IBM Cloud Docs
Configuration et traitement des incidents liés aux tunnels IPSec

Configuration et traitement des incidents liés aux tunnels IPSec

Les tunnels IPSec sont utilisés pour connecter en toute sécurité des sous-réseaux de l'espace privé (rfc1918) sur une connexion négociée entre deux routeurs ou pare-feux (communément appelés points d'extrémité pairs en référence à l'IPSec). En règle générale, les deux points d'extrémité homologues sont connectés l'un à l'autre par l'intermédiaire de l'internet. S'ils n'ont pas de connexion directe sur l'internet, l'un des pairs ou les deux peuvent être derrière un NAT/une redirection de port. La traversée NAT doit être activée dans vos configurations. I

Dans l'environnement IBM Cloud en particulier, Vyatta (ou un autre dispositif de passerelle classique) est utilisé comme point d'extrémité homologue côté infrastructure classique. L'extrémité distante (en référence à IBM Cloud) est un routeur ou un pare-feu du côté "on-prem".

La figure suivante montre une représentation visuelle très basique d'un tunnel IPSec, de IBM Cloud Classic à on-prem, via l'internet.

Configuration du tunnel IPSec de base de Vyatta
Figure 1 : Configuration du tunnel IPSec de base de Vyatta

IPSec basé sur les routes et les règles

Avec l'IPSec basé sur les routes, vous ne configurez pas de sélecteurs de trafic (également appelés préfixes locaux et distants), mais une interface VTI. En outre, vous configurez manuellement des itinéraires statiques pour des sous-réseaux distants avec un saut suivant défini sur cette interface.

Pour l'IPSec basé sur des règles sur le Vyatta, vous configurez des préfixes locaux et distants et ne configurez pas d'interface routable pour le tunnel. L'interface VFP a été ajoutée en tant que fonctionnalité afin d'ajouter une interface routable aux configurations IPSec basées sur des règles. Il n'est donc plus nécessaire de migrer vers une configuration basée sur les routes afin d'utiliser la NAT et des règles de pare-feu plus granulaires avec des tunnels basés sur des règles.

Pour en savoir plus sur les différences entre l'IPSec basé sur les routes et l'IPSec basé sur les règles, reportez-vous à l'article Options de configuration du VPN site à site IPsec.

Exemple de configuration d'IPSec basé sur les routes

L'exemple suivant est une configuration basée sur les routes fonctionnant dans l'environnement d'infrastructure classique IBM Cloud:

Côté ouest

#PHASE 1
set security vpn ipsec ike-group IKE-Fergie ike-version 2
set security vpn ipsec ike-group IKE-Fergie lifetime 28800
set security vpn ipsec ike-group IKE-Fergie proposal 1 dh-group 20
set security vpn ipsec ike-group IKE-Fergie proposal 1 encryption aes256
set security vpn ipsec ike-group IKE-Fergie proposal 1 hash sha2_256

#PHASE 2
set security vpn ipsec esp-group ESP-Fergie pfs dh-group20
set security vpn ipsec esp-group ESP-Fergie proposal 1 encryption aes128gcm128
set security vpn ipsec esp-group ESP-Fergie proposal 1 hash null
set security vpn ipsec esp-group ESP-Fergie lifetime 3600

#Tie it all together configuration
set security vpn ipsec site-to-site peer 159.8.98.213 authentication id 169.50.194.197
set security vpn ipsec site-to-site peer 159.8.98.213 authentication mode pre-shared-secret
set security vpn ipsec site-to-site peer 159.8.98.213 authentication pre-shared-secret '*********'
set security vpn ipsec site-to-site peer 159.8.98.213 authentication remote-id 159.8.98.213
set security vpn ipsec site-to-site peer 159.8.98.213 ike-group IKE-Fergie
set security vpn ipsec site-to-site peer 159.8.98.213 local-address 169.50.194.197
set security vpn ipsec site-to-site peer 159.8.98.213 vti bind vti2
set security vpn ipsec site-to-site peer 159.8.98.213 vti esp-group ESP-Fergie

#VTI INTERFACE CREATION
set interfaces vti vti2 address 172.16.0.5/30

#STATIC ROUTE CREATION FOR REMOTE PREFIX
set protocols static interface-route 10.127.132.128/26 next-hop-interface vti2

