Përcjellja e portës kundrejt aksesit VPN: ku shkon në të vërtetë paketa

Dy dizajne, një aplikacion HTTPS, dhe paketa ndjek një rrugë të ndryshme në secilin. Përcjellja e portës ndryshon ku dorëzohet paketa dhe pjesën tjetër e lë të paprekur. Një VPN e mbart më parë atë paketë brenda një pakete tjetër, kështu që dëgjuesi i aplikacionit sheh një burim tjetër dhe një ngarkesë maksimale më të vogël. Kriptimi për të cilin njerëzit debatojnë është i pranishëm në të dyja rastet, sepse aplikacioni është ende HTTPS; ajo që ndryshon është kush mund të hapë një lidhje dhe çfarë mund të vëzhgojë rrjeti në mes. Ky dallim zgjidh shumicën e pyetjeve praktike.

Rregulli DNAT rishkruan destinacionin dhe ndalon aty

Në një portë Linux, publikimi i një shërbimi do të thotë një rregull në zinxhirin PREROUTING të tabelës nat, ose ekuivalenti në nftables. Rregulli përputhet me adresën dhe portën publike, pastaj rishkruan destinacionin në adresën private të aplikacionit. Adresa e burimit, porta e burimit dhe ngarkesa mbeten të paprekura, dhe conntrack regjistron hartëzimin që përgjigjet të rishkruhen në dalje. Sjellja është modeli tradicional i përkthimit të adresave i përshkruar 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

Dëgjuesi i aplikacionit nuk mëson kurrë se lidhja erdhi përmes një përkthimi. Ai sheh adresën e vërtetë të burimit të klientit, e dobishme për regjistrat e aksesit dhe kufijtë e shpejtësisë, dhe përgjigjet në adresën private sepse conntrack e kthen hartëzimin. Asgjë në atë rrugë nuk dekripton ose rikripton: TLS vazhdon të punojë midis klientit dhe certifikatës së vetë aplikacionit.

Rregulli përcakton gjithashtu mënyrat e dështimit që do të takoni më vonë. Nëse porta përcjell por hosti i aplikacionit nuk ka asnjë rrugë kthimi te klienti, përgjigjet dalin me burimin e gabuar dhe shtrëngimi i duarve ngec. Nëse një rregull i dytë përputhet i pari, rendi vendos rezultatin, dhe iptables -t nat -L -n -v tregon numëruesit që provojnë cili rregull mori paketën.

Tuneli e mbështjell paketën para se dëgjuesi ta shohë

Një VPN nuk e publikon fare aplikacionin. Klienti ndërton një paketë të jashtme drejtuar adresës publike të portës, kripton paketën e brendshme brenda saj, dhe porta dekripton dhe e drejton paketën e brendshme te destinacioni privat. Me WireGuard transporti i jashtëm është UDP, zakonisht në një portë të lartë; me OpenVPN mbi TCP 443 paketa e jashtme duket si TLS për çdo gjë që vëzhgon rrugën.

Brenda tunelit paketa e brendshme ruan adresa private: adresa e tunelit të klientit, të themi 10.8.0.6, dhe aplikacioni në 10.20.30.40. Prandaj dëgjuesi sheh një burim nga grupi i tunelit, dhe çdo klient ndan atë portë si hapin tjetër. Regjistrat e aksesit pas një VPN shpesh tregojnë portën në vend të përdoruesit pikërisht për këtë arsye, përveç nëse porta ruan burimin origjinal.

Mbështjellja kushton hapësirë në kokë, dhe ky është i vetmi dallim në nivel mekanizmi me një pasojë të matshme. Një kokë IP e jashtme plus UDP plus koka e vetë WireGuard hanë nga MTU i rrugës, kështu që paketat e mëdha duhet të fragmentohen ose stiva TCP e brendshme duhet të kufizojë MSS-në e saj. Një transferim që funksionon në rrugën e përcjellë mund të ngecë në tunel kur një pajisje e ndërmjetme hedh ICMP-në që do të sinjalizonte MTU-në më të vogël.

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

Ekspozimi vendoset në hyrje, jo nga shifra

