3.11. Resolución de problemas de configuración de VPN IPsec
Los problemas relacionados con las configuraciones de VPN IPsec suelen producirse por varias razones principales. Si se encuentra con este tipo de problemas, puede comprobar si la causa del problema se corresponde con alguno de los siguientes escenarios, y aplicar la solución correspondiente.
Solución de problemas básicos de conexión
La mayoría de los problemas con las conexiones VPN se producen en las nuevas implantaciones, en las que los administradores configuran los puntos finales con opciones de configuración que no coinciden. Además, una configuración que funciona puede dejar de hacerlo repentinamente, a menudo debido a valores incompatibles introducidos recientemente. Esto puede ser el resultado de que un administrador cambie la configuración. Alternativamente, un administrador puede haber instalado una actualización de firmware o una actualización de paquete con diferentes valores por defecto para ciertas opciones, como los algoritmos de cifrado.
Para confirmar que se ha establecido una conexión VPN IPsec:
# ipsec trafficstatus
006 #8: "vpn.example.com"[1] 192.0.2.1, type=ESP, add_time=1595296930, inBytes=5999, outBytes=3231, id='@vpn.example.com', lease=100.64.13.5/32Si la salida está vacía o no muestra una entrada con el nombre de la conexión, el túnel está roto.
Para comprobar que el problema está en la conexión:
Vuelva a cargar la conexión vpn.example.com:
# ipsec auto --add vpn.example.com 002 added connection description "vpn.example.com"A continuación, inicie la conexión VPN:
# ipsec auto --up vpn.example.com
Problemas relacionados con los cortafuegos
El problema más común es que un firewall en uno de los puntos finales de IPsec o en un router entre los puntos finales está dejando caer todos los paquetes de intercambio de claves de Internet (IKE).
Para IKEv2, una salida similar al siguiente ejemplo indica un problema con un firewall:
# ipsec auto --up vpn.example.com 181 "vpn.example.com"[1] 192.0.2.2 #15: initiating IKEv2 IKE SA 181 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: sent v2I1, expected v2R1 010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 0.5 seconds for response 010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 1 seconds for response 010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 2 seconds for ...Para IKEv1, la salida del comando de iniciación tiene el siguiente aspecto:
# ipsec auto --up vpn.example.com 002 "vpn.example.com" #9: initiating Main Mode 102 "vpn.example.com" #9: STATE_MAIN_I1: sent MI1, expecting MR1 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 0.5 seconds for response 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 1 seconds for response 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 2 seconds for response ...
Debido a que el protocolo IKE, que se utiliza para configurar IPsec, está encriptado, sólo puede solucionar un subconjunto limitado de problemas utilizando la herramienta tcpdump. Si un cortafuegos está dejando caer paquetes IKE o IPsec, puedes intentar encontrar la causa utilizando la utilidad tcpdump. Sin embargo, tcpdump no puede diagnosticar otros problemas con las conexiones VPN IPsec.
Para capturar la negociación de la VPN y todos los datos cifrados en la interfaz
eth0:# tcpdump -i eth0 -n -n esp or udp port 500 or udp port 4500 or tcp port 4500Algoritmos, protocolos y políticas no coincidentes
Las conexiones VPN requieren que los puntos finales tengan algoritmos IKE, algoritmos IPsec y rangos de direcciones IP que coincidan. Si se produce un desajuste, la conexión falla. Si identifica un desajuste mediante uno de los siguientes métodos, arréglelo alineando algoritmos, protocolos o políticas.
Si el extremo remoto no está ejecutando IKE/IPsec, puede ver un paquete ICMP indicándolo. Por ejemplo:
# ipsec auto --up vpn.example.com ... 000 "vpn.example.com"[1] 192.0.2.2 #16: ERROR: asynchronous network error report on wlp2s0 (192.0.2.2:500), complainant 198.51.100.1: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)] ...Ejemplo de algoritmos IKE no coincidentes:
# ipsec auto --up vpn.example.com ... 003 "vpn.example.com"[1] 193.110.157.148 #3: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,NiEjemplo de algoritmos IPsec no coincidentes:
# ipsec auto --up vpn.example.com ... 182 "vpn.example.com"[1] 193.110.157.148 #5: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_256 group=MODP2048} 002 "vpn.example.com"[1] 193.110.157.148 #6: IKE_AUTH response contained the error notification NO_PROPOSAL_CHOSENUna versión de IKE que no coincida también puede hacer que el punto final remoto abandone la solicitud sin respuesta. Esto parece idéntico a un cortafuegos que abandona todos los paquetes IKE.
Ejemplo de rangos de direcciones IP no coincidentes para IKEv2 (llamados selectores de tráfico - TS):
# ipsec auto --up vpn.example.com ... 1v2 "vpn.example.com" #1: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048} 002 "vpn.example.com" #2: IKE_AUTH response contained the error notification TS_UNACCEPTABLEEjemplo de rangos de direcciones IP no coincidentes para IKEv1:
# ipsec auto --up vpn.example.com ... 031 "vpn.example.com" #2: STATE_QUICK_I1: 60 second timeout exceeded after 0 retransmits. No acceptable response to our first Quick Mode message: perhaps peer likes no proposalCuando se utilizan PreSharedKeys (PSK) en IKEv1, si ambas partes no ponen la misma PSK, todo el mensaje IKE se vuelve ilegible:
# ipsec auto --up vpn.example.com ... 003 "vpn.example.com" #1: received Hash Payload does not match computed value 223 "vpn.example.com" #1: sending notification INVALID_HASH_INFORMATION to 192.0.2.23:500En IKEv2, el error de PSK no coincidente resulta en un mensaje AUTHENTICATION_FAILED:
# ipsec auto --up vpn.example.com ... 002 "vpn.example.com" #1: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED
Unidad máxima de transmisión
Aparte de los cortafuegos que bloquean los paquetes IKE o IPsec, la causa más común de los problemas de red está relacionada con el aumento del tamaño de los paquetes cifrados. El hardware de red fragmenta los paquetes más grandes que la unidad de transmisión máxima (MTU), por ejemplo, 1500 bytes. A menudo, los fragmentos se pierden y los paquetes no se vuelven a ensamblar. Esto provoca fallos intermitentes, cuando una prueba de ping, que utiliza paquetes de pequeño tamaño, funciona pero el resto del tráfico falla. En este caso, se puede establecer una sesión SSH pero el terminal se congela en cuanto se utiliza, por ejemplo, introduciendo el comando 'ls -al /usr' en el host remoto.
Para solucionar el problema, reduzca el tamaño de la MTU añadiendo la opción mtu=1400 al archivo de configuración del túnel.
Alternativamente, para las conexiones TCP, active una regla iptables que cambie el valor de MSS:
# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Si el comando anterior no resuelve el problema en su escenario, especifique directamente un tamaño menor en el parámetro set-mss:
# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380Traducción de direcciones de red (NAT)
Cuando un host IPsec también sirve como router NAT, podría reasignar accidentalmente los paquetes. El siguiente ejemplo de configuración demuestra el problema:
conn myvpn
left=172.16.0.1
leftsubnet=10.0.2.0/24
right=172.16.0.2
rightsubnet=192.168.0.0/16
…El sistema con dirección 172.16.0.1 tiene una regla NAT:
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Si el sistema en la dirección 10.0.2.33 envía un paquete a 192.168.0.1, el router traduce la fuente 10.0.2.33 a 172.16.0.1 antes de aplicar el cifrado IPsec.
Entonces, el paquete con la dirección de origen 10.0.2.33 ya no coincide con la configuración de conn myvpn, e IPsec no cifra este paquete.
Para resolver este problema, inserte reglas que excluyan NAT para los rangos de subred IPsec de destino en el router, en este ejemplo:
iptables -t nat -I POSTROUTING -s 10.0.2.0/24 -d 192.168.0.0/16 -j RETURN
Errores en el subsistema IPsec del kernel
El subsistema IPsec del kernel puede fallar, por ejemplo, cuando un error provoca una desincronización del espacio de usuario de IKE y del kernel IPsec. Para comprobar este tipo de problemas:
$ cat /proc/net/xfrm_stat
XfrmInError 0
XfrmInBufferError 0
...Cualquier valor distinto de cero en la salida del comando anterior indica un problema. Si encuentra este problema, abra un nuevo caso de soporte, y adjunte la salida del comando anterior junto con los registros de IKE correspondientes.
Registros de Libreswan
Libreswan registra utilizando el protocolo syslog por defecto. Puedes utilizar el comando journalctl para encontrar entradas de registro relacionadas con IPsec. Como las entradas correspondientes al registro son enviadas por el demonio IKE de pluto, busque la palabra clave "pluto", por ejemplo:
$ journalctl -b | grep pluto
Para mostrar un registro en vivo para el servicio ipsec:
$ journalctl -f -u ipsec
Si el nivel de registro por defecto no revela su problema de configuración, active los registros de depuración añadiendo la opción plutodebug=all a la sección config setup del archivo /etc/ipsec.conf.
Tenga en cuenta que el registro de depuración produce muchas entradas, y es posible que el servicio journald o syslogd limite la velocidad de los mensajes syslog. Para asegurarse de que tiene registros completos, redirija el registro a un archivo. Edita el /etc/ipsec.conf, y añade el logfile=/var/log/pluto.log en la sección config setup.
Recursos adicionales
- Solución de problemas mediante archivos de registro
- Uso y configuración de firewalld
-
tcpdump(8)yipsec.conf(5)páginas man
