Redirección de portos fronte a acceso por VPN: onde vai realmente o paquete

Dous deseños, unha aplicación HTTPS, e o paquete segue unha ruta distinta en cada un. Unha redirección de portos cambia onde se entrega o paquete e deixa intacto o resto. Unha VPN leva primeiro ese paquete dentro doutro paquete, de modo que o oínte da aplicación ve unha orixe distinta e unha carga útil máxima menor. O cifrado que a xente discute está presente en ambos os casos, porque a aplicación segue a ser HTTPS; o que cambia é quen pode abrir unha conexión e que pode observar a rede intermedia. Esa distinción resolve a maioría das preguntas prácticas.

A regra DNAT reescribe o destino e detense aí

Nunha pasarela Linux, publicar un servizo significa unha regra na cadea PREROUTING da táboa nat, ou o equivalente en nftables. A regra coincide co enderezo e o porto públicos e despois reescribe o destino ao enderezo privado da aplicación. O enderezo de orixe, o porto de orixe e a carga útil quedan intactos, e conntrack rexistra a correspondencia para que as respostas se reescriban á saída. O comportamento é o modelo tradicional de tradución de enderezos descrito en 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 oínte da aplicación nunca sabe que a conexión chegou mediante unha tradución. Ve o enderezo de orixe real do cliente, o que resulta útil para os rexistros de acceso e os límites de velocidade, e responde ao enderezo privado porque conntrack inverte a correspondencia. Nada nesa ruta descifra nin volve cifrar: TLS segue funcionando entre o cliente e o certificado propio da aplicación.

A regra tamén fixa os modos de fallo que atopará máis adiante. Se a pasarela reenvía pero o host da aplicación non ten ningunha ruta de volta ao cliente, as respostas saen coa orixe equivocada e o saúdo atasca. Se unha segunda regra coincide primeiro, a orde decide o resultado, e iptables -t nat -L -n -v mostra os contadores que demostran que regra levou o paquete.

O túnel envolve o paquete antes de que o oínte o vexa

Unha VPN non publica a aplicación en absoluto. O cliente constrúe un paquete exterior dirixido ao enderezo público da pasarela, cifra o paquete interior dentro del, e a pasarela descifra e encamiña o paquete interior ao destino privado. Con WireGuard o transporte exterior é UDP, normalmente nun porto alto; con OpenVPN sobre TCP 443 o paquete exterior parece TLS para calquera cousa que vixíe a ruta.

Dentro do túnel o paquete interior conserva enderezos privados: o enderezo de túnel do cliente, digamos 10.8.0.6, e a aplicación en 10.20.30.40. Por iso o oínte ve unha orixe do grupo do túnel, e cada cliente comparte esa pasarela como seguinte salto. Os rexistros de acceso detrás dunha VPN adoitan mostrar a pasarela en lugar do usuario exactamente por esta razón, salvo que a pasarela conserve a orixe orixinal.

O envoltorio custa espazo de cabeceira, e esa é a única diferenza a nivel de mecanismo cunha consecuencia medible. Unha cabeceira IP exterior máis UDP máis a propia cabeceira de WireGuard comen o MTU da ruta, así que os paquetes grandes deben fragmentarse ou a pila TCP interior debe limitar o seu MSS. Unha transferencia que funciona pola ruta redirixida pode atascarse no túnel cando un dispositivo intermedio descarta o ICMP que tería sinalado 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 exposición decídese na entrada, non polo cifrado

Ambos os deseños rematan no mesmo oínte TLS, así que ambos herdan o mesmo certificado, as mesmas versións de protocolo e o mesmo inicio de sesión da aplicación. O que cambia é quen pode iniciar un saúdo. Cunha redirección pública, calquera host que alcance 203.0.113.10:443 obtén un saúdo TCP e un ClientHello TLS antes de que se consulte sequera a autorización da aplicación. Con acceso só por túnel, o oínte é accesible unicamente desde enderezos que a pasarela encamiña ao túnel, e o SYN dun descoñecido morre na política da pasarela.

Esa diferenza ten que ver coa accesibilidade, non coa confidencialidade. Un servizo HTTPS redirixido non é texto plano, e unha VPN non elimina a necesidade de autenticación da aplicación: a admisión ao túnel responde se un dispositivo pode enviar paquetes a esta rede, mentres que a aplicación de ficheiros responde se un usuario pode ler un documento. Confundir ambas as dúas cousas é como os equipos acaban cunha VPN que concede toda a LAN e unha aplicación cun só contrasinal compartido.

Inspeccione o oínte e a política por separado, porque calquera dos dous pode ser máis amplo do que supón:

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 mostra que o oínte está ligado a 0.0.0.0, a aplicación é accesible desde onde o encamiñamento e a política de devasas o permitan, e a redirección é só unha das formas de entrar. Ligalo ao enderezo privado, ou restrinxir o rango de orixe na devasa, é unha decisión separada de escoller unha VPN, e é a decisión que realmente reduce a exposición.

Mida a ruta, non a etiqueta

Cando alguén afirma que a redirección é máis rápida, a comparación honesta mantén todo o demais constante: mesmo cliente, mesma rede de acceso, mesmo ficheiro, mesma configuración de TLS, mesmo host de aplicación. Execute a transferencia dúas veces por ruta e anote o tempo total, o número de fallos e a capacidade de resposta, non a saída dunha proba de velocidade non relacionada.

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

Eses números separan o establecemento da conexión do tempo de transferencia, o que importa porque as dúas rutas adoitan diferir en latencia de ida e volta e en MTU, non en custo de cifrado. O traballo de TLS ocorre nos extremos en ambos os deseños, e un túnel engade encapsulación, unha ruta distinta e quizais unha pasarela máis ocupada. Se a ruta do túnel é máis longa ou a súa pasarela está cargada, a diferenza pertence á ruta e non á palabra cifrado.

Escolla a política de entrada que o servizo necesita de verdade e despois decida se unha diferenza medida xustifica cambiala. Unha redirección pública encaixa cun servizo pensado para internet aberto, con restricións de orixe, TLS actualizado e monitorización diante. O acceso só por túnel encaixa cunha ferramenta interna cuxos usuarios xa están inscritos, sempre que o encamiñamento da pasarela e os permisos da aplicación sexan ambos máis estreitos que toda a LAN.

Antes de dar o deseño por terminado, confirme catro cousas: a que enderezo está ligado o oínte, que regra ou ruta admite o paquete, se a ruta de volta funciona desde o enderezo real do cliente e se as cargas grandes sobreviven ao MTU. Cada unha ten un comando arriba, e ningunha se responde coa palabra seguro nin cun gráfico de ancho de banda.