Bezogen von: https://help.ubnt.com/hc/en-us/articles/360002668854

Übersicht

In diesem Artikel finden Benutzer Anleitungen zur Überprüfung und Fehlerbehebung von IPsec VPNs, die im UniFi Controller erstellt wurden. Dieser Artikel behandelt sowohl Auto-IPsec als auch manuelles IPsec und umfasst Schritte sowohl in der UniFi Controller GUI als auch in der USG-Kommandozeile (CLI).

| HINWEISE & ANFORDERUNGEN:

Gilt für die USG-Produktlinie.
Dieser Artikel setzt die Konfiguration mindestens eines VPN unter Settings > Networks voraus.
Bei der Konfiguration eines manuellen VPN müssen Protokolle, Lebensdauern und Pre-Shared-Keys auf beiden VPN-Endpunkten übereinstimmen.

---|---

Inhaltsverzeichnis

Schritte: IPsec-Tunnelbetrieb überprüfen

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

Nach der Konfiguration des VPN unter Settings > Networks und der Provisionierung des USG kann das VPN mit verschiedenen Methoden überprüft werden, die im Folgenden beschrieben werden.

SSH-Sitzung auf dem USG

	CLI: Greifen Sie auf die Kommandozeile (CLI) zu, indem Sie ein Programm wie PuTTY verwenden. Die angezeigte Ausgabe kann von der unten gezeigten abweichen.

1. Überprüfen Sie die IPsec Security Associations (SAs) und den Status auf dem 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. Überprüfen Sie die USG IPsec strongSwan-Konfiguration:

**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. Erfassen Sie den eingehenden IKE-Datenverkehr auf der externen WAN-Schnittstelle des 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

	Hinweis: Dies ist eine Live-Aufzeichnung. Wenn keine Ausgabe erfolgt, bedeutet das, dass der Datenverkehr entweder nicht vom Client generiert wird oder etwas den Datenverkehr vorgelagert blockiert.

4. Erfassen Sie die USG IPsec VPN-Protokolle:

**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

| Hinweis: Dies ist ebenfalls eine Live-Aufzeichnung. Wenn keine Ausgabe erfolgt, bedeutet das, dass der Datenverkehr nicht durch die Firewall gelassen wird. Alternativ können Sie den Befehl show vpn log | no-more verwenden, um das gesamte IPsec-Protokoll einzusehen. ---|---

5. Senden Sie Datenverkehr durch den Tunnel von einem Client auf einer Seite des VPN-Tunnels zu einem anderen Client. Testen Sie dies nicht von einem USG aus. Der Datenverkehr muss von einem LAN-Client kommen.

6. Um die Verbindung ohne vorheriges Senden von Datenverkehr durch den Tunnel zu erzwingen, führen Sie die folgenden Befehle aus:

sudo ipsec statusall

Unter der Connections-Liste sollte der Name der Peers stehen. Der Name des Peers variiert von USG zu USG.

Beispiel:

**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

Erzwingen Sie den Tunnelaufbau mit dem folgenden Befehl:

sudo ipsec up <connection_name>

Beispiel:

**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

Diese Ausgabe zeigt an, dass der Tunnel erfolgreich aufgebaut wurde.

Fehlerbehebung

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

Probleme mit ICMP oder Zugriff auf Remote-Clients/Netzwerke

Wenn die WAN-Schnittstellenadresse des USG hinter NAT liegt, was bedeutet, dass die IP-Adresse innerhalb von RFC1918 (Private IPv4-Adressen) liegt, müssen Sie die UDP-Ports 500 und 4500 auf dem Router oder Modem vor dem USG weiterleiten. Geben Sie für die “local WAN IP” in der VPN-Konfiguration von UniFi die WAN-Adresse des USG ein (auch wenn hinter NAT), und fahren Sie dann mit dem SSH-Zugriff auf das USG fort und geben Sie Folgendes ein:

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

Dies liegt daran, dass das USG seine private Adresse als ID ankündigt, während die Gegenseite die öffentliche Adresse erwartet.

	Hinweis: Um diese Änderung persistent zu machen, lesen Sie bitte den folgenden Artikel. (https://help.ubnt.com/hc/en-us/articles/215458888)

Tunnel aktiv, keine ICMP-Antwort:

Wenn der Tunnel aktiv ist, aber kein Ping möglich ist, geben Sie show vpn ipsec sa ein und schauen Sie sich die Pakete ein/aus an. Wenn Sie “out”-Pakete sehen, aber keine “in”-Pakete, bedeutet das, dass ESP möglicherweise vom vorgelagerten Modem gefiltert wird. Sie können versuchen, Folgendes einzustellen: set vpn ipsec site-to-site peer x.x.x.x force-encapsulation enable

Dies kapselt ESP (Encapsulating Security Payload) in UDP 4500 mit NAT-T ein. 2. Wenn der Tunnel aktiv ist, Sie aber keinen Ping durchführen können, prüfen Sie, ob der Datenverkehr durchkommt. Senden Sie einen Ping von einem tatsächlichen Client im LAN (nicht vom USG selbst) an einen Client im Remote-LAN über das VPN. Wenn Ihr VPN “enable dynamic routing” konfiguriert hat (oder “auto” ist), handelt es sich um ein routenbasiertes VPN, das mit VTI provisioniert wurde. Sie können dies in “show ip route” sehen.

Um zu sehen, ob der Datenverkehr den Tunnel durchquert, führen Sie diese Befehle auf dem USG aus, während Sie einen Ping an einen Remote-Client senden:

sudo tcpdump -npi vti0 (bei Verwendung von **Auto IPsec VPN**)
sudo tcpdump -npi vti64 (bei **manuellem VPN** mit aktiviertem dynamischen Routing)

Schauen Sie sich die Paket-ein/Paket-aus-Zähler mit “show vpn ipsec sa” an und prüfen Sie, ob welche durchkommen. Pakete aus bedeutet, dass das USG sie durch den Tunnel sendet, Pakete ein bedeutet, dass es sie empfängt.

Übersicht

Inhaltsverzeichnis

Schritte: IPsec-Tunnelbetrieb überprüfen

SSH-Sitzung auf dem USG

Fehlerbehebung

Probleme mit ICMP oder Zugriff auf Remote-Clients/Netzwerke

Tunnel aktiv, keine ICMP-Antwort:

Um zu sehen, ob der Datenverkehr den Tunnel durchquert, führen Sie diese Befehle auf dem USG aus, während Sie einen Ping an einen Remote-Client senden:

Verwandte Artikel

Unifi USG: Fehlerbehebung bei RADIUS-Authentifizierung

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

OpenVPN-Server auf Ubuntu einrichten