Obtenu depuis : https://help.ubnt.com/hc/en-us/articles/360002668854

Vue d’ensemble

Dans cet article, les utilisateurs trouveront des instructions sur la façon de vérifier et de dépanner les VPN IPsec créés dans le contrôleur UniFi. Cet article couvrira à la fois Auto-IPsec et IPsec manuel et implique des étapes à la fois dans l’interface graphique du contrôleur UniFi et en ligne de commande (CLI) de l’USG.

| NOTES ET PRÉREQUIS :

Applicable à la gamme USG.
Cet article nécessite la configuration d’au moins un VPN sous Settings > Networks.
Si vous configurez un VPN manuel, les protocoles, durées de vie et clés pré-partagées doivent correspondre sur les deux points de terminaison VPN.

---|---

Table des matières

Étapes : Comment vérifier le fonctionnement du tunnel IPsec

(https://help.ubnt.com/hc/en-us/articles/360002668854#top)

Après avoir configuré le VPN sous Settings > Networks et laissé l’USG se provisionner, le VPN peut être vérifié par plusieurs méthodes, décrites ci-dessous.

Session SSH sur l’USG

	CLI : Accédez à l’interface en ligne de commande (CLI) en utilisant un programme tel que PuTTY. La sortie affichée variera par rapport à ce qui est montré ci-dessous.

1. Vérifiez les associations de sécurité (SA) IPsec et le statut sur l’USG :

**show vpn ipsec sa
** peer-192.0.2.1-tunnel-1: #1, ESTABLISHED, IKEv1, 184447c009d51f80:14cc0f13aff401c0
 local '203.0.113.1' @ 203.0.113.1
 remote '192.0.2.1' @ 192.0.2.1
 AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
 established 237s ago, reauth in 85347s
 peer-192.0.2.1-tunnel-1: #1, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_MD5_96
 installed 237 ago, rekeying in 41939s, expires in 42964s
 in cb321982, 180 bytes, 3 packets, 231s ago
 out 5d4174b1, 180 bytes, 3 packets, 231s ago
 local 192.168.1.0/24
 remote 172.16.1.0/24

**sudo ipsec statusall
** Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.10.14-UBNT, mips):
 uptime: 10 minutes, since Mar 12 09:05:48 2017
 malloc: sbrk 376832, mmap 0, used 269320, free 107512
 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
 Listening IP addresses:
 203.0.113.1
 192.168.1.1
Connections:
peer-192.0.2.1-tunnel-1: 203.0.113.1...192.0.2.1 IKEv1
peer-192.0.2.1-tunnel-1: local:  uses pre-shared key authentication
peer-192.0.2.1-tunnel-1: remote:  uses pre-shared key authentication
peer-192.0.2.1-tunnel-1: child: 192.168.1.0/24 === 172.16.1.0/24 TUNNEL
Routed Connections:
peer-192.0.2.1-tunnel-1{1}: ROUTED, TUNNEL
peer-192.0.2.1-tunnel-1{1}: 192.168.1.0/24 === 172.16.1.0/24
Security Associations (1 up, 0 connecting):
peer-192.0.2.1-tunnel-1: ESTABLISHED 5 minutes ago, 203.0.113.1...192.0.2.1
peer-192.0.2.1-tunnel-1: IKEv1 SPIs: 184447c009d51f80_i* 14cc0f13aff401c0_r, pre-shared key reauthentication in 23 hours
peer-192.0.2.1-tunnel-1: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
peer-192.0.2.1-tunnel-1{1}: INSTALLED, TUNNEL, ESP SPIs: cb321982_i 5d4174b1_o
peer-192.0.2.1-tunnel-1{1}: AES_CBC_128/HMAC_MD5_96, 180 bytes_i (3 pkts, 324s ago), 180 bytes_o (3 pkts, 324s ago)
peer-192.0.2.1-tunnel-1{1}: 192.168.1.0/24 === 172.16.1.0/24

2. Vérifiez la configuration strongSwan IPsec de l’USG :

**sudo cat /etc/ipsec.conf
** # generated by /opt/vyatta/sbin/vpn-config.pl

config setup

conn %default
       keyexchange=ikev1

