Situação
Resultado. Eu bebo café. O aluno configurou uma conexão VPN entre dois pontos e desapareceu. Eu verifico: o túnel existe realmente, mas não há tráfego no túnel. O aluno não atende chamadas.
Eu coloco a chaleira no fogo e mergulho na solução de problemas do C-Terra Gateway. Compartilho minha experiência e metodologia.
Dados iniciais
Os dois sites separados geograficamente são conectados por um túnel GRE. GRE precisa ser criptografado:
Verificando se o túnel GRE está funcionando. Para fazer isso, eu sibilo do dispositivo R1 para a interface GRE do dispositivo R2. Este é o tráfego direcionado para criptografia. Sem resposta:
root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
--- 1.1.1.2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057msEu vejo os registros no Gate1 e no Gate2. O log relata alegremente que o túnel IPsec foi aumentado com sucesso, sem problemas:
root@Gate1:~# cat /var/log/cspvpngate.log
Aug 5 16:14:23 localhost vpnsvc: 00100119 <4:1> IPSec connection 5 established, traffic selector 172.17.0.1->172.16.0.1, proto 47, peer 10.10.10.251, id "10.10.10.251", Filter
IPsec:Protect:CMAP:1:LIST, IPsecAction IPsecAction:CMAP:1, IKERule IKERule:CMAP:1Nas estatísticas do túnel IPsec no Gate1, vejo que o túnel realmente existe, mas o contador Rcvd está zerado:
root@Gate1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded
ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 3 (10.10.10.251,500)-(10.10.10.252,500) active 1070 1014
IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0Eu soluciono os problemas do C-Terra assim: Estou procurando onde os pacotes de destino são perdidos no caminho de R1 para R2. No processo (spoiler), encontrarei um erro.
Solução de problemas
Etapa 1. O que Gate1 obtém de R1 Eu
uso o farejador de pacotes embutido - tcpdump. Eu executo o sniffer na interface interna (Gi0 / 1 na notação semelhante à Cisco ou eth1 na notação Debian OS):
root@Gate1:~# tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 1, length 64
14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 2, length 64
14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 3, length 64
14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 4, length 64Vejo que o Gate1 está recebendo pacotes GRE de R1. Se movendo.
Etapa 2. O que o Gate1 faz com os pacotes GRE
Usando o utilitário klogview, posso ver o que acontece com os pacotes GRE dentro do driver VPN C-Terra:
root@Gate1:~# klogview -f 0xffffffff
filtration result for out packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 4 "IPsecPolicy:CMAP", filter 8, event id IPsec:Protect:CMAP:1:LIST, status PASS
encapsulating with SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0
passed out packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: encapsulated
Vejo que o tráfego GRE alvo (proto 47) 172.16.0.1 -> 172.17.0.1 caiu (PASSA) sob a regra de criptografia LIST no mapa criptográfico CMAP e foi criptografado (encapsulado). O pacote foi então roteado (desmaiado). Não há tráfego de resposta na saída do klogview.
Verificando as listas de acesso no dispositivo Gate1. Vejo uma lista de acesso LIST, que define o tráfego de destino para criptografia, o que significa que as regras do ME não estão configuradas:
Gate1#show access-lists
Extended IP access list LIST
10 permit gre host 172.16.0.1 host 172.17.0.1Conclusão: o problema não está no dispositivo Gate1.
Mais sobre o
driver VPN klogview lida com todo o tráfego de rede, não apenas aquele que precisa ser criptografado. Essas mensagens são visíveis no klogview se o driver VPN processou o tráfego de rede e o transmitiu sem criptografia:
root@R1:~# ping 172.17.0.1 -c 4root@Gate1:~# klogview -f 0xffffffff
filtration result for out packet 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: chain 4 "IPsecPolicy:CMAP": no match
passed out packet 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: filteredVejo que o tráfego ICMP (proto 1) 172.16.0.1-> 172.17.0.1 não obteve (nenhuma correspondência) nas regras de criptografia do mapa de criptografia CMAP. O pacote foi roteado (desmaiado) em texto não criptografado.
Etapa 3. O que o Gate2 recebe do Gate1 Inicie um
sniffer na interface WAN (eth0) do Gate2:
root@Gate2:~# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), length 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), length 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), length 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), length 140Vejo que o Gate2 está recebendo pacotes ESP do Gate1.
Etapa 4. O que o Gate2 faz com os pacotes ESP
Inicie o utilitário klogview no Gate2:
root@Gate2:~# klogview -f 0xffffffff
filtration result for in packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: chain 17 "FilterChain:L3VPN", filter 21, status DROP
dropped in packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: firewall
Vejo que os pacotes ESP (proto 50) foram descartados (DROP) pela regra (L3VPN) do firewall. Certifico-me de que a lista de acesso L3VPN está realmente anexada a Gi0 / 0:
Gate2#show ip interface gi0/0
GigabitEthernet0/0 is up, line protocol is up
Internet address is 10.10.10.252/24
MTU is 1500 bytes
Outgoing access list is not set
Inbound access list is L3VPNEu encontrei o problema.
Etapa 5. O que há de errado com a lista de acesso?
Vejo qual é a lista de acesso L3VPN:
Gate2#show access-list L3VPN
Extended IP access list L3VPN
10 permit udp host 10.10.10.251 any eq isakmp
20 permit udp host 10.10.10.251 any eq non500-isakmp
30 permit icmp host 10.10.10.251 anyVejo que os pacotes ISAKMP são permitidos, portanto, um túnel IPsec foi estabelecido. Mas não existe uma regra permissiva para ESP. Aparentemente, o aluno confundiu icmp e esp.
Corrijo a lista de acesso:
Gate2(config)#
ip access-list extended L3VPN
no 30
30 permit esp host 10.10.10.251 anyEtapa 6. Verificando a funcionalidade
Em primeiro lugar, certifique-se de que a lista de acesso L3VPN está correta:
Gate2#show access-list L3VPN
Extended IP access list L3VPN
10 permit udp host 10.10.10.251 any eq isakmp
20 permit udp host 10.10.10.251 any eq non500-isakmp
30 permit esp host 10.10.10.251 anyAgora eu lanço o tráfego direcionado do dispositivo R1:
root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=35.3 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=3.01 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=2.65 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=2.87 ms
--- 1.1.1.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 2.650/10.970/35.338/14.069 msVitória. O túnel GRE foi estabelecido. O contador de tráfego de entrada nas estatísticas de IPsec não é zero:
root@Gate1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded
ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 3 (10.10.10.251,500)-(10.10.10.252,500) active 1474 1350
IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480No Gate2, na saída do klogview, apareceram mensagens de que o tráfego de destino 172.16.0.1-> 172.17.0.1 foi descriptografado com êxito (PASSA) (decapsulado) pela regra LIST no mapa criptográfico CMAP:
root@Gate2:~# klogview -f 0xffffffff
filtration result for in packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 18 "IPsecPolicy:CMAP", filter 25, event id IPsec:Protect:CMAP:1:LIST, status PASS
passed in packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: decapsulatedResultados O
aluno estragou o dia de folga.
Cuidado com as regras do ME.
Engenheiro anônimo
t.me/anonimous_engineer