O VPN conéctase pero non chega aos dispositivos da LAN: que revisar

O tráfico entra no túnel, a pasarela responde no seu propio enderezo e nada detrás dela responde. Ese patrón é habitual e non é unha contradición: unha resposta da pasarela demostra que o túnel rematou, e non demostra nada sobre o que pasa cun paquete dirixido máis alá. As dúas probas exercitan camiños de código distintos na mesma máquina.

A partir de agora, proba algo no outro lado da pasarela. O enderezo propio da pasarela seguirá respondendo por moi roto que estea o reenvío.

A pasarela responde desde a súa propia pila

Un paquete dirixido á pasarela entrégase ao seu camiño de entrada local, onde o núcleo decide se o acepta un socket á escoita. Un paquete dirixido a un host detrás da pasarela entrégase, en cambio, ao camiño de reenvío, onde se aplica outro conxunto de comprobacións. O reenvío pode estar completamente desactivado, ou o núcleo pode activalo e despois unha regra de filtro que nunca menciona o túnel pode rexeitalo. Nada diso afecta á resposta propia da pasarela, por iso o síntoma engana con tanta fiabilidade.

As páxinas de administración alcanzadas polo túnel tamén pertencen á primeira categoría. Son evidencia sobre o túnel, non sobre a rede que hai detrás.

Segue o fluxo ata a primeira fronteira que o descarta

Comeza no cliente e confirma a ruta e o enderezo de orixe que usará o fluxo. Despois observa a pasarela para ver chegar ese fluxo exacto, e de novo o mesmo fluxo saíndo cara á LAN. Se nunca chega, o problema está no lado do cliente ou nos prefixos permitidos do túnel. Se chega e nunca sae, o problema está no reenvío ou nun filtro da ruta de avance, e a captura xa dixo cal dos dous.

Executar a mesma proba desde a pasarela oculta a metade interesante, porque un paquete orixinado na pasarela ten outra orixe e outro requisito de retorno. Usa o fluxo do cliente, co seu propio enderezo de orixe, en cada paso. Unha captura tomada na interface equivocada produce sandeces con moita seguridade.

As rutas de retorno e os cortafogos dos hosts fallan por separado

Cando o paquete chega ao host, deben cumprirse tres cousas máis. O servizo debe estar escoitando no enderezo ao que se enviou o paquete, o cortafogos do host debe aceptalo, e a resposta debe ter unha ruta de volta cara ao conxunto de clientes. Esa última falla a miúdo, porque a ruta predeterminada do host apunta a un encamiñador que nunca oíu falar do rango do túnel. O resultado é unha conexión que se establece desde o punto de vista do host e morre en silencio na outra dirección.

Proba a ruta de volta a propósito enviando desde o cliente e observando o retorno. Unha captura unidireccional resolve en segundos o que unha hora de especulación non resolverá.

Confirma cada salto co enderezo de orixe do cliente

Executa as comprobacións en orde e conserva cada saída, porque o valor está na comparación e non en ningunha liña concreta. Os comandos de abaixo fixan o enderezo de orixe, mostran a ruta elixida e capturan os dous lados do reenvío. Substitúe o teu propio host da LAN e a túa interface de túnel.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

A consulta de ruta mostra se o cliente enviaría sequera ese paquete ao túnel, e o ping mostra se volveu algo do host. Comparar as dúas capturas separa a chegada da saída, xa que unha trama na interface do túnel sen contrapartida na interface da LAN é unha decisión de reenvío e non un fallo do servizo. Cando ambas as capturas mostran a petición e só unha mostra a resposta, a ruta de volta é o sospeitoso restante.

Anota que enderezo respondeu e que destino reenviado fallou. Esa frase fai o informe accionable en lugar dunha afirmación de que o servidor non é accesible.