Una puerta de enlace VPN necesita reenvío IP: qué comprobar

Su cliente puede hacer ping a la dirección de la puerta de enlace mientras todos los recursos que hay detrás siguen inaccesibles. Ese par de observaciones describe un host que le habla y un enrutador que no enruta, que son papeles distintos en la misma máquina. El reenvío es el interruptor entre ambos.

Los dos papeles son independientes, y también las dos familias de direcciones.

Responder a su propia dirección no demuestra nada

Cuando un paquete se dirige a la propia puerta de enlace, la pila local lo consume y no se toma ninguna decisión de reenvío. Por eso un ping correcto a la dirección del túnel o a una interfaz de gestión le dice que el demonio está vivo y el túnel levantado, pero no dice nada sobre el tráfico destinado a una red detrás de la caja. El núcleo solo consulta su ruta de reenvío para paquetes que no van dirigidos a él.

Lea el requisito como un papel, no como un ajuste: este host debe mover paquetes entre dos interfaces. Un portátil que solo necesita llegar a una red remota nunca asume ese papel, y un extremo sitio a sitio siempre lo hace. Leer el requisito así explica por qué una configuración de cliente que funciona falla cuando se traslada a una puerta de enlace.

La misma frase se aplica al cortafuegos situado delante de la decisión de reenvío, que tiene su propia política sobre qué se puede reenviar.

Compruebe cada familia de direcciones por separado

El reenvío IPv4 es un interruptor, y el reenvío IPv6 es otro con su propio comportamiento por interfaz. Activar el primero no dice nada del segundo, y un cliente de doble pila puede alcanzar media red mientras el resto queda a oscuras. Dos clientes de familias distintas pueden, por tanto, discrepar sobre la misma puerta de enlace. Pregunte qué familia usó el cliente que falla antes de editar cualquiera de los dos ajustes. Confirme ambos antes de concluir que el diseño de enrutamiento es incorrecto.

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

En muchas distribuciones, el valor que lee en tiempo de ejecución lo puso allí un servicio o un archivo de configuración, así que un cambio hecho con un comando puntual puede desaparecer al reiniciar. Encuentre el archivo que posee el ajuste antes de editar el valor en tiempo de ejecución.

El reenvío es uno de cuatro requisitos

Un flujo reenviado que funciona necesita cuatro cosas a la vez: el cliente debe saber que el destino está detrás del túnel, la puerta de enlace debe tener una ruta hacia delante, las respuestas deben tener un camino de vuelta y el cortafuegos debe permitir el tráfico. La traducción de origen pertenece a ese diseño como opción y no como regla, porque una red enrutada privada con caminos simétricos no la necesita y una asimétrica normalmente sí. Cada una de las cuatro falla de forma independiente, por eso reparar una rara vez mueve el síntoma. Escriba las cuatro antes de cambiar cualquiera de ellas.

Las plataformas de nube añaden una quinta consideración. Algunas aplican comprobaciones de origen y destino en las instancias, lo que descarta los paquetes reenviados independientemente de cómo esté configurado el núcleo del invitado. La documentación de red de la propia plataforma es la autoridad allí, no la salida de sysctl dentro de la VM.

Pruebe desde el cliente, no desde la puerta de enlace

Una prueba ejecutada en el propio intérprete de la puerta de enlace no recorre ninguna parte de la ruta de reenvío que acaba de habilitar. Genere el tráfico desde el cliente que tiene el problema y confirme que llega a algo detrás de la puerta de enlace y no a la puerta de enlace misma. Esa es la única prueba que ejercita el papel que cambió.

Mantenga separadas las reglas de escucha y las reglas de reenvío en su cabeza y en el registro de cambios. Abrir el puerto VPN admite clientes al servicio; no les concede nada en la red que hay detrás, y ambos parecen idénticos en una lista de cortafuegos que ha crecido durante años.

Si los paquetes llegan y el servicio luego rechaza al usuario, ya ha pasado de la red. Continúe con la autorización de la aplicación en lugar de ampliar de nuevo la política de reenvío.