Cliente VPN nun servidor LAN: por que as respostas saen polo camiño equivocado

Os síntomas seguen unha mesma forma: un host funciona, despois conecta a unha VPN como cliente e agora os clientes LAN alcánzano mentres as súas respostas desaparecen. Unha captura no host mostra que as respostas saen polo dispositivo do túnel en lugar da interface LAN. Nada do túnel está roto, e a solución é unha ruta, non unha reconexión. Percorra as catro comprobacións seguintes en orde e detéñase na primeira que falle.

Unha resposta é un paquete novo, non unha reversión

Axuda descartar a idea de que unha resposta volve polo camiño que tomou unha petición. O encamiñamento decídese por paquete, por dirección, no host emisor. Unha petición que chegou de 10.64.0.23 dentro do túnel non crea ningún camiño de retorno; cando o host responde, esa resposta compárase coa táboa como un paquete novo e sae pola ruta que gañe.

Por iso un cliente de túnel completo nunha máquina que tamén serve unha LAN produce un fallo tan confuso. O cliente instala unha ruta predeterminada, ou as dúas medias rutas predeterminadas que prefiren algúns clientes, e a resposta a un cliente LAN agora coincide co túnel. Vai ao provedor, que non ten motivo para reenviala, e o cliente LAN ve un tempo de espera aínda que o host está activo e responde localmente. A captura faino obvio, e a táboa de encamiñamento explícao.

Manteña dúas subredes na cabeza mentres le o resto. Unha é o conxunto de enderezos VPN do que veñen os clientes remotos, neste exemplo 10.64.0.0/24. A outra é a LAN que debe seguir funcionando, 172.16.24.0/24 co seu router en 172.16.24.1. O erro é que o tráfico entre elas decídeo a ruta predeterminada.

Demóstroo coa captura e a consulta

Antes de cambiar nada, confirme que dispositivo usará a resposta. Unha consulta é máis rápida que unha captura e responde exactamente a pregunta que responderá o núcleo cando se constrúa o paquete.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Lea a resposta en dúas partes. Se nomea dev tun0, o host encapsulará a resposta e entregaraa ao provedor, e o cliente LAN nunca a verá. Se nomea dev eth0 pero o cliente segue esgotando o tempo, a ruta xa é correcta e o paquete descártase máis tarde, que é outro problema con outra solución.

A captura no mesmo paso resolve a dúbida que un ping non pode. Un eco de resposta que chega ao cliente LAN demostra que algún camiño funciona, non que interface o levou, así que faga a captura no propio host e observe por onde saen as tramas. Unha impresora na mesma subrede segue respondendo, porque a súa ruta directa é máis específica que a ruta predeterminada do túnel. Un porto reenviado falla igual que calquera outro fluxo, porque a táboa elixe a interface e a conexión non.

Instale a ruta máis específica que supere o túnel

Decide a lonxitude do prefixo, non a métrica, así que unha ruta para o conxunto de clientes a través do router LAN gaña a calquera ruta predeterminada que instale o cliente VPN. Non fai falta cirurxía de métricas, e a ruta predeterminada pode quedarse exactamente onde o cliente a puxo.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Use replace en lugar de add, porque un cliente que se reconecte terá instalado a súa propia entrada e un segundo add falla cun erro de ruta existente que se le como un problema de permisos. Nun host Windows o equivalente é route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, onde -p mantén a entrada entre reinicios, xa que o cliente pode reconstruír a táboa cando o túnel volve subir. Nun host Windows actual o equivalente admitido é New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, co comando route máis antigo conservado como forma herdada.

Un detalle decide se isto é correcto ou só verosímil: o seguinte salto ten que ser o router que realmente posúe o camiño de volta aos clientes. Apuntar a ruta a un enderezo ao que se chega precisamente polo túnel crea un bucle que se manifesta como perda intermitente en lugar dun fallo limpo. Confirme que o seguinte salto está na subrede LAN antes de confirmar a liña.

Manteña a resposta tras unha reconexión

Unha ruta engadida a man sobrevive como moito ata a seguinte reconexión. Se o conxunto de clientes é dinámico, fíxoo na configuración do servidor para que o prefixo que encamiñou siga sendo o prefixo que reciben os clientes; doutro xeito a entrada apunta a un rango baleiro e o síntoma volve semanas despois sen causa evidente. Escribir a ruta no propio script up do cliente é a outra opción fiable, porque se executa despois de que o cliente reescribise a táboa.

Unha devasa con estado aínda pode vencer unha ruta correcta. Se a captura agora mostra que a resposta sae por eth0 e o cliente segue esgotando o tempo, comprobe se o host descarta o paquete antes de envialo. O filtrado estrito de ruta inversa e net.ipv4.conf.all.rp_filter posto a 1 descartan paquetes cuxa orixe non se encamiñaría de volta pola interface pola que chegaron, que é exactamente o caso asimétrico que acaba de crear e logo corrixir, e o estado de conntrack conta a mesma historia para os portos reenviados.

A última comprobación é a que a xente salta: repita a consulta despois de que o túnel baixase e volvese subir. Catro valores deben coincidir co que anotou: o destino, o seguinte salto, o dispositivo e a orixe elixida. Se algún se moveu, o cliente reescribiu a táboa e a solución pertence aos seus hooks e non ao historial dunha shell.