conn peer-192.0.2.1-tunnel-1
       left=203.0.113.1
       right=192.0.2.1
       leftsubnet=192.168.1.0/24
       rightsubnet=172.16.1.0/24
       ike=aes256-sha256-modp2048!
       keyexchange=ikev1
       ikelifetime=86400s
       esp=aes128-md5!
       keylife=43200s
       rekeymargin=540s
       type=tunnel
       compress=no
       authby=secret
       auto=route
       keyingtries=%forever
#conn peer-192.0.2.1-tunnel-1

3. Capturez l’arrivée du trafic IKE sur l’interface WAN externe de l’USG :

**sudo tcpdump -i eth0 -n udp dst port 500
** tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 I ident
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 1 I ident
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 1 R ident
IP 203.0.113.1.500 > 192.0.2.1.500: isakmp: phase 2/others I oakley-quick
IP 192.0.2.1.500 > 203.0.113.1.500: isakmp: phase 2/others R oakley-quick

	Remarque : Il s’agit d’une capture en temps réel. S’il n’y a pas de sortie, cela signifie que le trafic n’est pas généré par le client, ou que quelque chose bloque le trafic en amont.

4. Capturez les journaux VPN IPsec de l’USG :

**sudo swanctl --log
** creating acquire job for policy 192.168.1.10/32 === 172.16.1.10/32 with reqid {1}
 initiating Main Mode IKE_SA peer-192.0.2.1-tunnel-1 to 192.0.2.1
 generating ID_PROT request 0
 sending packet: from 203.0.113.1 to 192.0.2.1 (160 bytes)
 received packet: from 192.0.2.1 to 203.0.113.1 (108 bytes)
 parsed ID_PROT response 0
 received NAT-T (RFC 3947) vendor ID
 generating ID_PROT request 0
 parsed ID_PROT response 0
 generating ID_PROT request 0
 parsed ID_PROT response 0
 IKE_SA peer-192.0.2.1-tunnel-1 established between 203.0.113.1...192.0.2.1
 generating QUICK_MODE request 561157166
 parsed QUICK_MODE response 561157166
 CHILD_SA peer-192.0.2.1-tunnel-1{1} established with SPIs cb321982_i 5d4174b1_o and TS 192.168.1.0/24 === 172.16.1.0/24

| Remarque : Il s’agit également d’une capture en temps réel. S’il n’y a pas de sortie, cela signifie que le trafic n’est pas autorisé à passer par le pare-feu. Sinon, utilisez la commande show vpn log | no-more pour afficher l’historique complet des journaux IPsec. ---|---

5. Envoyez du trafic à travers le tunnel depuis un client d’un côté du tunnel VPN vers un autre client. Ne testez pas cela depuis un USG. Le trafic doit provenir d’un client LAN.

6. Pour forcer le démarrage de la connexion sans avoir à envoyer du trafic à travers le tunnel au préalable, exécutez les commandes suivantes :

sudo ipsec statusall

Sous la liste Connections devrait se trouver le nom des pairs. Le nom du pair variera d’un USG à l’autre.

Exemple :

**Connections:
 peer-172.20.1.13-tunnel-vti**: 172.20.1.242...172.20.1.13 IKEv1, dpddelay=20s
**peer-172.20.1.13-tunnel-vti** : local:  uses pre-shared key authentication
**peer-172.20.1.13-tunnel-vti** : remote:  uses pre-shared key authentication
**peer-172.20.1.13-tunnel-vti** : child: 0.0.0.0/0 === 0.0.0.0/0 TUNNEL, dpdaction=restart

Procédez en forçant le tunnel à se connecter avec la commande suivante :

sudo ipsec up <connection_name>

Exemple :

**user@ubnt:~$ sudo ipsec up peer-172.20.1.13-tunnel-vti**
 generating QUICK_MODE request 1747091534
