Redirecionamento de porta versus acesso VPN: para onde o pacote realmente vai

Dois desenhos, uma aplicação HTTPS, e o pacote segue uma rota diferente em cada um. Um redirecionamento de porta muda onde o pacote é entregue e deixa o resto intacto. Uma VPN transporta primeiro esse pacote dentro de outro pacote, pelo que o ouvinte da aplicação vê uma origem diferente e uma carga útil máxima menor. A encriptação de que se discute está presente nos dois casos, porque a aplicação continua a ser HTTPS; o que difere é quem pode abrir uma ligação e o que a rede intermédia pode observar. Essa distinção resolve a maioria das questões práticas.

A regra DNAT reescreve o destino e para aí

Num gateway Linux, publicar um serviço significa uma regra na cadeia PREROUTING da tabela nat, ou o equivalente em nftables. A regra corresponde ao endereço e à porta públicos e depois reescreve o destino para o endereço privado da aplicação. O endereço de origem, a porta de origem e a carga útil ficam intactos, e o conntrack regista o mapeamento para que as respostas sejam reescritas à saída. O comportamento é o modelo tradicional de tradução de endereços descrito em RFC 3022.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

O ouvinte da aplicação nunca sabe que a ligação chegou através de uma tradução. Vê o endereço de origem real do cliente, o que é útil para registos de acesso e limites de velocidade, e responde ao endereço privado porque o conntrack inverte o mapeamento. Nada nesse caminho desencripta nem volta a encriptar: o TLS continua a funcionar entre o cliente e o certificado da própria aplicação.

A regra também fixa os modos de falha que encontrará mais tarde. Se o gateway encaminha mas o host da aplicação não tem nenhuma rota de regresso ao cliente, as respostas saem com a origem errada e o handshake bloqueia. Se uma segunda regra corresponder primeiro, a ordem decide o resultado, e iptables -t nat -L -n -v mostra os contadores que provam qual regra apanhou o pacote.

O túnel empacota o pacote antes de o ouvinte o ver

Uma VPN não publica a aplicação de todo. O cliente constrói um pacote exterior endereçado ao endereço público do gateway, encripta o pacote interior lá dentro, e o gateway desencripta e encaminha o pacote interior para o destino privado. Com WireGuard o transporte exterior é UDP, normalmente numa porta alta; com OpenVPN sobre TCP 443 o pacote exterior parece TLS a tudo o que vigia o caminho.

Dentro do túnel o pacote interior conserva endereços privados: o endereço de túnel do cliente, digamos 10.8.0.6, e a aplicação em 10.20.30.40. Por isso o ouvinte vê uma origem do conjunto do túnel, e cada cliente partilha esse gateway como salto seguinte. Os registos de acesso atrás de uma VPN mostram frequentemente o gateway em vez do utilizador exatamente por esta razão, a menos que o gateway preserve a origem original.

O empacotamento custa espaço de cabeçalho, e essa é a única diferença ao nível do mecanismo com uma consequência mensurável. Um cabeçalho IP exterior mais UDP mais o próprio cabeçalho do WireGuard consomem o MTU do caminho, pelo que os pacotes grandes têm de ser fragmentados ou a pilha TCP interior tem de limitar o seu MSS. Uma transferência que funciona no caminho redirecionado pode bloquear no túnel quando um equipamento intermédio descarta o ICMP que teria sinalizado o MTU menor.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

A exposição decide-se na entrada, não pela cifra

Ambos os desenhos terminam no mesmo ouvinte TLS, pelo que ambos herdam o mesmo certificado, as mesmas versões de protocolo e o mesmo login da aplicação. O que muda é quem pode iniciar um handshake. Com um redirecionamento público, qualquer host que alcance 203.0.113.10:443 obtém um handshake TCP e um TLS ClientHello antes de a autorização da aplicação ser sequer consultada. Com acesso apenas por túnel, o ouvinte só é acessível a partir de endereços que o gateway encaminha para o túnel, e o SYN de um desconhecido morre na política do gateway.

Essa diferença diz respeito à acessibilidade, não à confidencialidade. Um serviço HTTPS redirecionado não é texto simples, e uma VPN não remove a necessidade de autenticação da aplicação: a admissão ao túnel responde se um dispositivo pode enviar pacotes para esta rede, enquanto a aplicação de ficheiros responde se um utilizador pode ler um documento. Confundir as duas coisas é como as equipas acabam com uma VPN que dá toda a LAN e uma aplicação com uma única palavra-passe partilhada.

Inspecione o ouvinte e a política em separado, porque qualquer dos dois pode ser mais amplo do que supõe:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

Se ss mostrar que o ouvinte está ligado a 0.0.0.0, a aplicação é acessível de onde o encaminhamento e a política da firewall o permitirem, e o redirecionamento é apenas uma das formas de entrar. Ligá-lo ao endereço privado, ou restringir o intervalo de origem na firewall, é uma decisão separada da escolha de uma VPN, e é a decisão que realmente reduz a exposição.

Meça o caminho, não o rótulo

Quando alguém afirma que o redirecionamento é mais rápido, a comparação honesta mantém tudo o resto constante: o mesmo cliente, a mesma rede de acesso, o mesmo ficheiro, a mesma configuração TLS, o mesmo host da aplicação. Execute a transferência duas vezes por caminho e registe o tempo total, o número de falhas e a capacidade de resposta, não a saída de um teste de velocidade não relacionado.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

Esses números separam o estabelecimento da ligação do tempo de transferência, o que importa porque os dois caminhos normalmente diferem na latência de ida e volta e no MTU, não no custo da cifra. O trabalho de TLS ocorre nos extremos em ambos os desenhos, e um túnel acrescenta encapsulamento, uma rota diferente e talvez um gateway mais ocupado. Se o caminho do túnel for mais longo ou o seu gateway estiver carregado, a diferença pertence ao caminho e não à palavra encriptação.

Escolha a política de entrada de que o serviço realmente precisa e depois decida se uma diferença medida justifica alterá-la. Um redirecionamento público adequa-se a um serviço destinado à internet aberta, com restrições de origem, TLS atualizado e monitorização à frente. O acesso apenas por túnel adequa-se a uma ferramenta interna cujos utilizadores já estão inscritos, desde que o encaminhamento do gateway e as permissões da aplicação sejam ambos mais estreitos do que toda a LAN.

Antes de dar o desenho por terminado, confirme quatro coisas: a que endereço está ligado o ouvinte, que regra ou rota admite o pacote, se o caminho de regresso funciona a partir do endereço real do cliente e se as cargas grandes sobrevivem ao MTU. Cada uma tem um comando acima, e nenhuma é respondida pela palavra seguro nem por um gráfico de largura de banda.