¿Ruta VPN o regla de cortafuegos: cuál está descartando el paquete?

Dos decisiones independientes ocurren sobre el mismo paquete, y cualquiera de ellas puede terminar la solicitud en silencio. La consulta de enrutamiento elige una interfaz y un salto siguiente, luego el filtro de paquetes decide si esa combinación está permitida. Un tiempo de espera le dice que una de las dos se negó, no cuál. Recorra las etapas en orden y la reparación suele dejar de ser una conjetura.

Dos decisiones, un paquete, dos dueños

La consulta de enrutamiento consulta primero las reglas de política, después la tabla a la que apuntan, y elige el prefijo más específico que coincide con el destino. Un cliente que instaló una ruta de túnel posee esa decisión, y nada en una regla de cortafuegos puede sustituirla. Cuando la consulta apunta a un lugar inesperado, cada etapa posterior trabaja sobre el paquete equivocado.

El filtrado es aparte. En un host Linux, los ganchos de netfilter dividen el tráfico según para quién es el paquete: la salida abandona la máquina, la entrada termina en ella, el reenvío la atraviesa. Una puerta de enlace que acepta clientes VPN y los enruta a una LAN necesita la ruta de reenvío, y es exactamente la cadena que la mayoría de las configuraciones por defecto dejan vacía.

La selección de origen pertenece a la misma decisión, y es donde se esconden la mayoría de los desajustes. El núcleo elige una dirección de origen de la interfaz de salida a menos que la ruta nombre una, así que una regla de filtro escrita para la subred LAN nunca coincide con un paquete que sale con la dirección del túnel.

Lea lo que la consulta eligió realmente

Imprima la decisión en lugar de inferirla. El comando siguiente resuelve la ruta que el núcleo usaría para ese destino, incluida la interfaz y el origen que elegiría:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

Los clientes VPN suelen instalar reglas de política en prioridades por debajo de la tabla principal, así que una tabla principal limpia no demuestra nada por sí sola. Compare las prioridades de las reglas con las tablas que eligen, y compruebe si la ruta del túnel sobrevive a una reconexión en lugar de añadirse a mano una vez.

El IPsec basado en políticas añade una tercera etapa de coincidencia que el enrutamiento no cubre, como describen las notas de reenvío de strongSwan para configuraciones de túnel y transporte. La política de seguridad selecciona el tráfico por prefijo y protocolo, mientras que la ruta solo decide adónde iría un paquete sin protección. Una subred que se enruta pero no tiene selector coincidente o bien queda sin protección o bien se descarta, según la configuración, y ninguno de los dos resultados parece un problema de cortafuegos. Imprima la política y compare sus selectores con los prefijos que esperaba que llevara el túnel.

El filtrado se aplica en un gancho, no en una ruta

Una regla que permite el oyente VPN es una regla sobre tráfico dirigido a la propia puerta de enlace. No dice nada sobre los clientes que llegan a hosts detrás de esa puerta, porque el tráfico reenviado atraviesa una cadena distinta. Leer el conjunto de reglas como una lista plana es la razón habitual de que una regla que parece correcta nunca se active.

Los contadores resuelven la cuestión rápido. Una regla con un recuento de paquetes cero nunca se alcanzó, lo que apunta a la cadena equivocada, la interfaz equivocada o un descarte anterior. Una regla con un recuento creciente bajo una política de descarte es el límite que buscaba, y el paquete se descarta en lugar de enrutarse mal.

Envíe una sonda por el camino que usa el cliente

Las pruebas ejecutadas en la propia puerta de enlace viajan por salida y entrada, con la dirección de origen propia de la puerta. Es un camino distinto del de la solicitud reenviada de un cliente, así que un curl local exitoso demuestra menos de lo que parece. Pruebe desde la máquina que falla, o fije explícitamente la interfaz y el origen.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

Una captura en ambos extremos separa los casos restantes. Un SYN que sale del cliente y nunca llega significa enrutamiento, cifrado o una lista de acceso aguas arriba. Un SYN que llega y no obtiene respuesta significa el servicio o su filtro de host, y el túnel nunca fue el problema.

El tráfico de retorno merece su propia mirada. El enrutamiento asimétrico más el filtrado de ruta inversa descartan las respuestas que llegan por la interfaz equivocada, lo que se ve como una conexión unidireccional en lugar de un puerto bloqueado. Compruebe el valor de sysctl antes de culpar al cortafuegos de un síntoma que no causó.

El registro funciona como una segunda opinión, no como un primer paso. Una declaración de registro temporal en la cadena de reenvío nombra la interfaz y las direcciones que la golpearon, y es fácil de quitar después. Déjela de forma permanente y habrá construido un problema de volumen de registros en lugar de una respuesta.

Coloque cada cambio donde sobreviva a una reconexión

Una ruta añadida con ip route add vive hasta que la interfaz se cae. Guárdela en el perfil de conexión: NetworkManager acepta rutas adicionales en la conexión, y netplan las conserva entre arranques. La misma regla se aplica a una excepción de cortafuegos del lado del cliente, que desaparece tras la siguiente recarga.

Las reglas del lado del servidor pertenecen al archivo de configuración que el servicio carga al iniciar, no a una sesión interactiva que termina cuando la cierra. Escriba la regla, recargue y confirme que el contador se movió, porque una recarga que rechazó la sintaxis deja el conjunto de reglas antiguo en su sitio en silencio.

Luego repita la solicitud original de la aplicación de principio a fin y anote qué capa cambió. Una corrección de ruta que también necesitaba un cambio de filtro seguirá fallando, y el segundo fallo se lee mucho más fácilmente cuando sabe que el primero desapareció. Anote la fecha y la versión del cliente junto al resultado, ya que los valores por defecto de enrutamiento y filtrado se mueven entre versiones. Mantenga esa nota en el ticket para que la siguiente persona empiece donde usted se detuvo en lugar de repetir el recorrido de dos etapas.