sending packet: from 172.20.1.242 to 172.20.1.13 (460 bytes)
received packet: from 172.20.1.13 to 172.20.1.242 (460 bytes)
parsed QUICK_MODE response 1747091534
CHILD_SA peer-172.20.1.13-tunnel-vti{1} established with SPIs cc5c8c8e_i c9473648_o and TS 0.0.0.0/0 === 0.0.0.0/0
connection 'peer-172.20.1.13-tunnel-vti' established successfully
adipple@ubnt:~$ show vpn ipsec sa
peer-172.20.1.13-tunnel-vti: #6, ESTABLISHED, IKEv1, 5366e644f90cde04:ef0e999fc18e24e7
 local '172.20.1.242' @ 172.20.1.242
 remote '172.20.1.13' @ 172.20.1.13
 AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
 established 4131s ago, reauth in 23759s
 peer-172.20.1.13-tunnel-vti: #1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_256_128/MODP_2048
 installed 881 ago, rekeying in 1766s, expires in 2720s
 in c0296e69, 0 bytes, 0 packets
 out c77e1590, 0 bytes, 0 packets
 local 0.0.0.0/0
 remote 0.0.0.0/0
 peer-172.20.1.13-tunnel-vti: #1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_256_128/MODP_2048
 installed 14 ago, rekeying in 2837s, expires in 3587s
 in cc5c8c8e, 0 bytes, 0 packets
 out c9473648, 0 bytes, 0 packets
 local 0.0.0.0/0
 remote 0.0.0.0/0

Cette sortie indique que le tunnel a été établi avec succès.

Dépannage

(https://help.ubnt.com/hc/en-us/articles/360002668854#top)

Problèmes avec ICMP ou l’accès aux clients/réseaux distants

Si l’adresse de l’interface WAN de l’USG est derrière un NAT, ce qui signifie que l’adresse IP se trouve dans la RFC1918 (adresses IPv4 privées), vous devrez rediriger les ports UDP 500 et 4500 sur le routeur ou le modem en amont de l’USG. Pour le “local WAN IP” dans la configuration VPN d’UniFi, mettez l’adresse WAN de l’USG (même si elle est derrière un NAT), puis connectez-vous en SSH à l’USG et tapez :

configure
set vpn ipsec site-to-site peer x.x.x.x authentication id <public_ip_of_modem or upstream router>

Cela est dû au fait que l’USG annoncera son adresse privée comme identifiant, alors que le côté distant s’attendra à l’adresse publique.

	Remarque : Pour rendre cette modification persistante, veuillez consulter l’article suivant. (https://help.ubnt.com/hc/en-us/articles/215458888)

Tunnel actif, pas de réponse ICMP :

Si le tunnel est actif mais que vous ne pouvez pas effectuer de ping, tapez show vpn ipsec sa et regardez les paquets entrants/sortants. Si vous voyez des paquets “out” mais pas de paquets “in”, cela signifie que l’ESP pourrait être filtré par le modem en amont. Vous pouvez essayer de configurer : set vpn ipsec site-to-site peer x.x.x.x force-encapsulation enable

Cela encapsule l’ESP (Encapsulating Security Payload) dans UDP 4500 avec NAT-T. 2. Si le tunnel est actif, mais que vous ne pouvez pas effectuer de ping, vérifiez si le trafic transite. Lancez un ping depuis un vrai client sur le LAN (pas l’USG lui-même) vers un client sur le LAN distant via le VPN. Si votre VPN a l’option “enable dynamic routing” configurée (ou est en mode “auto”), c’est un VPN basé sur les routes provisionné avec VTI. Vous pouvez le voir dans “show ip route”.

Pour voir si le trafic traverse le tunnel, exécutez ces commandes sur l’USG tout en envoyant un ping vers un client distant :

sudo tcpdump -npi vti0 (si vous utilisez **Auto IPsec VPN**)
sudo tcpdump -npi vti64 (si **VPN manuel** avec routage dynamique activé)

Examinez les compteurs de paquets entrants/sortants avec “show vpn ipsec sa”, pour voir si certains transitent. Les paquets sortants signifient que l’USG les envoie à travers le tunnel, les paquets entrants signifient qu’il les reçoit.

Vue d’ensemble

Table des matières

Étapes : Comment vérifier le fonctionnement du tunnel IPsec

Session SSH sur l’USG

Dépannage

Problèmes avec ICMP ou l’accès aux clients/réseaux distants

Tunnel actif, pas de réponse ICMP :

Pour voir si le trafic traverse le tunnel, exécutez ces commandes sur l’USG tout en envoyant un ping vers un client distant :

Articles Connexes

Unifi USG : Dépannage de l'authentification RADIUS

Comment redirect online domain/corporate traffic on a Windows 8 VPN connection

Configuration d'un serveur OpenVPN sur Ubuntu