O servidor web desaparece cando se conecta o cliente VPN

Un servizo que desaparece no momento en que se conecta un cliente VPN normalmente non está bloqueado, senón que responde pola interface equivocada. A petición chega á tarxeta de rede física, o daemon escribe unha resposta e a táboa de encamiñamento entrega esa resposta ao túnel, xa que o túnel asumiu a ruta predeterminada. O cliente remoto nunca ve unha resposta a unha conexión que abriu, así que espera e logo informa dun tempo de espera esgotado. Ningunha regra de devasas intervén nesa secuencia.

O síntoma: peticións dentro, respostas pola porta equivocada

A pista é unha conexión entrante que falla mentres todo o demais no equipo funciona. Outra pista é un equipo accesible desde a LAN pero non desde internet, ou un que funciona ata que o túnel se reconecta e entón detense. En cada caso a dirección de ida comportábase ben e a de volta non, o que apunta a unha asimetría de encamiñamento e non a unha política.

Confírmeo observando cara a onde vai a resposta, non observando como chega a petición.

Capture á vez na interface física e no dispositivo do túnel. Se a petición aparece na interface física e a resposta no túnel, o diagnóstico está rematado. Unha resposta que non aparece en ningún sitio significa que o servizo nunca aceptou a conexión, o que é unha investigación aparte cunha causa aparte.

Dúas rutas predeterminadas e unha decisión de encamiñamento

Un cliente que instala unha ruta predeterminada engade unha segunda entrada cunha métrica mellor que a da pasarela da LAN. Algúns clientes instalan no seu lugar dúas rutas de medio rango, que cobren o mesmo espazo de forma máis específica e gañan a busca do mesmo xeito. Calquera das dúas técnicas deixa que os paquetes saíntes ordinarios escollan a interface do túnel.

Esa escolla faise só por destino. O núcleo non pregunta de onde veu un paquete salvo que unha regra de política llo indique. Así, a resposta a un enderezo público de cliente entrégase ao túnel, cuxo extremo remoto recibe un paquete cun enderezo de orixe que non posúe e descártao ou reenvíao a un lugar inútil. En Linux, o filtrado estrito de ruta inversa tamén pode descartar a petición orixinal antes de que o seu servizo chegue a vela, o que desde fóra parece idéntico. Ambos os síntomas veñen da mesma asociación ausente entre un fluxo entrante e a súa resposta.

O túnel compórtase correctamente en todo momento. Díxoselle que levase a ruta predeterminada e fai exactamente iso.

Repare o camiño de volta sen romper o túnel

Existen tres formas duradeiras de reparación, e a elección depende de canto do tráfico propio do equipo debe quedar dentro do túnel. Excluír o destino ou o porto do servizo é o cambio máis pequeno. O encamiñamento por política segundo a orixe ou a marca é o máis preciso. A tradución de orixe é a máis burda e a máis fácil de explicar dous anos despois.

Escolla segundo o que o equipo deba facer, non segundo cal fragmento atopou primeiro.

Excluír un destino encaixa cun servizo de enderezo público estable, e atar o daemon ao enderezo físico en lugar de a todos os enderezos fai máis segura esa exclusión. Unha regra de política que escolle unha táboa por orixe mantén as conexións propias do equipo dentro do túnel mentres devolve as respostas do servizo pola pasarela WAN. Enmascarar as respostas na interface WAN chega ao mesmo camiño a costa de ocultar o enderezo do cliente dos rexistros do servizo. Un cambio improvisado da ruta predeterminada é un diagnóstico e non unha configuración, porque o cliente reescribe as rutas en cada reconexión.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Cando o equipo tamén encamiña para unha LAN detrás del

Un salto máis fóra, a mesma asimetría volve con máis pezas móbiles. O tráfico chega ao router desde internet, reenvíase a un dispositivo interno, e o único camiño de volta dese dispositivo é o túnel, así que a resposta chega ao cliente orixinal desde o enderezo do propio provedor. O seguimento de conexións atopa entón unha resposta dun fluxo cuxo comezo non viu, e descártaa. O cliente, mentres tanto, non ve absolutamente nada.

Dous cambios o reparan: tradución de destino para que a conexión entrante chegue ao dispositivo interno, e tradución de orixe para que a resposta dese dispositivo pareza vir do propio router.

No firmware do router a expresión habitual é unha regra de política que fixa o reenvío de portos ao lado WAN mentres o tráfico propio do router vai polo túnel. Sen tradución de orixe, esa resposta diríxese ao cliente externo e o dispositivo interno simplemente non ten ruta cara a ela. Probe tres cousas por separado, porque fallan por razóns distintas: unha conexión que chega de fóra, unha que orixina o propio equipo e unha consulta de nome.