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
- (https://help.ubnt.com/hc/en-us/articles/360002668854#3)
- (https://help.ubnt.com/hc/en-us/articles/360002668854#4)
- (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:
- 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.