Redirecció de port contra accés per VPN: on va realment el paquet

Dos dissenys, una aplicació HTTPS, i el paquet segueix un camí diferent en cadascun. La redirecció de port canvia on es lliura el paquet i deixa la resta intacta. Una VPN porta primer aquest paquet dins d'un altre paquet, de manera que l'oient de l'aplicació veu una font diferent i una càrrega màxima més petita. El xifratge pel qual la gent discuteix és present en tots dos casos, perquè l'aplicació continua sent HTTPS; el que canvia és qui pot obrir una connexió i què pot observar la xarxa entremig. Aquesta distinció resol la majoria de les preguntes pràctiques.

La regla DNAT reescriu la destinació i s'atura aquí

En una passarel·la Linux, publicar un servei significa una regla a la cadena PREROUTING de la taula nat, o l'equivalent a nftables. La regla coincideix amb l'adreça i el port públics, i després reescriu la destinació cap a l'adreça privada de l'aplicació. L'adreça d'origen, el port d'origen i la càrrega queden intactes, i conntrack registra la correspondència perquè les respostes es reescriguin a la sortida. El comportament és el model tradicional de traducció d'adreces descrit a 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

L'oient de l'aplicació mai no sap que la connexió ha arribat a través d'una traducció. Veu l'adreça d'origen real del client, cosa útil per als registres d'accés i els límits de velocitat, i respon a l'adreça privada perquè conntrack inverteix la correspondència. Res en aquest camí desxifra ni torna a xifrar: TLS continua funcionant entre el client i el certificat propi de l'aplicació.

La regla també fixa els modes de fallada que trobareu més endavant. Si la passarel·la reenvia però l'amfitrió de l'aplicació no té cap ruta de tornada al client, les respostes surten amb una font incorrecta i l'apretada de mans s'encalla. Si una segona regla coincideix primer, l'ordre decideix el resultat, i iptables -t nat -L -n -v mostra els comptadors que proven quina regla es va endur el paquet.

El túnel embolcalla el paquet abans que l'oient el vegi

Una VPN no publica l'aplicació en absolut. El client construeix un paquet exterior adreçat a l'adreça pública de la passarel·la, xifra el paquet interior a dins, i la passarel·la desxifra i encamina el paquet interior cap a la destinació privada. Amb WireGuard el transport exterior és UDP, normalment en un port alt; amb OpenVPN sobre TCP 443 el paquet exterior sembla TLS a qualsevol cosa que vigilï el camí.

Dins del túnel el paquet interior conserva adreces privades: l'adreça de túnel del client, per exemple 10.8.0.6, i l'aplicació a 10.20.30.40. Per tant l'oient veu una font del pool del túnel, i cada client comparteix aquesta passarel·la com a següent salt. Els registres d'accés darrere d'una VPN sovint mostren la passarel·la en lloc de l'usuari exactament per aquest motiu, llevat que la passarel·la conservi la font original.

L'embolcall costa espai de capçalera, i aquesta és l'única diferència a nivell de mecanisme amb una conseqüència mesurable. Una capçalera IP exterior més UDP més la capçalera pròpia de WireGuard es mengen l'MTU del camí, així que els paquets grans s'han de fragmentar o la pila TCP interior ha de limitar el seu MSS. Una transferència que funciona pel camí redirigit pot encallar-se al túnel quan un dispositiu intermedi descarta l'ICMP que hauria indicat l'MTU més petit.

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

L'exposició es decideix a l'entrada, no pel xifratge

Tots dos dissenys acaben al mateix oient TLS, així que tots dos hereten el mateix certificat, les mateixes versions de protocol i el mateix inici de sessió de l'aplicació. El que canvia és qui pot iniciar una apretada de mans. Amb una redirecció pública, qualsevol amfitrió que arribi a 203.0.113.10:443 obté una apretada de mans TCP i un ClientHello TLS abans que es consulti l'autorització de l'aplicació. Amb accés només per túnel, l'oient és accessible només des d'adreces que la passarel·la encamina al túnel, i el SYN d'un desconegut mor a la política de la passarel·la.

Aquesta diferència és d'accessibilitat, no de confidencialitat. Un servei HTTPS redirigit no és text pla, i una VPN no elimina la necessitat d'autenticació de l'aplicació: l'admissió al túnel respon si un dispositiu pot enviar paquets en aquesta xarxa, mentre que l'aplicació de fitxers respon si un usuari pot llegir un document. Confondre les dues és com els equips acaben amb una VPN que atorga tota la LAN i una aplicació amb una sola contrasenya compartida.

Inspeccioneu l'oient i la política per separat, perquè qualsevol de les dues pot ser més àmplia del que suposeu:

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

Si ss mostra que l'oient està lligat a 0.0.0.0, l'aplicació és accessible des d'on l'encaminament i la política de tallafoc ho permeten, i la redirecció només és una de les maneres d'entrar-hi. Lligar-lo a l'adreça privada, o restringir el rang d'origen al tallafoc, és una decisió separada de triar una VPN, i és la decisió que realment redueix l'exposició.

Mesureu el camí, no l'etiqueta

Quan algú afirma que la redirecció és més ràpida, la comparació honesta manté tota la resta constant: mateix client, mateixa xarxa d'accés, mateix fitxer, mateixa configuració TLS, mateix amfitrió d'aplicació. Executeu la transferència dues vegades per camí i anoteu el temps total, el nombre de fallades i la capacitat de resposta, no la sortida d'una prova de velocitat no 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

Aquests números separen l'establiment de la connexió del temps de transferència, cosa que importa perquè els dos camins solen diferir en latència d'anada i tornada i MTU, no en cost de xifratge. La feina de TLS passa als extrems en tots dos dissenys, i un túnel afegeix encapsulament, una ruta diferent i potser una passarel·la més carregada. Si el camí del túnel és més llarg o la seva passarel·la està carregada, la diferència pertany al camí i no a la paraula xifratge.

Trieu la política d'entrada que el servei necessita de veritat, i després decidiu si una diferència mesurada justifica canviar-la. Una redirecció pública escau a un servei pensat per a internet obert, amb restriccions d'origen, TLS actualitzat i monitoratge al davant. L'accés només per túnel escau a una eina interna els usuaris de la qual ja estan inscrits, sempre que l'encaminament de la passarel·la i els permisos de l'aplicació siguin tots dos més estrets que tota la LAN.

Abans de donar el disseny per acabat, confirmeu quatre coses: a quina adreça està lligat l'oient, quina regla o ruta admet el paquet, si el camí de tornada funciona des de l'adreça real del client i si les càrregues grans sobreviuen a l'MTU. Cadascuna té una ordre més amunt, i cap no es respon amb la paraula segur ni amb un gràfic d'amplada de banda.