ProHoster > Blog > Administração > Como solucionar problemas de VPN IPsec nacional. Parte 1

Como solucionar problemas de VPN IPsec nacional. Parte 1

Como solucionar problemas de VPN IPsec nacional. Parte 1

Situação

Feriado. Estou tomando café. O estudante configurou uma conexão VPN entre dois pontos e desapareceu. Verifico: o túnel realmente existe, mas não há tráfego no túnel. O estudante não atende as chamadas.

Coloco a chaleira para aquecer e me aprofundo na solução de problemas do S-Terra Gateway. Compartilho minha experiência e metodologia.

Dados de origem

Duas plataformas geograficamente separadas estão conectadas por um túnel GRE. É necessário criptografar o GRE:

Como solucionar problemas de VPN IPsec nacional. Parte 1

Verifico a funcionalidade do túnel GRE. Para isso, executo um ping do dispositivo R1 até a interface GRE do dispositivo R2. Este é o tráfego alvo para criptografia. Não recebo resposta:

root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.

--- Estatísticas de ping 1.1.1.2 ---
4 pacotes transmitidos, 0 recebidos, 100% de perda de pacote, tempo 3057ms

Vejo os logs no Gate1 e Gate2. O log informa com alegria que o túnel IPsec foi estabelecido com sucesso, sem problemas:

root@Gate1:~# cat /var/log/cspvpngate.log
5 de Aug 16:14:23 localhost vpnsvc: 00100119  Conexão IPSec 5 estabelecida, seletor de tráfego 172.17.0.1->172.16.0.1, proto 47, peer 10.10.10.251, id "10.10.10.251", Filtro 
IPsec:Protect:CMAP:1:LIST, Ação IPsec Ação:CMAP:1, Regra IKE Regra:CMAP:1

Nas 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
Sessões ISAKMP: 0 iniciadas, 0 respondidas

Conexões ISAKMP:
Num Conn-id (Endereço Local, Porta)-(Endereço Remoto, Porta) Estado Enviado Recebido
1 3 (10.10.10.251,500)-(10.10.10.252,500) ativo 1070 1014

Conexões IPsec:
Num Conn-id (Endereço Local, Porta)-(Endereço Remoto, Porta) Protocolo Ação Tipo Enviado Recebido
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP túnel 480 0

Estou solucionando problemas no S-Terra assim: procuro onde os pacotes alvo estão se perdendo no caminho de R1 até R2. No processo (spoiler) encontrarei um erro.

Solução de Problemas

Passo 1. O que o Gate1 recebe de R1

Uso o analisador de pacotes integrado - tcpdump. Início do analisador na interface interna (Gi0/1 na notação como Cisco ou eth1 na notação do OS Debian):

root@Gate1:~# tcpdump -i eth1

tcpdump: saída detalhada suprimida, use -v ou -vv para decodificação completa do protocolo
ouvindo em eth1, tipo de link EN10MB (Ethernet), tamanho de captura 262144 bytes
14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, chave=0x1, comprimento 92: IP 1.1.1.1 > 1.1.1.2: solicitação de eco ICMP, id 2083, seq 1, comprimento 64
14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, chave=0x1, comprimento 92: IP 1.1.1.1 > 1.1.1.2: solicitação de eco ICMP, id 2083, seq 2, comprimento 64
14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, chave=0x1, comprimento 92: IP 1.1.1.1 > 1.1.1.2: solicitação de eco ICMP, id 2083, seq 3, comprimento 64
14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, chave=0x1, comprimento 92: IP 1.1.1.1 > 1.1.1.2: solicitação de eco ICMP, id 2083, seq 4, comprimento 64

Vejo que o Gate1 recebe pacotes GRE de R1. Vou em frente.

Passo 2. O que o Gate1 faz com os pacotes GRE

Usando a ferramenta klogview, verifico o que acontece com os pacotes GRE internamente VPN no driver do S-Terra:

root@Gate1:~# klogview -f 0xffffffff

