Tunnels VPN et IPsec

1) Pourquoi IPsec et quand il est approprié

• Site-to-Site: on-prem ↔ cloud, cloud ↔ cloud, DC ↔ DC.
• Client VPN : admin-access, jump-host, break-glass.
• Backhaul/Transit: хабы и spoke-VPC/VNet (hub-and-spoke).
• L'IPsec est approprié lorsque vous avez besoin d'une pile standard et interopérable, d'une accélération matérielle (AES-NI/DPDK/ASIC), de crypto-politiques strictes et d'une compatibilité avec le fer réseau.

2) Concepts de base (résumé rapide)

IKEv2 (Phase 1) - Harmonisation des paramètres/authentification (RSA/ECDSA/PSK), création d'IKE SA.
IPsec ESP (Phase 2) - cryptage du trafic, Child SA (SA pour des préfixes/interfaces spécifiques).
PFS - ephemerality (groupe Diffie-Hellman) pour chaque enfant SA.
NAT-T (UDP/4500) - encapsulation ESP s'il y a un NAT sur le chemin.
DPD - Dead Peer Detection, remplacement d'un SA cassé.
Rekey/Reauth - Mise à jour des clés jusqu'à expiration (lifetime/bytes).

• IKE : 'AES-256-GCM' ou 'AES-256-CBC + SHA-256', DH 'groupe 14/19/20' (2048 bits MODP ou ECP).
• ESP : 'AES-GCM-256' (AEAD), PFS par les mêmes groupes.
• Lifetimes : IKE 8-24 h, enfant 30-60 min ou en volume de trafic (par exemple 1-4 Go).

3) Topologies et types de tunnels

3. 1 Route basée (de préférence)

Une interface virtuelle (VTI) de chaque côté ; les itinéraires/protocoles dynamiques (BGP/OSPF) portent des préfixes. Il est plus facile de mettre à l'échelle et de segmenter, mieux pour le CIDR (avec des politiques NAT).

3. 2 Policy-based (sélecteurs de trafic)

Listes « istochnik↔naznacheniye » dans SA. Convient pour les S2S simples sans routage dynamique ; plus difficile avec beaucoup de préfixes.

3. 3 GRE-over-IPsec / VXLAN-over-IPsec

L'encapsulation est L3/L2 au-dessus du canal crypté : multiprotocole, pratique pour les BGP (portez keepalive) et pour les cas où vous avez besoin de multicast/ESMR dans underlay.

4) Segmentation, routage et tolérance aux pannes

BGP sur VTI/GRE : échange de préfixes, MED/LocalPref/communities pour les priorités, protection max-prefix.
ECMP/Active-Active : une paire de tunnels en parallèle (différents fournisseurs/RR).
Active-Passive : Tunnel de secours avec un AD/LocalPref plus élevé, DPD accélère le basculement.
Split-tunnel : uniquement les préfixes d'entreprise via VPN ; Internet - localement (réduction des retards/coûts).
CIDR intersection : Politiques NAT sur les bords ou sous-réseaux proxy, si possible, réaménagement de l'adressage.

5) MTU, MSS et performance

IPsec/NAT-T overhead : − ~ 60-80 octets par paquet. Mettez MTU 1436-1460 pour VTI/tunnels.
MSS-clamp : pour TCP, exposez 'MSS = 1350-1380' (dépendant de underlay) pour éliminer la fragmentation.
Activez le PMTUD et logiez ICMP « Fragmentation Needed ».
L'offload matériel/fast-path (DPDK, AES-NI, ASIC) réduit considérablement la charge de travail du CPU.

6) Fiabilité et sécurité des clés

PFS est obligatoire ; Rekey avant l'expiration de 70-80 % lifetime.
Authentification : si ECDSA est possible, les certificats de CA d'entreprise (ou cloud-CA), PSK - seulement temporairement et avec une haute entropie.
CRL/OCSP ou courte durée de validité des certificats.
Journaux d'authentification et alertes en cas d'échec répété d'IKE.

