Router LAN máis cliente VPN: dous dispositivos, dúas táboas de rutas

Dous dispositivos reenvían o paquete e cada un mantén a súa propia táboa. O router LAN sabe que o prefixo remoto pertence ao cliente VPN, e o cliente VPN sabe como chegar a ese prefixo a través do seu túnel. Configura só a primeira táboa e o paquete chega a unha máquina que non ten ningunha ruta coincidente, así que volve saír pola predeterminada. Ese é todo o fallo, e desde o lado da LAN parece un bucle de enrutamento porque case o é.

Debuxa os dous saltos antes de tocar unha ruta

Toma un deseño ilustrativo: hosts da LAN en 192.168.50.0/24, o router normal en 192.168.50.1, un cliente dedicado en 192.168.50.15 e unha LAN remota en 10.60.0.0/24 accesible só a través do túnel que mantén ese cliente. Ningún dos dous rangos privados se solapa co outro, e o túnel ten o seu propio plan de enderezos.

Ambos os rangos privados importan porque deciden que dispositivo pode responder. O lado remoto verá chegar o paquete desde o enderezo de túnel do cliente, e a súa resposta ten que atopar un camiño de volta a 192.168.50.0/24. Se só se configura a dirección de saída, a petición pode funcionar mentres a resposta desaparece.

Paso 1: apunta o router ao cliente, non ao túnel

No router LAN, engade unha ruta de destino cuxo seguinte salto sexa o enderezo LAN do cliente:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Ese rexistro di «entrégao á máquina que pode facer túnel». Non di nada sobre como se constrúe o túnel, e non substitúe a ruta propia do cliente. Nun router xestionado o equivalente vive na páxina de rutas estáticas do dispositivo; nun router Linux pertence á configuración da interface que posúe a LAN, non a un shell que vas pechar.

Comproba a resposta do segundo comando. Se informa o cliente como gateway e a interface LAN como device, o primeiro salto é correcto e o traballo restante está na outra máquina.

Paso 2: dálle ao cliente unha ruta propia do lado do túnel

O cliente agora recibe un paquete para 10.60.0.0/24 e consulta a súa propia táboa. Se a súa configuración de túnel instalou unha ruta para ese prefixo, o paquete continúa cifrado. Se non o fixo, o paquete coincide coa predeterminada normal e volve a 192.168.50.1, que o envía outra vez ao cliente.

Mira antes de engadir nada:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Unha ruta de prefixo ausente en todas as táboas é o achado que buscas. Engádea a través da configuración propia do túnel, para que a próxima reconexión a reinstale; unha ip route add manual desaparece coa sesión e fai que o fallo volva no momento menos oportuno. O seguinte salto é a interface de túnel ou o enderezo que a VPN asigna como o seu par, segundo o cliente, e o enderezo do par debería vir do perfil actual e non dunha nota antiga.

O bucle, cando ocorre, non é infinito na práctica: o TTL baixa en cada paso e o paquete morre cunha mensaxe de tempo excedido. Por iso un traceroute repetido pode suxerir un ciclo mentres un cliente que simplemente non reenvía deixa caer o mesmo paquete en silencio.

Paso 3: permite o reenvío e escolle a ruta de volta

Recibir e reenviar son permisos distintos. net.ipv4.ip_forward=1 no cliente permite o tránsito a nivel de núcleo, e unha regra de cortafuegos aínda ten que permitilo entre a interface LAN e o túnel. Unha regra que permite o acceso á páxina de xestión do propio cliente non permitirá o tránsito cara á LAN remota, e a distinción é fácil de pasar por alto cando o mesmo host responde a pings localmente.

O lado remoto ten o problema espello. Debe saber que 192.168.50.0/24 é accesible a través deste cliente autenticado. Con OpenVPN iso normalmente significa unha ruta por cliente empuxada pola configuración do servidor, ou un ficheiro específico do cliente no servidor que declara a LAN detrás do cliente. Sen iso, a LAN remota ou descarta a resposta ou a envía á súa propia pasarela predeterminada, que é internet.

A tradución de orixe é a alternativa cando o prefixo da LAN non se pode anunciar. Unha regra de masquerade con alcance no cliente reescribe a orixe ao enderezo do túnel, e as respostas volven entón de forma natural. Tamén oculta que host da LAN fixo a petición, e por si soa non permite ao lado remoto iniciar conexións cara a dentro. Escolle ese compromiso a propósito en lugar de engadir un masquerade global e descubrir o efecto secundario máis tarde.

Paso 4: fai persistentes ambas as decisións e despois proba a ruta real

Cada ruta ten un dono, e o dono é a configuración que se rexenera ao arrincar ou ao reconectar. No router pode ser unha entrada de ruta estática; no cliente pode ser o perfil VPN, NetworkManager ou systemd-networkd. Verifica reconectando o túnel e reiniciando o cliente, e despois le a táboa de novo en lugar de confiar na edición.

Mantén intacta a ruta predeterminada que transporta a conexión exterior do túnel. Substituíla para «simplificar» a configuración rompe a ruta cifrada antes de que ningún tráfico interior poida usala, e o síntoma é un túnel que nunca se restablece despois do cambio.

Proba desde un host LAN corrente, non desde o cliente, porque unha petición orixinada no cliente nunca exercita o primeiro salto do router. Obtén un servizo que exista só na LAN remota e confirma o corpo da resposta, e despois mira os contadores ou os rexistros do cliente para ver o tránsito. Un traceroute interior que mostra saltos privados demostra o reenvío, non o cifrado: a ruta exterior é unha observación aparte, e só os contadores da interface do túnel mostran que saíu por el.