#HA considerations - group number can be different on each Vyatta
set interfaces bonding dp0bond1 vrrp vrrp-group 2 notify 'ipsec'

#IKEv2 considerations
set security vpn ike make-before-break

Côté Est

#PHASE 1
set security vpn ipsec ike-group IKE-Fergie ike-version 2
set security vpn ipsec ike-group IKE-Fergie lifetime 28800
set security vpn ipsec ike-group IKE-Fergie proposal 1 dh-group 20
set security vpn ipsec ike-group IKE-Fergie proposal 1 encryption aes256
set security vpn ipsec ike-group IKE-Fergie proposal 1 hash sha2_256

#PHASE 2
set security vpn ipsec esp-group ESP-Fergie pfs dh-group20
set security vpn ipsec esp-group ESP-Fergie proposal 1 encryption aes128gcm128
set security vpn ipsec esp-group ESP-Fergie proposal 1 hash null
set security vpn ipsec esp-group ESP-Fergie lifetime 3600

#Tie it all together configuration
et security vpn ipsec site-to-site peer 169.50.194.197 authentication id 159.8.98.213
set security vpn ipsec site-to-site peer 169.50.194.197 authentication mode pre-shared-secret
set security vpn ipsec site-to-site peer 169.50.194.197 authentication pre-shared-secret '*********'
set security vpn ipsec site-to-site peer 169.50.194.197 authentication remote-id 169.50.194.197
set security vpn ipsec site-to-site peer 169.50.194.197 ike-group IKE-Fergie
set security vpn ipsec site-to-site peer 169.50.194.197 local-address 159.8.98.213
set security vpn ipsec site-to-site peer 169.50.194.197 vti bind vti2
set security vpn ipsec site-to-site peer 169.50.194.197 vti esp-group ESP-Fergie

#VTI INTERFACE CREATION
set interfaces vti vti2 address 172.16.0.6/30

#STATIC ROUTE CREATION FOR REMOTE PREFIX
set protocols static interface-route 10.165.125.112/28 next-hop-interface vti2

#HA considerations - group number can be different on each Vyatta
set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify 'ipsec'

#IKEv2 considerations
set security vpn ike make-before-break

Pare-feu basés sur l'interface avec IPsec basé sur la route

Lorsque vous appliquez des règles de pare-feu à vos interfaces, vous devez savoir quelles sont les adresses IP source et destination d'un paquet à l'entrée et à la sortie d'une interface. Le diagramme suivant illustre un paquet typique traversant le Vyatta sur le chemin aller et retour à travers un tunnel IPSec.

Trafic IPSec
Figure 2 : Flux de trafic IPSec

La direction OUT pour un VTI est celle où le paquet sera crypté et envoyé hors du Vyatta. La direction IN d'un VTI est celle où le paquet sera décrypté et envoyé au serveur derrière le Vyatta. Pour l'interface extérieure, dp0bond1, le paquet contiendra toujours les adresses IP des points d'extrémité des homologues. Les ports/protocoles sont ESP, UDP port 500 et UDP port 4500 (si vous utilisez NAT-T).

L'IP source et l'IP destination d'un paquet dans la direction IN pour une interface VLAN (VIF) doivent correspondre à la direction OUT pour le VTI.

Les journaux de règles de pare-feu suivants illustrent le flux :

