VPN atrás de um NAT que você não pode configurar: o que ainda funciona

Cada extremidade de túnel precisa de um endereço e de uma porta que o outro lado consiga alcançar, e um roteador que você não administra é o motivo habitual de esse requisito falhar. A parte interessante não é existirem truques, mas cada um depender de uma propriedade de uma tabela de mapeamento que você não vê do cliente. Duas dessas propriedades decidem quase tudo: como um mapeamento é criado e se ele aceita pacotes de um endereço com o qual o interior nunca contatou. Ordene o ambiente por essas propriedades e as soluções deixam de ser folclore.

A tabela de mapeamento decide tudo

A tradução de endereços de rede mantém uma tabela em que um endereço e uma porta internos ficam registrados contra um endereço e uma porta públicos. As respostas que correspondem a um registro são traduzidas de volta, e um pacote que chega de fora sem registro correspondente não tem destino algum. Esse único comportamento explica por que um ouvinte atrás do roteador é inalcançável pela internet. Também explica por que o primeiro pacote em cada direção precisa se originar dentro.

Olhe a tabela pelo lado do roteador e as soluções ficam óbvias: ou algo cria uma entrada permanente, ou cria uma temporária e a mantém fresca, ou o tráfego nunca toma esse caminho. O resto do artigo são esses três casos em ordem. Nada aqui depende de um recurso do fabricante além do que a tabela registra.

O que o serviço de encontro pode e não pode fazer

O hole punching UDP usa o registro de saída como uma abertura temporária em vez de derrotar o filtro. Os dois pares contatam um serviço de encontro, que aprende cada extremidade pública e devolve ao outro lado a sua extremidade. Depois ambos enviam um em direção ao outro, e cada pacote de saída cria ou renova o registro que deixa a resposta entrar. A ordem é o que faz funcionar, e a ordem também é o que o torna frágil: um par que envia antes de o outro lado ter criado o seu registro é simplesmente descartado, enquanto uma nova tentativa um instante depois tem sucesso. O serviço em si não transporta tráfego VPN, então sua única alavanca é o timing que coordena.

O comportamento do mapeamento decide o resto, e RFC 4787 nomeia as três formas: independente da extremidade, dependente do endereço e dependente do endereço e da porta. Na última, a porta que um par precisa mirar muda com cada destino, então a previsão deixa de ser confiável. É aí que a técnica encontra seus becos sem saída, porque o NAT de nível de operadora e um firewall corporativo rígido eliminam ambos a previsibilidade de que o esquema precisa, e nenhuma quantidade de novas tentativas a traz de volta.

Keepalives, reinicializações e a extremidade que se move

Um caminho perfurado é um fluxo e não um ouvinte, então tudo o que roda sobre ele precisa sobreviver à mudança. Ele deve manter o mapeamento vivo com tráfego periódico, perceber quando a extremidade pública se move e restabelecer-se após a reinicialização do roteador ou a reatribuição do endereço. Produtos de mesh VPN colocam essa lógica no próprio plano de controle, enquanto um servidor simples a deixa com você. Keepalives só ajudam enquanto o mesmo mapeamento sobrevive, e custam bateria num cliente móvel, por isso um intervalo agressivo não é gratuito.

Um notebook que dorme uma hora normalmente volta numa extremidade pública diferente. O que restabelece o caminho precisa rodar de novo de dentro, o que devolve o mesmo requisito ao cliente.

Três maneiras de contornar um encaminhamento ausente

A primeira maneira pede ao roteador que crie ele mesmo a entrada, via UPnP IGD, NAT-PMP ou PCP, quando o recurso existe e está ligado. A segunda entrega o tráfego a um relay com endereço público, que sempre funciona e sempre custa largura de banda além de uma fronteira de confiança diferente. A terceira inverte a direção: o host interno abre um túnel de saída para um servidor público e todo o resto viaja dentro dele.

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

Uma extremidade de relay torna essa troca visível na configuração do cliente, onde a extremidade é um relay e não o endereço do próprio par. O keepalive persistente mantém o mapeamento aquecido, e os prefixos permitidos decidem o que o cliente pode enviar por ele. Um túnel reverso a partir do host interno é a mesma ideia com outro proprietário, e não exige nenhuma mudança de NAT. Cada uma das três remove o requisito de entrada sem derrotar um firewall que bloqueia por projeto o tráfego não solicitado, porque o tráfego ainda começa dentro.

Ajuste a solução a quem possui o roteador

Se você administra o roteador, um encaminhamento UDP estático é mais fácil de auditar do que qualquer esquema de perfuração e falha de formas que você vê. Se não, descubra se o fabricante oferece um relay ou um plano de controle hospedado, e se a política permitiria usá-lo. Se nenhum estiver disponível, as opções restantes são um túnel reverso ou aceitar que a extremidade não é alcançável de fora. Registrar qual você usou importa mais do que parece, porque as opções diferem em quem pode observar o tráfego e no que acontece quando um terceiro muda algo.

Anote se o caminho com que você terminou era direto ou passava por um relay, pois esse único fato prevê tanto a latência quanto o comportamento em caso de falha. RFC 4787 continua sendo a referência para o comportamento de mapeamento por baixo de tudo isso, e ler a sua seção de mapeamento é mais rápido do que testar três soluções em sequência. A tabela não se importa com a opção que você escolheu; ela só registra o que o próximo pacote pode fazer.