Siguiente salto en una ruta VPN: por qué la puerta de enlace debe ser accesible localmente

Una ruta hacia una red VPN lleva dos direcciones fáciles de confundir: el prefijo de destino que el paquete intenta alcanzar y el siguiente salto que lo moverá un paso más cerca. En un host de LAN, ese siguiente salto tiene que ser un enrutador al que realmente pueda llegar en el mismo enlace. La dirección VPN remota no es un siguiente salto, por muy bien que encaje con el destino que tiene en mente.

Este manual cubre el caso habitual: un portátil en 192.168.20.0/24, una puerta de enlace VPN con dirección LAN 192.168.20.5 y una red remota 10.70.0.0/24 detrás de esa puerta. Todos los comandos siguientes suponen que está en el portátil, salvo que se indique lo contrario.

Dos direcciones, una ruta

La entrada prevista es 10.70.0.0/24 via 192.168.20.5. El prefijo dice a dónde va el paquete; la dirección via dice quién lo lleva allí. El núcleo se niega a instalar una ruta cuya puerta de enlace no puede alcanzar por la interfaz que usted nombra, y esa negativa es todo el punto: un siguiente salto que necesita el túnel para ser accesible no puede ser el siguiente salto que construye el túnel.

Así que la primera comprobación no es «funciona la puerta de enlace» sino «está la puerta de enlace en este enlace». La subred propia del portátil, su entrada ARP o de vecino y la interfaz de la ruta tienen que coincidir. Una dirección que solo existe dentro de 10.70.0.0/24 puede ser el destino de una segunda ruta, nunca la via de la primera.

A qué obliga el siguiente salto a la puerta de enlace

Instalar la ruta en el portátil solo decide la primera entrega. Después la puerta de enlace necesita su propio camino: reenvío activado, una ruta de túnel para 10.70.0.0/24 y cualquier política de acceso que rija quién puede usarla. En Linux eso es net.ipv4.ip_forward=1 más una ruta de túnel; un cortafuegos delante necesita una regla que permita el flujo reenviado.

La dirección de vuelta es la parte que la gente olvida. El lado remoto debe tener una ruta de vuelta a 192.168.20.0/24, o el diseño debe traducir el origen del portátil a algo que el lado remoto conozca. Un ping que funciona desde la puerta de enlace demuestra que la puerta puede alcanzar la red remota; no dice nada sobre si los paquetes del portátil sobreviven al viaje de vuelta.

Verifique la búsqueda desde el host que envía

Pregunte al núcleo qué siguiente salto elegiría y lea la interfaz en la respuesta:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Si la búsqueda informa de la puerta de enlace y la interfaz LAN, el primer tramo está configurado como se pretendía. Si informa del dispositivo de túnel, algo anterior en la tabla es más específico y gana. Si la ruta no se instala en absoluto, el núcleo le dice que la puerta de enlace no es accesible, y ese mensaje es más útil que cualquier captura de paquetes.

Luego repita la prueba desde el lugar correcto. Una petición creada en la puerta de enlace usa la dirección de origen propia de la puerta, lo que puede ocultar una ruta de vuelta ausente o una política que solo permite ciertos orígenes. El manual de ip-route separa el destino, la puerta de enlace y la anulación onlink, y vale la pena entender la anulación antes de usarla.

No use onlink para fingir accesibilidad

onlink le dice al núcleo que se salte la comprobación de accesibilidad de una puerta de enlace y le envíe de todos modos. No crea un camino, no resuelve ARP para una dirección que no está ni hace que un enrutador remoto responda en su segmento Ethernet. Es legítimo para puertas de enlace que responden pero no están en una subred conectada, y es una trampa cuando se usa para silenciar un error que no ha explicado.

Si la ruta solo se instala con onlink, la siguiente pregunta es por qué la puerta de enlace no está donde usted cree. Una VLAN equivocada, una segunda dirección en la interfaz equivocada o una errata en el último octeto producen esto, y cada una de ellas también rompe el camino de vuelta en cuanto el tráfico empieza a fluir.

Los túneles punto a punto no son Ethernet

Un dispositivo de túnel no hace ARP y a menudo no tiene una subred de vecinos con sentido. Sus rutas suelen parecerse a 10.70.0.0/24 dev tun0, sin ningún via, porque el par es el único otro extremo. Copiar un via al estilo LAN en esa tabla produce una ruta que el núcleo puede rechazar o, peor, una que apunta a una dirección a la que el par nunca responde.

Mantenga los dos modelos separados en el manual: una ruta LAN tiene una puerta de enlace accesible, una ruta de túnel tiene una interfaz y un par. WireGuard, OpenVPN e IPsec exponen formas ligeramente distintas, así que anote la forma que realmente usó en lugar de generalizar a partir de un solo host.

Añada, confirme, revierta

Todo el cambio son tres comandos y una comprobación, y debería escribirse en ese orden:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Confirme el camino, confirme un destino y luego tenga a mano la línea de borrado por si el cambio deja el host inaccesible de una forma que no previó. Si la ruta debe sobrevivir a un reinicio, póngala en la configuración de red del host y no en un perfil del shell, y pruebe el reinicio antes de confiar en ella. Una ruta que solo existe en el shell que la añadió es una ruta que depurará dos veces.