7) Les nuages et les caractéristiques des fournisseurs

AWS: AWS Managed VPN (policy-based/route-based), TGW (Transit Gateway), VGW/CGW. Pour la performance/échelle - Direct Connect + IPsec comme backup.
GCP: Cloud VPN (Classic/HA), Cloud Router (BGP); для throughput — Interconnect.
Azure : VPN Gateway (Policy/Route-based), VNet-to-VNet, ExpressRoute pour une private de L2/L3.
Private Endpoints/Privatelink : le trafic vers PaaS est mieux conduit via des interfaces privées au lieu de NAT egress.

8) Kubernetes et service-mesh

Nodes K8s à l'intérieur des réseaux privés ; Pod CIDR ne doit pas « sortir » vers des sites distants - acheminer le Node CIDR et faire défiler les services via les passerelles ingress/egress.
Istio/Linkerd mTLS sur IPsec sont des domaines de confiance distincts.
Contrôle egress : interdiction de quitter directement le pod sur Internet (NetworkPolicy), autorisation - sur VTI/VPN.

9) Surveillance et journaux

Tunnel-SLA : latency, jitter, packet loss, up/down état SA.
BGP : voisins, préfixes, compteurs flap.
Logs IKE/ESP : authenticité, rekey, événement DPD.
Exportation vers Prometheus (via snmp_exporter/telegraf), alertes sur churn SA et dégradation RTT/PLR.
Marquez 'site = onprem' cloud ',' vpn = tunnel-X 'pour la corrélation.

10) Trablshuting (checklist)

1. Firvols : UDP/500, UDP/4500, protocole 50 (ESP) sont autorisés sur le chemin (ou seulement 4500 sous NAT-T).
2. L'horloge/NTP est synchrone - sinon IKE tombe en raison des temps/certificats.
3. Les paramètres IKE/ESP sont les mêmes : codes, DH, lifetimes, sélecteurs.
4. NAT-T est activé s'il y a un NAT.
5. DPD et rekey : pas trop agressifs, mais pas paresseux non plus (DPD 10-15s, rekey ~ 70 % lifetime).
6. MTU/MSS : Serrer le MSS, vérifier ICMP « non fragmentation ».
7. BGP : filtres/communities/AS-path, n'y a-t-il pas de « blackhole » à cause du wrong next-hop.
8. Logs : IKE SA established ? Child SA created? Le SPI change-t-il ? Y a-t-il des erreurs de replay ?

11) Configi (référents, raccourcis)

11. 1 strongSwan (route-based VTI + IKEv2)

ini
/etc/ipsec. conf conn s2s keyexchange=ikev2 auto=start left=%defaultroute leftid=@onprem. example leftsubnet=0. 0. 0. 0/0 leftauth=pubkey leftcert=onprem. crt right=203. 0. 113. 10 rightid=@cloud. example rightsubnet=0. 0. 0. 0/0 rightauth=pubkey ike=aes256gcm16-prfsha256-ecp256!
esp=aes256gcm16-ecp256!
dpdaction=restart dpddelay=15s ikelifetime=12h lifetime=45m installpolicy=no      # route-based через VTI

bash ip tunnel add vti0 local 198. 51. 100. 10 remote 203. 0. 113. 10 mode vti ip link set vti0 up mtu 1436 ip addr add 169. 254. 10. 1/30 dev vti0 ip route add 10. 20. 0. 0/16 dev vti0

11. 2 VyOS (BGP sur VTI, MSS clamp)

bash set interfaces vti vti0 address '169. 254. 10. 1/30'
set interfaces vti vti0 mtu '1436'
set protocols bgp 65010 neighbor 169. 254. 10. 2 remote-as '65020'
set protocols bgp 65010 neighbor 169. 254. 10. 2 timers holdtime '9'
set firewall options mss-clamp interface-type 'all'
set firewall options mss-clamp mss '1360'

11. 3 Cisco IOS (IKEv2/IPsec profile)

