Portu-birbidalketa VPN sarbidearen aurka: norantz doan paketea benetan

Portu-birbidalketak helburua berridazten du eta han gelditzen da; VPN batek paketea lehenengo bildu egiten du. Ikusi zein geruza aldatzen duen bakoitzak eta zer esan nahi duen horrek HTTPSerako.

Bi diseinu, HTTPS aplikazio bat, eta paketeak bide desberdina hartzen du bakoitzean. Portu-birbidalketak aldatzen du paketea non entregatzen den eta gainerakoa ukitu gabe uzten du. VPN batek pakete hori beste pakete baten barruan eramaten du lehenengo, beraz aplikazioaren entzuleak beste iturburu bat eta karga erabilgarri maximo txikiagoa ikusten ditu. Jendeak eztabaidatzen duen zifratzea bi kasuetan dago, aplikazioa HTTPS delako oraindik; desberdina da nork ireki dezakeen konexioa eta erdiko sareak zer behatu dezakeen. Bereizketa horrek erantzuten ditu galdera praktiko gehienak.

DNAT arauak helburua berridazten du eta han gelditzen da

Linux atean, zerbitzu bat argitaratzeak nat taularen PREROUTING katean arau bat eskatzen du, edo nftableseko baliokidea. Arauak helbide eta portu publikoak bat datoz, eta gero helburua aplikazioaren helbide pribatura berridazten du. Iturburu helbidea, iturburu portua eta karga ukitugabe geratzen dira, eta conntrackek mapaketa erregistratzen du, erantzunak irtetean berridatz daitezen. Jokabidea RFC 3022 dokumentuan deskribatutako helbide-itzulpen eredu tradizionala da.

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

Aplikazioaren entzuleak ez du inoiz jakiten konexioa itzulpen baten bidez iritsi denik. Bezeroaren benetako iturburu helbidea ikusten du, hau da, sarbide-erregistroetarako eta abiadura-mugetarako erabilgarria, eta helbide pribatuari erantzuten dio conntrackek mapaketa alderantzikatzen duelako. Bide horretan ezerk ez du deszifratzen edo berriz zifratzen: TLS oraindik bezeroaren eta aplikazioaren beraren ziurtagiriaren artean dabil.

Arauak geroago aurkituko dituzun hutsegite-moduak ere finkatzen ditu. Ateak aurreratzen badu baina aplikazioaren ostalariak bezerorako itzulbiderik ez badu, erantzunak iturburu okerrarekin ateratzen dira eta esku-ematea trabatzen da. Bigarren arau bat lehenengo bat badator, ordenak erabakitzen du emaitza, eta iptables -t nat -L -n -v aginduak paketea zein arauk hartu duen frogatzen duten kontagailuak erakusten ditu.

Tunelak paketea biltzen du entzuleak ikusi aurretik

VPN batek ez du aplikazioa argitaratzen. Bezeroak atearen helbide publikora zuzendutako kanpoko pakete bat eraikitzen du, barruko paketea haren barruan zifratzen du, eta ateak deszifratu eta barruko paketea helburu pribatura bideratzen du. WireGuardekin kanpoko garraioa UDP da, normalean portu altuan; OpenVPN TCP 443ren gainean doanean, kanpoko paketea TLS bezalakoa da bidea behatzen duen edozerentzat.

Tunelaren barruan barruko paketeak helbide pribatuak gordetzen ditu: bezeroaren tunel helbidea, demagun 10.8.0.6, eta aplikazioa 10.20.30.40 helbidean. Beraz, entzuleak tunel multzoko iturburu bat ikusten du, eta bezero bakoitzak ate hori partekatzen du hurrengo jauzi gisa. VPN baten atzeko sarbide-erregistzoek sarritan erabiltzailearen ordez atea erakusten dute arrazoi horregatik, atikoak jatorrizko iturburua gordetzen ez badu behintzat.

Bilkitzeak goiburu-espazioa kostatzen du, eta hori da ondorio neurgarria duen mekanismo-mailako desberdintasun bakarra. Kanpoko IP goiburuak gehi UDPk gehi WireGuarden beraren goiburuak bidearen MTUa jaten dute, beraz pakete handiak zatitu behar dira edo barruko TCP pila bere MSSa mugatu behar da. Birbidalitako bidetik funtzionatzen duen transferentzia batek tunelean trabatu daiteke tarteko gailu batek MTU txikiagoa adieraziko lukeen ICMPa botatzen duenean.

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

