ProHoster > Blog > Administración > Como solucionar problemas de VPN IPsec doméstica. Parte 1

Como solucionar problemas de VPN IPsec doméstica. Parte 1

Como solucionar problemas de VPN IPsec doméstica. Parte 1

A situación

Día libre. Tomo café. O estudante estableceu unha conexión VPN entre dous puntos e desapareceu. Comprobo: realmente hai un túnel, pero non hai tráfico no túnel. O alumno non responde ás chamadas.

Puxen a chaleira e mergullo na solución de problemas de S-Terra Gateway. Comparto a miña experiencia e metodoloxía.

Datos iniciais

Os dous sitios separados xeograficamente están conectados por un túnel GRE. GRE debe estar cifrado:

Como solucionar problemas de VPN IPsec doméstica. Parte 1

Estou comprobando a funcionalidade do túnel GRE. Para iso, executo ping desde o dispositivo R1 ata a interface GRE do dispositivo R2. Este é o tráfico obxectivo para o cifrado. Sen 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 3057ms

Miro os rexistros de Gate1 e Gate2. O rexistro informa felizmente de que o túnel IPsec foi lanzado con éxito, sen 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:1

Nas estatísticas do túnel IPsec en Gate1 vexo que realmente hai un túnel, pero o contador Rсvd restablece a cero:

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 0

Problema S-Terra así: busco onde se perden os paquetes de destino no camiño de R1 a R2. No proceso (spoiler) atoparei un erro.

Solución de problemas

Paso 1. Que recibe Gate1 de R1

Eu uso o rastreador de paquetes integrado - tcpdump. Lanzo o sniffer na interface interna (Gi0/1 en notación similar a Cisco ou eth1 en notación 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 64

Vexo que Gate1 recibe paquetes GRE de R1. Estou avanzando.

Paso 2. Que fai Gate1 cos paquetes GRE

Usando a utilidade klogview podo ver o que está a suceder cos paquetes GRE dentro do controlador VPN S-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

Vexo que o tráfico GRE obxectivo (proto 47) 172.16.0.1 -> 172.17.0.1 estaba baixo a regra de cifrado LIST no mapa criptográfico CMAP e estaba encapsulado. A continuación, o paquete foi encamiñado (pasado). Non hai tráfico de resposta na saída de klogview.

Estou comprobando as listas de acceso no dispositivo Gate1. Vexo unha lista de acceso LIST, que define o tráfico de destino para o cifrado, o que significa que as regras do firewall non están configuradas:

Gate1#show access-lists
Extended IP access list LIST
    10 permit gre host 172.16.0.1 host 172.17.0.1

Conclusión: o problema non é co dispositivo Gate1.

Máis información sobre klogview

O controlador VPN xestiona todo o tráfico de rede, non só o que debe cifrarse. Estas son as mensaxes visibles en klogview se o controlador VPN procesou o tráfico da rede e o transmitiu sen cifrar:

root@R1:~# ping 172.17.0.1 -c 4

root@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: filtered

Vexo que o tráfico ICMP (proto 1) 172.16.0.1->172.17.0.1 non se incluíu (sen coincidencia) nas regras de cifrado da tarxeta criptográfica CMAP. O paquete foi encamiñado (pasado) en texto claro.

Paso 3. O que Gate2 recibe de Gate1

Lanzo o sniffer na interface Gate0 WAN (eth2):

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 140

Vexo que Gate2 recibe paquetes ESP de Gate1.

Paso 4. Que fai Gate2 cos paquetes ESP

Lanzo a utilidade klogview en 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

Vexo que os paquetes ESP (proto 50) foron eliminados (DROP) pola regra do firewall (L3VPN). Asegúrome de que Gi0/0 ten unha lista de acceso L3VPN adxunta:

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 L3VPN

Descubrín o problema.

Paso 5. Que hai de malo coa lista de acceso

Miro cal é a lista de acceso 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

Vexo que os paquetes ISAKMP están permitidos, polo que se establece un túnel IPsec. Pero non hai ningunha regra de habilitación para ESP. Ao parecer, o alumno confundiu icmp e esp.

Editando a lista de acceso:

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

Paso 6. Comprobación da funcionalidade

En primeiro lugar, asegúrese de que a lista de acceso L3VPN é correcta:

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 lanzo o tráfico de destino desde o 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 ms

Vitoria. Estableceuse o túnel GRE. O contador de tráfico entrante nas estatísticas IPsec non é cero:

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

Na pasarela Gate2, na saída de klogview, apareceron mensaxes de que o tráfico de destino 172.16.0.1->172.17.0.1 foi descifrado correctamente (PASS) pola 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 de

Un estudante estragou o seu día libre.
Teña coidado coas regras de ME.

Enxeñeiro anónimo
t.me/enxeñeiro_anónimo

Fonte: www.habr.com

Engadir un comentario