Redirecționare de port versus acces VPN: unde ajunge de fapt pachetul

O redirecționare de port rescrie destinația și se oprește acolo; un VPN împachetează pachetul mai întâi. Vedeți ce strat schimbă fiecare și ce înseamnă asta pentru HTTPS.

Două arhitecturi, o aplicație HTTPS, iar pachetul urmează o rută diferită în fiecare. O redirecționare de port schimbă unde este livrat pachetul și lasă restul neatins. Un VPN transportă mai întâi acel pachet într-un alt pachet, astfel încât ascultătorul aplicației vede o altă sursă și o sarcină utilă maximă mai mică. Criptarea despre care se discută este prezentă în ambele cazuri, pentru că aplicația rămâne HTTPS; ceea ce diferă este cine poate deschide o conexiune și ce poate observa rețeaua dintre ele. Această distincție rezolvă majoritatea întrebărilor practice.

Regula DNAT rescrie destinația și se oprește acolo

Pe un gateway Linux, publicarea unui serviciu înseamnă o regulă în lanțul PREROUTING al tabelei nat, sau echivalentul în nftables. Regula se potrivește cu adresa și portul publice, apoi rescrie destinația către adresa privată a aplicației. Adresa sursă, portul sursă și sarcina utilă rămân neatinse, iar conntrack înregistrează maparea astfel încât răspunsurile să fie rescrise la ieșire. Comportamentul este modelul tradițional de traducere a adreselor descris în 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

Ascultătorul aplicației nu află niciodată că conexiunea a sosit printr-o traducere. Vede adresa sursă reală a clientului, utilă pentru jurnalele de acces și limitele de viteză, și răspunde la adresa privată pentru că conntrack inversează maparea. Nimic pe acea rută nu decriptează sau re-criptează: TLS funcționează în continuare între client și certificatul propriu al aplicației.

Regula stabilește și modurile de eșec pe care le veți întâlni mai târziu. Dacă gateway-ul redirecționează dar gazda aplicației nu are nicio rută înapoi la client, răspunsurile pleacă cu sursa greșită și strângerea de mână se blochează. Dacă o a doua regulă se potrivește prima, ordinea decide rezultatul, iar iptables -t nat -L -n -v arată contoarele care dovedesc ce regulă a luat pachetul.

Tunelul împachetează pachetul înainte ca ascultătorul să-l vadă

Un VPN nu publică deloc aplicația. Clientul construiește un pachet exterior adresat adresei publice a gateway-ului, criptează pachetul interior în el, iar gateway-ul decriptează și rutează pachetul interior către destinația privată. Cu WireGuard transportul exterior este UDP, de obicei pe un port înalt; cu OpenVPN peste TCP 443 pachetul exterior arată ca TLS pentru tot ce supraveghează ruta.

În interiorul tunelului pachetul interior păstrează adrese private: adresa de tunel a clientului, să zicem 10.8.0.6, și aplicația la 10.20.30.40. De aceea ascultătorul vede o sursă din pool-ul tunelului, iar fiecare client împarte acel gateway ca următor salt. Jurnalele de acces din spatele unui VPN arată adesea gateway-ul în locul utilizatorului exact din acest motiv, dacă gateway-ul nu păstrează sursa originală.

Împachetarea costă spațiu de antet, iar aceasta este singura diferență la nivel de mecanism cu o consecință măsurabilă. Un antet IP exterior plus UDP plus antetul propriu al WireGuard consumă din MTU-ul rutei, așa că pachetele mari trebuie fragmentate sau stiva TCP interioară trebuie să-și limiteze MSS-ul. O transferare care funcționează pe ruta redirecționată se poate bloca pe tunel când un echipament intermediar aruncă ICMP-ul care ar fi semnalat MTU-ul mai mic.

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

Expunerea se decide la intrare, nu prin cifru

Ambele arhitecturi se termină la același ascultător TLS, așa că ambele moștenesc același certificat, aceleași versiuni de protocol și aceeași autentificare a aplicației. Ceea ce se schimbă este cine are voie să înceapă o strângere de mână. Cu o redirecționare publică, orice gazdă care ajunge la 203.0.113.10:443 primește o strângere de mână TCP și un TLS ClientHello înainte ca autorizarea aplicației să fie măcar consultată. Cu acces doar prin tunel, ascultătorul este accesibil doar din adrese pe care gateway-ul le rutează în tunel, iar SYN-ul unui străin moare la politica gateway-ului.

Această diferență ține de accesibilitate, nu de confidențialitate. Un serviciu HTTPS redirecționat nu este text simplu, iar un VPN nu elimină nevoia de autentificare a aplicației: admiterea în tunel răspunde dacă un dispozitiv poate trimite pachete în această rețea, în timp ce aplicația de fișiere răspunde dacă un utilizator poate citi un document. Confundarea celor două este modul în care echipele ajung cu un VPN care dă tot LAN-ul și o aplicație cu o singură parolă comună.

Inspectați ascultătorul și politica separat, pentru că oricare dintre ele poate fi mai larg decât presupuneți:

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

Dacă ss arată că ascultătorul este legat de 0.0.0.0, aplicația este accesibilă de oriunde rutarea și politica firewall-ului permit, iar redirecționarea este doar una dintre căile de intrare. Legarea de adresa privată, sau restricționarea intervalului de surse în firewall, este o decizie separată de alegerea unui VPN, și ea este decizia care chiar reduce expunerea.

Măsurați ruta, nu eticheta

Când cineva susține că redirecționarea este mai rapidă, comparația onestă păstrează tot restul constant: același client, aceeași rețea de acces, același fișier, aceeași configurație TLS, aceeași gazdă a aplicației. Rulați transferul de două ori pe rută și notați timpul total, numărul de eșecuri și receptivitatea, nu rezultatul unui test de viteză fără legătură.

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

Aceste numere separă stabilirea conexiunii de timpul de transfer, ceea ce contează pentru că cele două rute diferă de obicei prin latența dus-întors și MTU, nu prin costul cifrului. Munca TLS are loc la capete în ambele arhitecturi, iar un tunel adaugă încapsulare, o rută diferită și poate un gateway mai încărcat. Dacă ruta tunelului este mai lungă sau gateway-ul ei este încărcat, diferența aparține rutei și nu cuvântului criptare.

Alegeți politica de intrare de care serviciul are într-adevăr nevoie, apoi decideți dacă o diferență măsurată justifică schimbarea ei. O redirecționare publică se potrivește unui serviciu destinat internetului deschis, cu restricții de sursă, TLS actualizat și monitorizare în față. Accesul doar prin tunel se potrivește unei unelte interne ai cărei utilizatori sunt deja înscriși, cu condiția ca rutarea gateway-ului și permisiunile aplicației să fie ambele mai înguste decât tot LAN-ul.

Înainte de a declara arhitectura terminată, confirmați patru lucruri: la ce adresă este legat ascultătorul, ce regulă sau rută admite pachetul, dacă ruta de întoarcere funcționează de la adresa reală a clientului și dacă sarcinile mari supraviețuiesc MTU-ului. Fiecare dintre ele are o comandă mai sus, iar niciuna nu primește răspuns de la cuvântul sigur sau de la un grafic de lățime de bandă.

Articole similare