Esposizioa sarreran erabakitzen da, ez zifratzean

Bi diseinuak TLS entzule berean amaitzen dira, beraz biek ziurtagiri bera, protokolo-bertsio berak eta aplikazioaren saio-hasiera bera heredatzen dituzte. Aldatzen dena da nork duen esku-ematea hasteko baimena. Birbidalketa publikoarekin, 203.0.113.10:443 lortzen duen edozein ostalarik TCP esku-ematea eta TLS ClientHello jasotzen ditu zure aplikazioaren autorizazioa kontsultatu aurretik. Tunel bidezko sarbide soilarekin, entzulea ateko politikak tunelean bideratzen dituen helbideetatik soilik da irisgarria, eta arrotz baten SYNak atearen politikan hiltzen da.

Desberdintasun hori irisgarritasunari buruzkoa da, ez konfidentzialtasunari. Birbidalitako HTTPS zerbitzu bat ez da testu hutsa, eta VPN batek ez du aplikazioaren autentifikazioaren beharra kentzen: tunelera onartzeak erantzuten du gailu batek sare honetara paketeak bidal ditzakeen, eta fitxategi aplikazioak erantzuten du erabiltzaile batek dokumentu bat irakur dezakeen. Biak nahastea da taldeek LAN osoa ematen duen VPN batekin eta pasahitz partekatu bakarreko aplikazio batekin amaitzeko modua.

Aztertu entzulea eta politika bereizita, edozein izan baitaiteke uste duzuna baino zabalagoa:

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

ss aginduak entzulea 0.0.0.0 helbidera lotuta dagoela erakusten badu, aplikazioa bideratzeak eta suebaki-politikak uzten duten edonondik da irisgarria, eta birbidalketa sartzeko bideetako bat baino ez da. Helbide pribatura lotzea edo suebakian iturburu-tartea murriztea VPN bat aukeratzearen erabaki bereizia da, eta esposizioa benetan murrizten duen erabakia da.

Neurtu bidea, ez etiketa

Norbaitek birbidalketa azkarragoa dela dioenean, konparazio zintzoak gainerako guztia konstante mantentzen du: bezero bera, sarbide-sare bera, fitxategi bera, TLS konfigurazio bera, aplikazio-ostalari bera. Exekutatu transferentzia birritan bideko eta idatzi denbora osoa, hutsegite-kopurua eta erantzukizuna, ez erlaziorik gabeko abiadura-proba baten irteera.

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

Zenbaki horiek konexioaren ezarpena transferentzia-denboratik bereizten dute, eta hori garrantzitsua da bi bideek normalean joan-etorriko latentzian eta MTUn desberdintzen direlako, ez zifratze-kostuan. TLS lana muturretan gertatzen da bi diseinuetan, eta tunelek kapsulatzea, beste ibilbide bat eta agian ate okupatuagoa gehitzen ditu. Tunelaren bidea luzeagoa bada edo bere atea kargatuta badago, desberdintasuna bidearena da, ez zifratze hitzarena.

Aukeratu zerbitzuak benetan behar duen sarrera-politika, eta gero erabaki neurtutako desberdintasun batek hura aldatzea justifikatzen duen. Birbidalketa publikoak internet irekiko zerbitzu baterako egokia da, iturburu-murrizketekin, TLS eguneratuta eta aurrean monitorizazioa duelarik. Tunel bidezko sarbide soila barne-tresna batentzat egokia da, haren erabiltzaileak dagoeneko izena emanda badaude, betiere atearen bideratzea eta aplikazioaren baimenak LAN osoa baino estuagoak badira.

Diseinua amaitutzat eman aurretik, berretsi lau gauza: entzulea zein helbidetara lotuta dagoen, zein arak edo bidek onartzen duen paketea, itzulbidea bezeroaren benetako helbidetik funtzionatzen duen eta karga handiek MTUa gainditzen duten. Horietako bakoitzak goiko komando bat du, eta bat ere ez da erantzuten seguru hitzarekin edo banda-zabaleraren grafiko batekin.

Erlazionatutako artikuluak