Të dyja dizajnet përfundojnë te i njëjti dëgjues TLS, prandaj të dy trashëgojnë të njëjtin certifikatë, të njëjtat versione protokolli dhe të njëjtin hyrje në aplikacion. Ajo që ndryshon është kush lejohet të fillojë një shtrëngim duarsh. Me një përcjellje publike, çdo host që arrin 203.0.113.10:443 merr një shtrëngim duarsh TCP dhe një TLS ClientHello para se autorizimi i aplikacionit tuaj të konsiderohet fare. Me akses vetëm përmes tunelit, dëgjuesi arrihet vetëm nga adresat që porta i drejton në tunel, dhe SYN i një të huaji vdes në politikën e portës.

Ky dallim ka të bëjë me arritshmërinë, jo me konfidencialitetin. Një shërbim HTTPS i përcjellë nuk është tekst i thjeshtë, dhe një VPN nuk e heq nevojën për vërtetim të aplikacionit: pranimi në tunel përgjigjet nëse një pajisje mund të dërgojë paketa në këtë rrjet, ndërsa aplikacioni i skedarëve përgjigjet nëse një përdorues mund të lexojë një dokument. Përzierja e të dyjave është mënyra se si ekipet përfundojnë me një VPN që jep të gjithë LAN-in dhe një aplikacion me një fjalëkalim të përbashkët.

Ekzaminoni dëgjuesin dhe politikën veçmas, sepse secili prej tyre mund të jetë më i gjerë sesa supozoni:

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

Nëse ss tregon se dëgjuesi është i lidhur me 0.0.0.0, aplikacioni arrihet nga kudo që lejojnë rrugëzimi dhe politika e murit të zjarrit, dhe përcjellja është vetëm një nga rrugët e hyrjes. Lidhja me adresën private, ose kufizimi i intervalit të burimit në murin e zjarrit, është një vendim i veçantë nga zgjedhja e një VPN, dhe është ai vendim që zvogëlon vërtet ekspozimin.

Matni rrugën, jo etiketën

Kur dikush pretendon se përcjellja është më e shpejtë, krahasimi i ndershëm mban çdo gjë tjetër konstante: i njëjti klient, i njëjti rrjet aksesi, i njëjti skedar, e njëjta konfigurim TLS, i njëjti host aplikacioni. Ekzekutoni transferimin dy herë për rrugë dhe shënoni kohën totale, numrin e dështimeve dhe reagimin, jo rezultatin e një testi shpejtësie të palidhur.

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

Këto numra ndajnë vendosjen e lidhjes nga koha e transferimit, çka ka rëndësi sepse dy rrugët zakonisht ndryshojnë në vonesën vajtje-ardhje dhe MTU, jo në koston e shifrës. Puna e TLS ndodh në skaje në të dyja dizajnet, dhe një tunel shton inkapsulim, një rrugë tjetër dhe ndoshta një portë më të ngarkuar. Nëse rruga e tunelit është më e gjatë ose porta e tij është e ngarkuar, dallimi i takon rrugës dhe jo fjalës kriptim.

Zgjidhni politikën e hyrjes që shërbimi ka vërtet nevojë, pastaj vendosni nëse një dallim i matur e justifikon ndryshimin e saj. Përcjellja publike u përshtatet një shërbimi të destinuar për internetin e hapur, me kufizime burimi, TLS të përditësuar dhe monitorim para tij. Aksesi vetëm përmes tunelit u përshtatet një mjeti të brendshëm, përdoruesit e të cilit janë regjistruar tashmë, me kusht që rrugëzimi i portës dhe lejet e aplikacionit të jenë të dyja më të ngushta se i gjithë LAN-i.

Përpara se ta shpallni dizajnin të përfunduar, konfirmoni katër gjëra: në cilën adresë është lidhur dëgjuesi, cili rregull ose rrugë e lejon paketën brenda, a funksionon rruga e kthimit nga adresa e vërtetë e klientit dhe a i mbijetojnë ngarkesat e mëdha MTU-së. Secila prej tyre ka një komandë më sipër, dhe asnjërës nuk i përgjigjet fjala i sigurt ose një grafik gjerësie brezi.