May 25 05:34:07 gateway02 dataplane[4391]:  In:dp0bond1 PASS fw rule PubIn:1 proto=(other/50) addr=198.11.194.155->159.8.98.214 macs=e4:c7:22:63:b5:41->0:0:5e:0:1:2 v4=(len:156,ttl:241,tos:00,ecn:Not,prot:50,hl:5)
May 25 05:34:07 gateway02 dataplane[4391]:  In:vti0 PASS fw rule INipsecvti0:10 proto=(icmp/1) addr=10.90.72.203->10.126.19.174 v4=(len:84,ttl:63,tos:00,ecn:Not,prot:1,hl:5) icmp=(EchoRq,type:8,code:0)
May 25 05:34:07 gateway02 dataplane[4391]: Out:dp0bond0.1750 PASS fw rule OUTipsec1750:10 proto=(icmp/1) addr=10.90.72.203->10.126.19.174 v4=(len:84,ttl:62,tos:00,ecn:Not,prot:1,hl:5) icmp=(EchoRq,type:8,code:0)
May 25 05:34:07 gateway02 dataplane[4391]:  In:dp0bond0.1750 PASS fw rule INipsec1750:10 proto=(icmp/1) addr=10.126.19.174->10.90.72.203 v4=(len:84,ttl:64,tos:00,ecn:Not,prot:1,hl:5) icmp=(EchoRp,type:0,code:0)
May 25 05:34:07 gateway02 dataplane[4391]: Out:vti0 PASS fw rule OUTipsecvti0:10 proto=(icmp/1) addr=10.126.19.174->10.90.72.203 v4=(len:84,ttl:63,tos:00,ecn:Not,prot:1,hl:5) icmp=(EchoRp,type:0,code:0)
May 25 05:34:07 gateway02 dataplane[4391]: Out:dp0bond1 PASS fw rule PubOut:1 proto=(other/50) addr=159.8.98.214->198.11.194.155 v4=(len:156,ttl:255,tos:00,ecn:Not,prot:50,hl:5)

Pare-feu de zone avec IPSec basé sur les routes

Pour les pare-feu basés sur des zones, les politiques que vous définissez doivent supposer que le trafic circule entre l'interface VTI et l'interface VLAN privée locale (VIF) du VRA. Il n'est pas nécessaire de définir une politique entre la VTI et les zones dp0bond1.

Dépannage de base

Pour résoudre les problèmes de configuration du tunnel IPSec, procédez comme suit :

  1. Réinitialiser les tunnels et redémarrer le VPN.

    Faites-le d'abord si vous le pouvez, car cela peut vous faire gagner du temps en cas de panne. Veillez à vous souvenir de ce que chaque commande redémarre et de son effet sur le reste des tunnels.

  2. Vérifier la connectivité du réseau de bout en bout entre les pairs.

    Assurez-vous que les ports UDP 500 et 4500 (si vous utilisez NAT-T) et le protocole ESP sont autorisés sur l'interface extérieure pour les deux homologues.

  3. Vérifier l'état de la phase 1. Un statut "en panne" peut signifier

    • Vous n'avez pas vérifié l'étape 2
    • Les versions IKE, les algorithmes de chiffrement, les algorithmes de hachage ou les identifiants IKE ne correspondent pas
    • Il existe des incompatibilités entre les fournisseurs
  4. Vérifier l'état de la phase 2. Un état "en panne" (ou pas d'état du tout) peut signifier :

    • La phase 1 est en panne
    • Les algorythmes de chiffrement, les algorythmes de hachage, les sélecteurs de trafic ou les dh-groups ne correspondent pas
    • Il existe des incompatibilités entre les fournisseurs
  5. Examinez les journaux IPsec disponibles pour y trouver des signes du problème. Les journaux peuvent vous donner des informations précises sur les discordances et vous aider à résoudre rapidement le problème.

  6. Consultez les patchs logiciels VRA pour obtenir des informations sur les bogues courants. Vous pouvez également demander un PDF complet au IBM Cloud Security Support.

Commandes de dépannage

Pour vérifier l'état de la phase 1 :

show vpn ike sa
show vpn ike sa peer <Peer IP>

Exemple de sortie :

vyatta@siferguson-par01-02:~$ show vpn ike sa peer 169.50.194.197
Peer ID / IP                            Local ID / IP
------------                            -------------
169.50.194.197                          159.8.98.213

    State    Encrypt       Hash    D-H Grp  A-Time  L-Time IKEv
    -----  ------------  --------  -------  ------  ------ ----
    up     aes256        sha2_256  14       2154    3600    2

Pour vérifier l'état de la phase 2 :

show vpn ipsec sa
show vpn ipsec sa peer <Peer IP>

Exemple de sortie :

vyatta@siferguson-par01-02:~$ show vpn ipsec sa peer 169.50.194.197
Peer ID / IP                            Local ID / IP
------------                            -------------
169.50.194.197                          159.8.98.213

    Tunnel  Id          State  Bytes Out/In   Encrypt       Hash      DH A-Time  L-Time
    ------  ----------  -----  -------------  ------------  --------  -- ------  ------
    vti     44          up     284.3M/27.2G   aes128gcm128  null      n/a 2131    300

