Servidor VPN doméstico inaccesible: percorre a cadea NAT

O servidor responde na LAN, a regra de reenvío de porto parece correcta e, aínda así, un cliente externo non pode conectarse. Avanzar cara a fóra unha fronteira á vez é máis rápido que editar a regra por cuarta vez, porque cada fronteira deixa a súa propia evidencia: a páxina WAN do router, a tradución do provedor e o oínte no host. Comeza pola páxina de administración que xa tes aberta e remata cunha proba desde unha rede que non controlas. Anota cada resultado sobre a marcha, porque a secuencia é o diagnóstico e un número recordado non é unha proba. Se só necesitas un túnel de saída, a tradución non é o teu problema: só se bloquea o tráfico entrante non solicitado.

Comeza na páxina WAN do router

Inicia sesión no router e le a páxina de estado en lugar da lista de reenvío de portos. Anota o enderezo WAN, a interface á que pertence e se o tipo de conexión é DHCP, PPPoE ou algo que proporcione o provedor. Despois compara ese enderezo co que informa un servizo externo, usando un teléfono con datos móbiles para que a observación non volva polo mesmo router. Os dous números responden preguntas distintas, e comparalos é todo o obxectivo deste paso.

Un enderezo WAN que difire do enderezo público observado significa que hai polo menos un tradutor por riba do router. Aínda non é unha avaría, porque moitos provedores traducen por deseño e o servizo segue funcionando. Se os dous coinciden, probablemente o router posúe o enderezo e o problema trasladouse ao interior da túa rede. En calquera caso, anota o par coa data, porque os provedores reasignan enderezos e unha comparación coas notas do mes pasado non vale nada.

Sube un salto cara arriba

Executa un traceroute desde o propio router e le os primeiros saltos. Enderezos públicos repetidos, un primeiro salto que responde cun enderezo privado ou un enderezo dentro do rango compartido 100.64.0.0/10 apuntan todos a un tradutor augas arriba. RFC 6598 define ese rango xustamente para este tipo de despregamento, e por iso velo no campo WAN é un sinal forte e non unha curiosidade. Dous tradutores na ruta fan a traza menos evidente, así que le o patrón e non unha soa liña.

Algúns provedores só mostran o enderezo asignado no portal de cliente, así que mira alí antes de concluír que o router mente. Un enderezo do portal que coincide coa túa observación externa mentres o router informa outra cousa é a proba máis clara dun tradutor augas arriba. Garda ambas as páxinas no rexistro de cambios, porque a discusión sobre quen posúe que fronteira avanza moito máis rápido con dúas imaxes datadas.

Confirma o oínte e o reenvío

Unha proba na LAN demostra que o servizo funciona localmente e non demostra nada sobre o alcance desde fóra. Moitos routers responden a súa propia regra de reenvío desde dentro, así que unha proba de bucle ten éxito mentres a ruta externa segue pechada. Confirma que o daemon está ligado ao enderezo e ao porto que cres que usa, e despois proba desde fóra. Todo o que segue é só de lectura.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

Se a proba externa mostra que non chega ningún paquete ao router, a caída ocorreu augas arriba e ningunha regra local a arranxará. Se os paquetes chegan e nada responde, a seguinte fronteira é o oínte ou a devasa do host. Unha captura de paquetes no host aclara cal dos dous estás mirando e leva menos tempo que outra rolda de adiviñar regras. Mantén o oínte e o seu transporte sen cambios mentres comparas, ou a seguinte proba responderá outra pregunta.

Cambia a topoloxía, non a mesma regra

Cando o tradutor é do provedor, a solución é outra ruta e non outro reenvío. Un VPS pequeno con enderezo público, unido por un túnel de saída desde o lado da casa, pon un extremo alcanzable diante do servizo. Un enderezo público proporcionado polo provedor é máis simple onde existe e normalmente máis barato que manter unha máquina. IPv6 elimina a tradución por completo, sempre que a rede do cliente, os rexistros DNS e a política da devasa o soporten todo.

DNS dinámico só actualiza un nome; non crea alcance, e apuntalo a un enderezo compartido envía os clientes a unha pasarela do provedor que outros abonados tamén usan. Ese fallo parece exactamente un servidor morto, e por iso importa o rexistro dos pasos anteriores. Anota a que enderezo resolveu o nome cando a proba fallou, e garda a resposta co resultado da proba.

Reescribe o plan arredor da fronteira que controlas: o oínte, o túnel e as rutas. Mantén o reenvío antigo só mentres siga describindo algo certo, porque unha regra que xa non encaixa coa topoloxía é peor que ningunha regra. Anota que capa bloqueaba en realidade e que evidencia o mostrou. Se non, a seguinte persoa que abra a páxina de administración repetirá cada paso deste percorrido desde o principio.