Chegar a un equipo detrás de NAT sen abrir un porto

Dous extremos detrás do NAT do operador e un router de oficina bloqueado non deixan ningún porto entrante que redirixir, e o reflexo é pedir un de todos os xeitos. A mellor pregunta é que lado pode marcar cara a fóra e que servizo accesible ten permiso para levar o tráfico. Catro deseños responden a esa pregunta de forma distinta e fallan de forma distinta cando se bloquea unha ruta. Escoller entre eles é unha comparación de garantías, non de nomes de protocolos.

Catro deseños, catro promesas diferentes

A táboa de abaixo é a versión curta. Lea a columna central como a promesa que pode probar e a columna dereita como a promesa que ninguén fixo.

Que fila se aplica depende da tarefa e non da preferencia. Unha sesión de escritorio remoto, unha consola administrativa e acceso a toda unha subrede privada son tres requisitos que non precisan o mesmo punto de entrada, aínda que casualmente afecten o mesmo equipo.

Un concentrador cambia quen marca cara a fóra, non o que está permitido

Nun deseño de concentrador encamiñado, o portátil remoto e o equipo de traballo, ou a pasarela do sitio diante del, abren cada un un túnel de saída cara a un servizo que ambos poden alcanzar. Nada acepta unha conexión non solicitada no router do equipo, e é exactamente por iso que este deseño sobrevive ao NAT e segue funcionando cando o sitio non ten enderezo estático. Despois o concentrador encamiña o tráfico entre os dous enderezos internos segundo a súa propia política.

O custo é que o concentrador debe existir, debe ser accesible desde ambos os lados e alguén debe operalo. O filtrado de saída ten que permitir o transporte, e unha rede que o bloquee derrotará o deseño aínda que non fixese falta ningunha redirección de porto.

A parte sutil é que accesibilidade e autorización son decisións separadas tomadas en lugares distintos. Unha ruta cara a un prefixo non di nada sobre que servizo do equipo pode usar a identidade, e unha regra de cortalumes que permite o túnel non di nada sobre se a conta pode iniciar sesión. Configure ambas, probe ambas e manteña a decisión de autorización no sistema que posúe o recurso e non na táboa de encamiñamento.

O tránsito só funciona cando ambos os stacks o implementan

O tránsito entre pares é unha capacidade dun sistema concreto, non un axuste que mellora unha VPN. Interactive Connectivity Establishment reúne varias direccións candidatas e proba parellas ata que unha funciona: candidatas de host nas interfaces locais, candidatas reflexivas do servidor construídas a partir do que revela un NAT e candidatas retransmitidas asignadas nun relé. Un enderezo privado por si só non é unha ruta, porque o outro lado non pode encamiñar cara a ela.

Paga a pena entender o caso retransmitido antes de descartalo. RFC 8656 describe TURN como un protocolo no que un cliente pide a un servidor un enderezo de transporte retransmitido e o servidor reenvía o tráfico entre ese cliente e os seus pares. O relé leva por tanto os datos, o que é materialmente distinto dun directorio que só axuda a que os extremos se atopen. Intercambiar o enderezo do relé co outro extremo é un paso de coordinación que a aplicación ten que facer.

O que non pode prometer é unha ruta directa. O NAT simétrico e algúns cortalumes empresariais derrotan o perforado de buratos, e cando o fan o sistema ou recorre a un relé ou falla. Tampouco pode concluír que dous extremos traducidos nunca poidan falar; un stack compatible con respaldo de relé existe precisamente porque a miúdo si poden. Decida se importa máis a dispoñibilidade ou a conexión directa e logo verifique que ruta escolleu realmente o despregue en lugar de supoñer o caso feliz.

Un bróker é máis estreito que unha rede

Cando o requisito é unha soa aplicación, un bróker de aplicacións ou unha conexión inversa iniciada polo equipo poden ser a resposta máis pequena. O equipo marca cara a fóra a un bróker, o bróker autentica o usuario remoto e só se transporta esa sesión de aplicación. Non se crea ningunha ruta cara á subrede do equipo, así que un compromiso da sesión remota non herda un camiño cara a cada dispositivo de ao lado.

Esa estreiteza ten un prezo: cada aplicación adicional necesita a súa propia integración, e calquera cousa que a aplicación supoña sobre unha rede local, como un recurso compartido que abre nun servidor próximo, pode non ser accesible. Os brókers tamén concentran política e rexistro nun só lugar, o que resulta útil ata que ese lugar se converte na caída.

Compare as fronteiras de confianza e logo probe a ruta

Un concentrador que remata túneles pode ler o tráfico que encamiña. Un relé pode levar un intercambio protexido de forma independente cando a aplicación cifra de extremo a extremo, e un bróker normalmente remata a sesión que presenta. Estableza onde acaba realmente a protección antes de decidir que dous deseños son equivalentes porque ambos están cifrados.

Logo comprobe a que alcanza realmente o equipo cara a fóra, xa que todos os deseños de arriba dependen diso. Execúteo no equipo, substituíndo o nome de host que pensa usar.

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

Acepte o deseño só despois de que a operación remota prevista teña éxito coa identidade permitida, se rexeite unha identidade non aprobada e o comportamento cando a ruta directa ou retransmitida non estea dispoñible sexa coñecido e estea documentado. Inclúa unha reconexión e o contexto de arranque normal do equipo, porque unha sesión que comezou na oficina pola LAN non proba nada do que depende o acceso remoto.