resultado da filtragem para pacote de saída 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: cadeia 4 "IPsecPolicy:CMAP", filtro 8, id do evento IPsec:Protect:CMAP:1:LIST, status PASS
encapsulando com SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0
pacote de saída passado 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: encapsulado

Vejo que o tráfego GRE (proto 47) de 172.16.0.1 -> 172.17.0.1 passou (PASS) pela regra de criptografia LIST no mapa de criptografia CMAP e foi criptografado (encapsulado). Em seguida, o pacote foi roteado (passado). Não há tráfego de retorno na saída do klogview.

Verificando as listas de acesso no dispositivo Gate1. Vejo uma lista de acesso LIST que define o tráfego-alvo para criptografia, portanto, não há regras de política de criptografia configuradas:

Gate1#show access-lists
Lista de acesso IP estendida LIST
    10 permitir gre host 172.16.0.1 host 172.17.0.1

Conclusão: o problema não está no dispositivo Gate1.

Informações adicionais sobre klogview

O driver VPN processa todo o tráfego de rede, não apenas aquele que deve ser criptografado. Mensagens como essa podem ser vistas no klogview, se o driver VPN processou o tráfego de rede e o enviou em texto claro:

root@R1:~# ping 172.17.0.1 -c 4

root@Gate1:~# klogview -f 0xffffffff

resultado da filtragem para pacote de saída 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: cadeia 4 "IPsecPolicy:CMAP": sem correspondência
pacote de saída passado 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: filtrado

Vejo que o tráfego ICMP (proto 1) de 172.16.0.1->172.17.0.1 não passou (sem correspondência) pelas regras de criptografia do mapa de criptografia CMAP. O pacote foi roteado (passado) em texto claro.

Passo 3. O que o Gate2 recebe do Gate1

Iniciando o sniffer na interface WAN (eth0) do Gate2:

root@Gate2:~# tcpdump -i eth0
tcpdump: saída detalhada suprimida, use -v ou -vv para decode completo do protocolo
ouvindo na eth0, tipo de link EN10MB (Ethernet), tamanho da captura 262144 bytes
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), comprimento 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), comprimento 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), comprimento 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), comprimento 140

Vejo que o Gate2 está recebendo pacotes ESP do Gate1.

Passo 4. O que o Gate2 faz com os pacotes ESP

Iniciando a ferramenta klogview no Gate2:

root@Gate2:~# klogview -f 0xffffffff
resultado da filtragem para pacote de entrada 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: cadeia 17 "FilterChain:L3VPN", filtro 21, status DROP
pacote de entrada dropado 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. Verifico se a lista de acesso L3VPN está realmente vinculada ao Gi0/0:

Gate2#show ip interface gi0/0
GigabitEthernet0/0 está ativo, protocolo de linha está ativo
  Endereço da Internet é 10.10.10.252/24
  MTU é 1500 bytes
  Lista de acesso de saída não está configurada
  Lista de acesso de entrada é L3VPN

Identifiquei o problema.

Passo 5. O que há de errado com a lista de acesso

Vou conferir o que é 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 any

Vejo que pacotes ISAKMP estão permitidos, portanto, o túnel IPsec está sendo estabelecido. Mas não há regra permissiva para ESP. Provavelmente, o aluno confundiu icmp e esp.

Estou corrigindo a lista de acesso:

Gate2(config)#
ip access-list extended L3VPN
no 30
30 permit esp host 10.10.10.251 any

Passo 6. Verifico a funcionalidade

Primeiro, verifico se 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 any

Agora, do dispositivo R1, inicio o tráfego de destino:

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 ms

Vitória. O túnel GRE foi estabelecido. O contador de tráfego de entrada nas estatísticas do 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 480

No gateway Gate2, mensagens apareceram na saída do klogview indicando que o tráfego de destino 172.16.0.1->172.17.0.1 foi decifrado com sucesso (PASS) 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: decapsulated

Resultados

O aluno estragou a saída.
Tenha cuidado com as regras da MЭ.

Engenheiro anônimo
t.me/anonimous_engineer

Fonte: habr.com

Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS 🔥 Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS | ProHoster