VPN darrere d'un NAT que no podeu configurar: què continua funcionant

Cada punt final de túnel necessita una adreça i un port que l'altre costat pugui assolir, i un encaminador que no administreu és el motiu habitual que aquest requisit falli. La part interessant no és que existeixin trucs, sinó que cadascun depèn d'una propietat d'una taula de mapatge que no veieu des del client. Dues d'aquestes propietats decideixen gairebé tot: com es crea un mapatge i si accepta paquets d'una adreça amb la qual l'interior no ha contactat mai. Ordeneu l'entorn per aquestes propietats i les solucions deixen de ser folklore.

La taula de mapatge ho decideix tot

La traducció d'adreces de xarxa manté una taula en què una adreça i un port interns queden registrats contra una adreça i un port públics. Les respostes que coincideixen amb un registre es tradueixen de tornada, i un paquet que arriba de fora sense cap registre coincident no té cap destinació. Aquest sol comportament explica per què un receptor darrere de l'encaminador és inabastable des d'internet. També explica per què el primer paquet en cada direcció ha d'originar-se a l'interior.

Mireu la taula des del costat de l'encaminador i les solucions es fan evidents: o alguna cosa crea una entrada permanent, o en crea una de temporal i la manté fresca, o el trànsit no pren mai aquest camí. La resta de l'article són aquests tres casos per ordre. Res aquí no depèn d'una funció del fabricant més enllà del que registra la taula.

Què pot i què no pot fer el servei de trobada

El foradat de forats UDP utilitza el registre de sortida com una obertura temporal en lloc de derrotar el filtre. Els dos iguals contacten un servei de trobada, que aprèn cada punt final públic i retorna a l'altre costat el seu punt final. Llavors tots dos envien l'un cap a l'altre, i cada paquet de sortida crea o refresca el registre que deixa entrar la resposta. L'ordre és el que el fa funcionar, i l'ordre també és el que el fa fràgil: un igual que envia abans que l'altre costat hagi creat el seu registre simplement es descarta, mentre que un reintent un moment després té èxit. El servei mateix no transporta cap trànsit VPN, així que la seva única palanca és el moment que coordina.

El comportament del mapatge decideix la resta, i RFC 4787 anomena les tres formes: independent del punt final, dependent de l'adreça i dependent de l'adreça i el port. Amb l'última, el port que un igual ha d'apuntar canvia amb cada destinació, de manera que la predicció deixa de ser fiable. Aquí la tècnica troba els seus carrers sense sortida, perquè el NAT de nivell d'operador i un tallafoc corporatiu estricte eliminen tots dos la predictibilitat que l'esquema necessita, i cap quantitat de reintents no la recupera.

Keepalives, reinicis i el punt final que es mou

Un camí foradat és un flux i no un receptor, així que el que hi corre a sobre ha de sobreviure al canvi. Ha de mantenir el mapatge viu amb trànsit periòdic, adonar-se quan el punt final públic es mou i restablir-se després que l'encaminador es reiniciï o l'adreça es reassenyi. Els productes de mesh VPN posen aquesta lògica al seu propi pla de control, mentre que un servidor simple us la deixa a vosaltres. Els keepalives només ajuden mentre sobreviu el mateix mapatge, i costen bateria en un client mòbil, per la qual cosa un interval agressiu no és gratuït.

Un portàtil que dorm una hora normalment torna amb un punt final públic diferent. El que restableix el camí ha de tornar a executar-se des de dins, cosa que posa el mateix requisit al client.

Tres maneres de saltar-se un reenviament que falta

La primera manera demana a l'encaminador que creï l'entrada ell mateix, mitjançant UPnP IGD, NAT-PMP o PCP, quan la funció existeix i està activada. La segona lliura el trànsit a un repetidor amb adreça pública, que sempre funciona i sempre costa amplada de banda més una frontera de confiança diferent. La tercera inverteix la direcció: l'amfitrió intern obre un túnel de sortida cap a un servidor públic i tota la resta viatja a dins.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Un punt final de repetidor fa visible aquest intercanvi a la configuració del client, on el punt final és un repetidor i no l'adreça pròpia d'un igual. El keepalive persistent manté el mapatge calent, i els prefixos permesos decideixen què pot enviar-hi el client. Un túnel invers des de l'amfitrió intern és la mateixa idea amb un propietari diferent, i no necessita cap canvi de NAT. Cadascuna de les tres elimina el requisit d'entrada sense derrotar un tallafoc que bloqueja per disseny el trànsit no sol·licitat, perquè el trànsit encara comença a dins.

Encafeu la solució amb qui posseeix l'encaminador

Si administreu l'encaminador, un reenviament UDP estàtic és més fàcil d'auditar que qualsevol esquema de foradat i falla de maneres que veieu. Si no, esbrineu si el fabricant ofereix un repetidor o un pla de control allotjat, i si la política en permetria l'ús. Si no n'hi ha cap, les opcions restants són un túnel invers o acceptar que el punt final no és abastable des de fora. Enregistrar quin heu fet servir importa més del que sembla, perquè les opcions difereixen en qui pot observar el trànsit i en què passa quan un tercer canvia alguna cosa.

Fixeu-vos si el camí amb què heu acabat era directe o passava per un repetidor, ja que aquest sol fet prediu tant la latència com el comportament en cas de fallada. RFC 4787 continua sent la referència del comportament de mapatge que hi ha a sota de tot això, i llegir-ne la secció de mapatge és més ràpid que provar tres solucions en seqüència. La taula no té cura de quina opció heu triat; només registra què pot fer el següent paquet.