cisco crypto ikev2 proposal P1 encryption aes-gcm-256 integrity null group 19
!
crypto ikev2 policy P1 proposal P1
!
crypto ikev2 keyring KR peer CLOUD address 203. 0. 113. 10 pre-shared-key very-long-psk
!
crypto ikev2 profile IKEV2-PROF match address local 198. 51. 100. 10 authentication local pre-share authentication remote pre-share keyring local KR
!
crypto ipsec transform-set ESP-GCM esp-gcm 256 mode transport
!
crypto ipsec profile IPSEC-PROF set transform-set ESP-GCM set ikev2-profile IKEV2-PROF
!
interface Tunnel10 ip address 169. 254. 10. 1 255. 255. 255. 252 tunnel source 198. 51. 100. 10 tunnel destination 203. 0. 113. 10 tunnel protection ipsec profile IPSEC-PROF ip tcp adjust-mss 1360

12) Politiques et conformité

Les cryptophiles et les listes de codes autorisés sont centralisés (security baseline).
Rotation de clés/serts avec rappels et automatisation.
Audit-logs IKE/IPsec dans un coffre-fort immuable (WORM/Object Lock).
Segmentation : domaines VRF/VR pour prod/stage/dev et circuit de cartes (PCI DSS).

13) Spécificités d'iGaming/Finance

Résidence de données : le trafic avec des événements PII/de paiement ne passe par IPsec que dans les juridictions autorisées (routage par VRF/étiquettes).
PSP/KYC : si l'accès est donné par la connectivité privée - utiliser ; sinon, un proxy egress avec mTLS/HMAC, allowlist FQDN.
Journaux des transactions : enregistrement parallèle (sur on-bou et dans le cloud) via IPsec/Privatelink ; logiques immuables.
SLO « chemins de l'argent » : tunnels/itinéraires séparés avec priorité et surveillance accrue.

14) Anti-modèles

PSK pour toujours, une phrase secrète « commune ».
Policy-based avec de nombreux préfixes - « l'enfer des admins » (mieux que VTI + BGP).
Ignorer MTU/MSS → fragmentation, temporisation cachée, 3xx/5xx « sans raison ».
Un tunnel sans réserve ; un fournisseur.
L'absence de NTP/clock-sync → les chutes IKE spontanées.
Codes par défaut (groupes obsolètes/MD5/SHA1).
Pas d'alerts sur le flap SA/BGP et la croissance du RTT/PLR.

15) Chèque-liste prod-prêt

• IKEv2 + AES-GCM + PFS (groupe de 14/19/20), lifetimes, rekey ~ 70 %.
• VTI/GRE, BGP avec filtres/communautés, ECMP ou hot-standby.
• NAT-T est activé (si nécessaire), ouvert UDP/500/4500, ESP en cours de route.
• MTU 1436-1460, MSS clamp 1350-1380, PMTUD actif.
• DPD 10-15s, Réaction de Dead Peer et réinstallation rapide de SA.
• Suivi SA/BGP/RTT/PLR ; logiques IKE/ESP en collection centralisée.
• Rotation automatique des serts/clés, TTL courts, OCSP/CRL, alertes.
• Segmentation (VRF), split-tunnel, politique egress « deny-by-default ».
• Les gateways cloud (AWS/GCP/Azure) sont testés sur charge réelle.
• Runbook documenté "et faussaire et extensions de canal.

16) TL; DR

Construisez IPsec (VTI/GRE) avec le IKEv2 + AES-GCM + PFS, le routage dynamique BGP, la sauvegarde sur deux liens indépendants et le MTU/MSS correct. Activer NAT-T, DPD et rekey régulier, surveiller SA/BGP/RTT/PLR, stocker les logs d'authentification. Dans les nuages, utilisez les passerelles gérées et PrivateLink ; dans Kubernetes - ne pas « tracer » Pod CIDR via VPN. Pour iGaming, gardez les juridictions et le circuit de paiement isolés, avec des SLO et des audits serrés.