Alcançar uma estação de trabalho atrás de NAT sem encaminhamento de porta

Duas extremidades atrás do NAT da operadora e um router de escritório bloqueado não deixam nenhuma porta de entrada para encaminhar, e o reflexo é pedir uma mesmo assim. A pergunta melhor é que lado consegue ligar para fora e que serviço alcançável tem permissão para transportar o tráfego. Quatro desenhos respondem a essa pergunta de formas diferentes e falham de formas diferentes quando um caminho fica bloqueado. Escolher entre eles é uma comparação de garantias, não de nomes de protocolos.

Quatro desenhos, quatro promessas diferentes

A tabela abaixo é a versão curta. Leia a coluna do meio como a promessa que pode testar e a coluna da direita como a promessa que ninguém fez.

Qual a linha que se aplica depende da tarefa e não da preferência. Uma sessão de ambiente de trabalho remoto, uma consola administrativa e acesso a toda uma sub-rede privada são três requisitos que não precisam do mesmo ponto de entrada, mesmo quando casualmente envolvem a mesma máquina.

Um hub muda quem liga para fora, não o que é permitido

Num desenho com hub encaminhado, o portátil remoto e a estação de trabalho, ou a gateway do local à frente dela, abrem cada um um túnel de saída para um serviço que ambos conseguem alcançar. Nada aceita uma ligação não solicitada no router da estação de trabalho, e é exatamente por isso que este desenho sobrevive ao NAT e continua a funcionar quando o local não tem endereço estático. O hub encaminha depois o tráfego entre os dois endereços internos segundo a sua própria política.

O custo é que o hub tem de existir, ser alcançável dos dois lados e ser operado por alguém. A filtragem de saída tem de permitir o transporte, e uma rede que o bloqueie derrotará o desenho mesmo que não fosse necessário qualquer encaminhamento de porta.

A parte subtil é que alcançabilidade e autorização são decisões separadas tomadas em locais diferentes. Uma rota para um prefixo não diz nada sobre qual serviço da estação de trabalho a identidade pode usar, e uma regra de firewall que permite o túnel não diz nada sobre se a conta consegue iniciar sessão. Configure ambas, teste ambas e mantenha a decisão de autorização no sistema que possui o recurso e não na tabela de encaminhamento.

A travessia só funciona quando ambas as pilhas a implementam

A travessia entre pares é uma capacidade de um sistema concreto, não um ajuste que melhora uma VPN. O Interactive Connectivity Establishment reúne vários endereços candidatos e testa pares até um funcionar: candidatos de anfitrião nas interfaces locais, candidatos reflexivos do servidor construídos a partir do que um NAT revela e candidatos retransmitidos atribuídos num relé. Um endereço privado por si só não é um caminho, porque o outro lado não consegue encaminhar para ele.

Vale a pena compreender o caso retransmitido antes de o descartar. RFC 8656 descreve o TURN como um protocolo em que um cliente pede a um servidor um endereço de transporte retransmitido e o servidor reencaminha o tráfego entre esse cliente e os seus pares. O relé transporta portanto os dados, o que é materialmente diferente de um diretório que apenas ajuda as extremidades a encontrarem-se. Trocar o endereço do relé com o outro lado é um passo de coordenação que a aplicação tem de executar.

O que não pode prometer é um caminho direto. O NAT simétrico e algumas firewalls empresariais derrotam a perfuração de buracos, e quando o fazem o sistema ou recorre a um relé ou falha. Também não pode concluir que duas extremidades traduzidas nunca poderão falar; uma pilha suportada com recurso a relé existe precisamente porque muitas vezes conseguem. Decida se importa mais a disponibilidade ou a ligação direta e depois verifique que caminho escolheu realmente a implementação em vez de assumir o caso feliz.

Um broker é mais estreito do que uma rede

Quando o requisito é uma única aplicação, um broker de aplicações ou uma ligação inversa iniciada pela estação de trabalho podem ser a resposta mais pequena. A estação de trabalho liga para fora a um broker, o broker autentica o utilizador remoto e apenas essa sessão de aplicação é transportada. Não é criada nenhuma rota para a sub-rede da estação de trabalho, pelo que um compromisso da sessão remota não herda um caminho para cada dispositivo ao lado.

Essa estreiteza tem um preço: cada aplicação adicional precisa da sua própria integração, e tudo o que a aplicação assume sobre uma rede local, como uma partilha de ficheiros que abre num servidor próximo, pode não ser alcançável. Os brokers também concentram política e registo num só lugar, o que é útil até esse lugar se tornar a falha.

Compare as fronteiras de confiança e depois teste o caminho

Um hub que termina túneis pode ler o tráfego que encaminha. Um relé pode transportar uma troca protegida de forma independente quando a aplicação cifra de ponta a ponta, e um broker normalmente termina a sessão que apresenta. Estabeleça onde a proteção termina realmente antes de decidir que dois desenhos são equivalentes porque ambos estão cifrados.

Depois verifique a que chega realmente a estação de trabalho em saída, já que todos os desenhos acima dependem disso. Execute isto na estação de trabalho, substituindo o nome de anfitrião que pretende usar.

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

Aceite o desenho apenas depois de a operação remota prevista ter êxito com a identidade permitida, de uma identidade não aprovada ser recusada e de o comportamento quando o caminho direto ou retransmitido não está disponível ser conhecido e estar documentado. Inclua uma reconexão e o contexto de arranque normal da estação de trabalho, porque uma sessão que começou no escritório pela LAN não testa nada de que o acesso remoto dependa.