Obtido de: https://help.ubnt.com/hc/en-us/articles/360002668854

Visão Geral


Neste artigo, os usuários encontrarão instruções sobre como verificar e solucionar problemas de VPNs IPsec criadas no UniFi Controller. Este artigo abordará tanto Auto-IPsec quanto IPsec manual e envolve passos tanto na GUI do UniFi Controller quanto na linha de comando (CLI) do USG.

| NOTAS E REQUISITOS:

  • Aplicável à linha de produtos USG.
  • Este artigo requer a configuração de pelo menos uma VPN em Settings > Networks.
  • Se estiver configurando uma VPN manual, os protocolos, tempos de vida e chaves pré-compartilhadas devem coincidir em ambos os endpoints da VPN.

---|---


Sumário


  1. (https://help.ubnt.com/hc/en-us/articles/360002668854#3)
  2. (https://help.ubnt.com/hc/en-us/articles/360002668854#4)
  3. (https://help.ubnt.com/hc/en-us/articles/360002668854#5)

Passos: Como Verificar a Operação do Túnel IPsec


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

Após configurar a VPN em Settings > Networks e permitir que o USG faça o provisionamento, a VPN pode ser verificada por vários métodos, descritos abaixo.

Sessão SSH no USG


CLI: Acesse a interface de linha de comando (CLI) usando um programa como o PuTTY. A saída exibida pode variar do que é mostrado abaixo.

1. Verifique as Security Associations (SAs) e o status do IPsec no 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. Verifique a configuração strongSwan do IPsec no 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. Capture a chegada do tráfego IKE na interface WAN externa do 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
Nota : Esta é uma captura em tempo real. Se não houver saída, isso significa que o tráfego não está sendo gerado no cliente ou que algo está bloqueando o tráfego a montante.

4. Capture os logs de VPN IPsec do 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

| Nota : Esta também é uma captura em tempo real. Se não houver saída, isso significa que o tráfego não está sendo permitido pelo firewall. Alternativamente, use o comando show vpn log | no-more para visualizar todo o histórico de logs IPsec. ---|---

5. Envie tráfego pelo túnel de um cliente em um lado do túnel VPN para outro cliente. Não teste isso a partir de um USG. O tráfego deve vir de um cliente na LAN.

6. Para forçar o início da conexão sem precisar primeiro enviar tráfego pelo túnel, execute os seguintes comandos:

sudo ipsec statusall

Na lista Connections deve estar o nome dos peers. O nome do peer pode variar de USG para USG.

Exemplo:

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

Prossiga forçando a conexão do túnel com o seguinte comando:

sudo ipsec up <connection_name>

Exemplo:

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

Esta saída indica que o túnel foi estabelecido com sucesso.


Solução de Problemas


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

Problemas com ICMP ou Acesso a Clientes/Redes Remotas

Se o endereço da interface WAN do USG estiver atrás de NAT, o que significa que o endereço IP está dentro do RFC1918 (endereços IPv4 privados), você precisará encaminhar as portas UDP 500 e 4500 no roteador ou modem a montante do USG. Para o “local WAN IP” na configuração VPN do UniFi, coloque o endereço WAN do USG (mesmo se estiver atrás de NAT), depois prossiga acessando o USG via SSH e digitando:

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

Isso ocorre porque o USG anunciará seu endereço privado como sua ID, enquanto o lado remoto estará esperando o endereço público.

Nota : Para tornar esta alteração persistente, consulte o seguinte artigo. (https://help.ubnt.com/hc/en-us/articles/215458888)

Túnel Ativo, Sem Resposta ICMP:

  1. Se o túnel está ativo mas não consegue fazer ping, digite show vpn ipsec sa e observe os pacotes de entrada/saída. Se você vê pacotes “out” mas não “in”, isso significa que o ESP pode estar sendo filtrado pelo modem a montante. Você pode tentar configurar: set vpn ipsec site-to-site peer x.x.x.x force-encapsulation enable

Isso encapsula o ESP (encapsulating security payload) em UDP 4500 com NAT-T. 2. Se o túnel está ativo, mas você não consegue fazer ping, verifique se o tráfego está passando. Envie um ping a partir de um cliente real na LAN (não do próprio USG) destinado a um cliente na LAN remota pela VPN. Se sua VPN tem “enable dynamic routing” configurado (ou é “auto”), é uma VPN baseada em rotas provisionada com VTI. Você pode ver isso em “show ip route”.

Para ver se o tráfego está atravessando o túnel, execute estes comandos no USG enquanto envia um ping para um cliente remoto:

sudo tcpdump -npi vti0 (if using Auto IPsec VPN)
sudo tcpdump -npi vti64 (if manual VPN with dynamic routing enabled)

Observe os contadores de pacotes de entrada/saída com “show vpn ipsec sa”, veja se algum está passando. Pacotes de saída significam que o USG está enviando-os pelo túnel, pacotes de entrada significam que está recebendo-os.