Dobre NAT e a túa VPN: o cliente funciona, o servidor non

O teu router está detrás doutro router, o enderezo WAN é privado e o cliente VPN conéctase igualmente. Esa combinación sorprende a quen espera que o dobre NAT rompa os túneles, pero as conexións de saída son xusto o que a tradución manexa mellor. Aloxar un servidor VPN detrás das mesmas dúas capas é o caso que adoita fallar. Debuxa a dirección da conexión antes de cambiar nada.

Debuxa primeiro a dirección da conexión

Abre a páxina de estado do router interior e anota o seu enderezo WAN, despois compárao co enderezo que che indica un servizo público. Se os dous difiren, hai polo menos un tradutor entre o teu router e internet. Se o enderezo WAN cae dentro de 100.64.0.0/10, o tradutor exterior probablemente é do teu provedor e non o controlas. Esos dous feitos deciden cal dos pasos seguintes pode funcionar.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

O dobre NAT non é unha dobre VPN. A tradución reescribe enderezos e portos; non engade un segundo túnel cifrado nin cifra nada. Manter as dúas ideas separadas importa porque as solucións son completamente distintas, e unha delas implica unha conversa co teu provedor en lugar dunha páxina de axustes.

Saída: o cliente pregunta, os tradutores asignan

Un túnel de saída comeza cun paquete da túa máquina, así que cada tradutor pode crear unha asignación e deixar entrar a resposta. O protocolo, o porto e os temporizadores de inactividade deciden se esa asignación sobrevive o suficiente para ser útil. A maioría dos routers domésticos resólveno sen ningunha configuración.

Os fallos que aparecen adoitan ter que ver con tempos de espera e soporte de protocolos, non co número de routers. Un túnel que cae tras uns minutos de silencio é unha asignación que caduca, e un keepalive é a resposta habitual. IPsec ten extensións estándar de NAT-traversal, así que afirmar que non pode atravesar a tradución é simplemente incorrecto. Se o túnel non se establece nunca, mira o extremo e as credenciais antes de culpar a topoloxía.

wg show
ping -c3 10.8.0.1

Détente se o túnel de saída funciona desde unha rede e non desde outra. Esa comparación trata das redes, non do número de routers.

Entrada: o reenvío só cobre o equipo que posúes

Aloxar un servidor é a dirección inversa: unha conexión nova chega desde internet e ten que alcanzar a túa máquina atravesando cada capa. Unha regra de reenvío de porto no router interior só axuda se o tradutor exterior tamén che entrega ese tráfico. Repetir a regra local non outorga control sobre o equipo do provedor.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

Compara o enderezo WAN do router interior co enderezo público que observaches e anota de onde saíu cada valor. Se o enderezo WAN é privado ou está no rango compartido, a capa exterior fai unha tradución que non podes configurar. Pregunta ao provedor que accesibilidade de entrada admite antes de pasar unha noite con regras que non poden surtir efecto. Quitar un router ou desactivar un devasado de forma ampla non é un diagnóstico, e é un mal intercambio por un só porto aberto.

Détente se a capa exterior é do provedor e non reenvía. Entón as respostas admitidas son outro método de acceso ou un relé, non outra regra pola túa parte.

Proba unha variable cada vez

Cambia unha cousa por proba e anota o resultado, porque unha ruta con dobre NAT ten máis variables que unha cun só router. Mantén o perfil e o dispositivo fixos e compara despois outra rede de acceso. Fíxate en se falla a negociación, se a sesión cae tras a inactividade ou se só fallan os destinos privados. Esas tres observacións apuntan a tres capas distintas.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

As subredes privadas superpostas son unha trampa á parte que ningunha cantidade de tradución arranxa. Se a túa rede doméstica e a rede remota usan o mesmo rango, aparece un conflito de rutas sen importar cantos tradutores haxa no medio. Renumerar un lado é a única resposta duradeira.

A pasarela remota merece a mesma atención, porque as súas regras de reenvío e rutas de retorno poden ser a peza que falta. Un túnel que se autentica pode non ter ningunha ruta de aplicación utilizábel, e ese fallo vese idéntico desde o lado do cliente. O percorrido termina cando podes dicir que dirección falla e que capa é responsable.