Doble NAT i la vostra VPN: el client funciona, el servidor no

El vostre encaminador és darrere d'un altre encaminador, l'adreça WAN és privada i el client VPN es connecta igualment. Aquesta combinació sorprèn qui espera que el doble NAT trenqui els túnels, però les connexions de sortida són justament el que la traducció gestiona millor. Allotjar un servidor VPN darrere de les mateixes dues capes és el cas que normalment falla. Dibuixeu la direcció de la connexió abans de canviar res.

Dibuixeu primer la direcció de la connexió

Obriu la pàgina d'estat de l'encaminador interior i anoteu-ne l'adreça WAN, i després compareu-la amb l'adreça que us indica un servei públic. Si les dues difereixen, hi ha almenys un traductor entre el vostre encaminador i internet. Si l'adreça WAN cau dins de 100.64.0.0/10, el traductor exterior probablement és del vostre proveïdor i no el controleu. Aquests dos fets decideixen quins dels passos següents poden funcionar.

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

El doble NAT no és una doble VPN. La traducció reescriu adreces i ports; no afegeix un segon túnel xifrat ni xifra res. Mantenir les dues idees separades és important perquè les solucions són completament diferents, i una d'elles implica una conversa amb el vostre proveïdor en lloc d'una pàgina de configuració.

Sortida: el client pregunta, els traductors assignen

Un túnel de sortida comença amb un paquet de la vostra màquina, així que cada traductor pot crear una assignació i deixar entrar la resposta. El protocol, el port i els temporitzadors d'inactivitat decideixen si aquesta assignació sobreviu prou temps per ser útil. La majoria d'encaminadors domèstics ho gestionen sense cap configuració.

Les fallades que apareixen solen tractar-se de temps d'espera i de suport de protocols, no del nombre d'encaminadors. Un túnel que cau després d'uns minuts de silenci és una assignació que caduca, i un keepalive és la resposta habitual. IPsec té extensions estàndard de NAT-traversal, així que afirmar que no pot travessar la traducció és simplement incorrecte. Si el túnel no s'estableix mai, mireu el punt final i les credencials abans de culpar la topologia.

wg show
ping -c3 10.8.0.1

Atureu-vos si el túnel de sortida funciona des d'una xarxa i no des d'una altra. Aquesta comparació tracta de les xarxes, no del nombre d'encaminadors.

Entrada: el reenviament només cobreix l'equip que posseïu

Allotjar un servidor és la direcció inversa: una connexió nova arriba d'internet i ha d'arribar a la vostra màquina travessant cada capa. Una regla de reenviament de port a l'encaminador interior només ajuda si el traductor exterior també us lliura aquest trànsit. Repetir la regla local no atorga control sobre l'equip del proveïdor.

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

Compareu l'adreça WAN de l'encaminador interior amb l'adreça pública que heu observat i anoteu d'on ve cada valor. Si l'adreça WAN és privada o dins del rang compartit, la capa exterior fa una traducció que no podeu configurar. Pregunteu al proveïdor quina accessibilitat d'entrada admet abans de passar una vetllada amb regles que no poden tenir efecte. Treure un encaminador o desactivar un tallafoc de manera àmplia no és cap diagnòstic, i és un mal intercanvi per un sol port obert.

Atureu-vos si la capa exterior és del proveïdor i no reenvia. Llavors les respostes admeses són un altre mètode d'accés o un relé, no una altra regla a la vostra banda.

Proveu una variable alhora

Canvieu una cosa per prova i anoteu el resultat, perquè un camí amb doble NAT té més variables que un amb un sol encaminador. Manteniu el perfil i el dispositiu fixos i compareu després una altra xarxa d'accés. Fixeu-vos si falla la negociació, si la sessió cau després d'inactivitat o si només fallen les destinacions privades. Aquestes tres observacions apunten a tres capes diferents.

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

Les subxarxes privades superposades són una trampa a part que cap quantitat de traducció no arregla. Si la vostra xarxa domèstica i la xarxa remota fan servir el mateix rang, apareix un conflicte de rutes independentment de quants traductors hi hagi entremig. Renumerar un costat és l'única resposta duradora.

La passarel·la remota mereix la mateixa atenció, perquè les seves regles de reenviament i rutes de retorn poden ser la peça que falta. Un túnel que s'autentica pot no tenir cap camí d'aplicació utilitzable, i aquesta fallada es veu idèntica des del costat del client. El recorregut acaba quan podeu dir quina direcció falla i quina capa n'és responsable.