Arriba a una estació de treball darrere de NAT sense obrir cap port

Dos extrems darrere del NAT de l’operador i un router d’oficina bloquejat no deixen cap port d’entrada per redirigir, i el reflex és demanar-ne un igualment. La pregunta millor és quin costat pot marcar cap a fora i quin servei accessible té permís per portar el trànsit. Quatre dissenys responen aquesta pregunta de maneres diferents i fallen de maneres diferents quan un camí queda bloquejat. Triar entre ells és una comparació de garanties, no de noms de protocols.

Quatre dissenys, quatre promeses diferents

La taula de sota és la versió curta. Llegiu la columna central com la promesa que podeu provar i la columna dreta com la promesa que ningú no ha fet.

Quina fila s’aplica depèn de la tasca i no de la preferència. Una sessió d’escriptori remot, una consola administrativa i accés a tota una subxarxa privada són tres requisits que no necessiten el mateix punt d’entrada, encara que casualment afectin la mateixa màquina.

Un concentrador canvia qui marca cap a fora, no què està permès

En un disseny de concentrador encaminat, l’ordinador portàtil remot i l’estació de treball, o la passarel·la del lloc que hi ha al davant, obren cadascun un túnel de sortida cap a un servei que tots dos poden assolir. Res no accepta una connexió no sol·licitada al router de l’estació de treball, i és exactament per això que aquest disseny sobreviu al NAT i continua funcionant quan el lloc no té cap adreça estàtica. Després el concentrador encamina el trànsit entre les dues adreces interiors segons la seva pròpia política.

El cost és que el concentrador ha d’existir, ha de ser accessible des dels dos costats i algú l’ha d’operar. El filtratge de sortida ha de permetre el transport, i una xarxa que el bloquegi farà fracassar el disseny encara que no calgués cap redirecció de port.

La part subtil és que accessibilitat i autorització són decisions separades preses en llocs diferents. Una ruta cap a un prefix no diu res sobre quin servei de l’estació de treball pot usar la identitat, i una regla de tallafoc que permet el túnel no diu res sobre si el compte pot iniciar sessió. Configureu totes dues, proveu totes dues i manteniu la decisió d’autorització amb el sistema que posseeix el recurs i no amb la taula d’encaminament.

El travessament només funciona quan tots dos stacks l’implementen

El travessament entre iguals és una capacitat d’un sistema concret, no un paràmetre que millora una VPN. Interactive Connectivity Establishment recull diverses adreces candidates i prova parelles fins que una funciona: candidates d’amfitrió a les interfícies locals, candidates reflexives del servidor construïdes a partir del que revela el NAT i candidates relayades assignades en un relé. Una adreça privada per si sola no és un camí, perquè l’altre costat no hi pot encaminar.

Val la pena entendre el cas relayat abans de descartar-lo. RFC 8656 descriu TURN com un protocol en què un client demana a un servidor una adreça de transport relayada i el servidor reenvia el trànsit entre aquest client i els seus iguals. Per tant el relé porta les dades, cosa materialment diferent d’un directori que només ajuda els extrems a trobar-se. Intercanviar l’adreça del relé amb l’altre extrem és un pas de coordinació que l’aplicació ha de fer.

El que no podeu prometre és un camí directe. El NAT simètric i alguns tallafocs empresarials derroten el forat de perforació, i quan ho fan el sistema o cau a un relé o falla. Tampoc no podeu concloure que dos extrems traduïts no puguin parlar mai; un stack suportat amb fallback de relé existeix precisament perquè sovint sí que poden. Decidiu si importa més la disponibilitat o la directesa, i després verifiqueu quin camí ha triat realment el desplegament en lloc de suposar el cas feliç.

Un broker és més estret que una xarxa

Quan el requisit és una sola aplicació, un broker d’aplicacions o una connexió inversa iniciada per l’estació de treball poden ser la resposta més petita. L’estació de treball marca cap a fora a un broker, el broker autentica l’usuari remot i només es porta aquella sessió d’aplicació. No es crea cap ruta cap a la subxarxa de l’estació de treball, així que un compromís de la sessió remota no hereta un camí cap a cada dispositiu del costat.

Aquesta estretor té un preu: cada aplicació addicional necessita la seva pròpia integració, i qualsevol cosa que l’aplicació pressuposi sobre una xarxa local, com un recurs compartit que obre en un servidor proper, pot no ser accessible. Els brokers també concentren política i registre en un sol lloc, cosa útil fins que aquell lloc es converteix en la caiguda.

Compareu les fronteres de confiança i després proveu el camí

Un concentrador que acaba els túnels pot llegir el trànsit que encamina. Un relé pot portar un intercanvi protegit de manera independent quan l’aplicació xifra d’extrem a extrem, i un broker normalment acaba la sessió que presenta. Establiu on acaba realment la protecció abans de decidir que dos dissenys són equivalents perquè tots dos estan xifrats.

Després comproveu a què arriba realment l’estació de treball cap a fora, ja que tots els dissenys de dalt en depenen. Executeu-ho a l’estació de treball, substituint el nom d’amfitrió que penseu utilitzar.

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

Accepteu el disseny només després que l’operació remota prevista tingui èxit amb la identitat permesa, es rebutgi una identitat no aprovada i el comportament quan el camí directe o relayat no estigui disponible sigui conegut i documentat. Incloeu una reconnexió i el context d’arrencada normal de l’estació de treball, perquè una sessió que va començar a l’oficina per la LAN no prova res d’allò de què depèn l’accés remot.