Pour afficher rapidement un ensemble d'informations détaillées sur une connexion homologue spécifique :

show vpn debug peer <Peer IP>

Exemple de sortie :

vyatta@siferguson-par01-02:~$ show vpn debug peer 169.50.194.197
peer-169.50.194.197:  159.8.98.213...169.50.194.197  IKEv2
peer-169.50.194.197:   local:  [159.8.98.213] uses pre-shared key authentication
peer-169.50.194.197:   remote: [169.50.194.197] uses pre-shared key authentication
peer-169.50.194.197-tunnel-vti:   child:  0.0.0.0/0 === 0.0.0.0/0 TUNNEL
peer-169.50.194.197[48]: ESTABLISHED 38 minutes ago, 159.8.98.213[500][159.8.98.213]...169.50.194.197[500][169.50.194.197]
peer-169.50.194.197[48]: IKEv2 SPIs: 65967eb4beab8549_i 1eacdfa5f926b9a3_r*, pre-shared key reauthentication in 13 minutes
peer-169.50.194.197[48]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
peer-169.50.194.197-tunnel-vti{44}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: 9796e1b4_i db89cc43_o
peer-169.50.194.197-tunnel-vti{44}:  AES_GCM_16_128, 31436172664 bytes_i, 322001309 bytes_o, rekeying active
peer-169.50.194.197-tunnel-vti{44}:   0.0.0.0/0 === 0.0.0.0/0

{ : screen|

Pour afficher et analyser les journaux IPSec disponibles :

show log vpn ipsec
show log vpn ipsec subsystem ike-sa site-to-site peer <Peer IP>
journalctl -f -u strongswan #This live follows the end of the journal logs for ipsec
journalctl -u strongswan > /home/vyatta/journalctl-ipsec-$(date +%Y%m%d) #this creates a file so that you can parse/grep through the logs without them rotating

Pour réinitialiser les tunnels IPSec :

 reset vpn ipsec-peer <Peer IP> #reset all tunnels/phase 2's on this peer
 reset vpn ipsec-peer <Peer IP> tunnel <tunnel id> #reset phase 2 tunnel for only the specified tunnel on the specified peer
 restart vpn #This restarts the entire IPSec VPN subsystem - this affects all tunnels on all peers

Problèmes courants

La liste suivante présente quelques problèmes courants que vous pouvez rencontrer avec les tunnels IPSec.

  • Les paramètres de la phase 1 et de la phase 2 ne correspondent pas entre les deux homologues.
  • Les versions IKE ne correspondent pas.
  • La phase 1 échoue avec une erreur d'authentification alors que tout semble correspondre.
    • Veillez à ce que l'ID d'authentification et l'ID distant correspondent aux adresses IP locale et distante.
  • Les ports ESP et UDP 500 et 4500 ne sont pas autorisés sur les interfaces extérieures.
    • Assurez-vous que l'ESP et le port 500 sont autorisés. Si vous utilisez NAT-T, assurez-vous que UDP 4500 est autorisé.
  • Ciena recommande d'utiliser la ligne set security vpn ike make-before-break lorsque vous utilisez IKEv2. L'omission de cette ligne peut entraîner des pannes.
  • Thoroughput est lent.
    • Utilisez soit le aes128gcm soit le aes256gcm comme algorythme de cryptage de la phase 2. Cela peut augmenter considérablement le débit si l'algorithme de cryptage précédent était le standard AES128 ou AES256.
    • Désactiver l'enregistrement par paquet s'il est mis en œuvre. La journalisation du pare-feu par paquet peut réduire le débit.
  • Les tunnels IPSec fonctionnent, mais ils s'arrêtent après une nouvelle clé.
    • Vérifiez que PFS et dh-groups correspondent sur les deux pairs.
  • La commande show vpn ipsec sa affiche les incréments dans une seule direction.
    • Cela est généralement dû à un routage asymétrique, où un côté envoie des données à travers le tunnel et l'autre non.
  • Utilisation de run-transition-scripts pour le basculement HA au lieu de la commande de remplacement notify.

Autres ressources

La liste suivante fournit des ressources supplémentaires pour la configuration et le dépannage des tunnels IPSec :