Prievado peradresavimas prieš VPN prieigą: kur paketas iš tikrųjų keliauja

Prievado peradresavimas perrašo tikslą ir ten sustoja; VPN pirmiausia įvynioja paketą. Pažiūrėkite, kurį sluoksnį kiekvienas keičia ir ką tai reiškia HTTPS.

Du sprendimai, viena HTTPS programa, o paketas kiekviename keliauja skirtingu maršrutu. Prievado peradresavimas pakeičia, kur paketas pristatomas, o likusią dalį palieka nepakeistą. VPN pirmiausia neša tą paketą kito paketo viduje, todėl programos klausytojas mato kitą šaltinį ir mažesnį didžiausią naudingą krūvį. Šifravimas, dėl kurio ginčijamasi, yra abiem atvejais, nes programa vis dar HTTPS; skiriasi tai, kas gali atidaryti ryšį ir ką gali stebėti tarpininkaujantis tinklas. Šis skirtumas išsprendžia daugumą praktinių klausimų.

DNAT taisyklė perrašo tikslą ir ten sustoja

Linux šliuže paskelbti paslaugą reiškia taisyklę nat lentelės PREROUTING grandinėje arba atitikmenį nftables. Taisyklė atitinka viešą adresą ir prievadą, tada perrašo tikslą į programos privatų adresą. Šaltinio adresas, šaltinio prievadas ir naudingas krūvis lieka nepaliesti, o conntrack įrašo susiejimą, kad atsakymai išeinant būtų perrašomi atgal. Elgsena yra tradicinis adresų vertimo modelis, aprašytas 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

Programos klausytojas niekada nesužino, kad ryšys atėjo per vertimą. Jis mato tikrąjį kliento šaltinio adresą, kas naudinga prieigos žurnalams ir spartos riboms, ir atsako į privatų adresą, nes conntrack apsuka susiejimą. Niekas tame kelyje neiššifruoja ir iš naujo neužšifruoja: TLS vis dar veikia tarp kliento ir pačios programos sertifikato.

Taisyklė taip pat nustato gedimų režimus, su kuriais susidursite vėliau. Jei šliuzas persiunčia, bet programos mazgas neturi grįžimo kelio iki kliento, atsakymai išeina su netinkamu šaltiniu ir rankos paspaudimas sustoja. Jei antroji taisyklė atitinka pirmoji, tvarka lemia rezultatą, o iptables -t nat -L -n -v rodo skaitiklius, įrodančius, kuri taisyklė paėmė paketą.

Tunelis įvynioja paketą, kol klausytojas jo nepamato

VPN visai neskelbia programos. Klientas sukuria išorinį paketą, adresuotą šliuzo viešajam adresui, užšifruoja vidinį paketą jame, o šliuzas iššifruoja ir nukreipia vidinį paketą į privatų tikslą. Su WireGuard išorinis transportas yra UDP, paprastai aukštame prievade; su OpenVPN per TCP 443 išorinis paketas atrodo kaip TLS bet kam, kas stebi kelią.

Tunelio viduje vidinis paketas išlaiko privačius adresus: kliento tunelio adresą, tarkim 10.8.0.6, ir programą 10.20.30.40. Todėl klausytojas mato šaltinį iš tunelio baseino, ir kiekvienas klientas dalijasi tuo šliuzu kaip kitu šuoliu. Prieigos žurnalai už VPN dažnai rodo šliuzą, o ne vartotoją būtent dėl šios priežasties, nebent šliuzas išsaugo pradinį šaltinį.

Įvyniojimas kainuoja antraštės vietos, ir tai vienintelis mechanizmo lygmens skirtumas su išmatuojama pasekme. Išorinė IP antraštė plius UDP plius pati WireGuard antraštė suvalgo kelio MTU, todėl dideli paketai turi būti fragmentuojami arba vidinis TCP stekas turi apriboti savo MSS. Peradresuotu keliu veikiantis perdavimas gali strigti tunelyje, kai tarpinis įrenginys numeta ICMP, kuris būtų pranešęs apie mažesnį MTU.

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

Poveikis sprendžiamas įėjime, o ne šifru

Abu sprendimai baigiasi tame pačiame TLS klausytoje, todėl abu paveldi tą patį sertifikatą, tas pačias protokolo versijas ir tą patį programos prisijungimą. Kinta tai, kam leidžiama pradėti rankos paspaudimą. Su viešu peradresavimu bet kuris mazgas, pasiekiantis 203.0.113.10:443, gauna TCP rankos paspaudimą ir TLS ClientHello dar prieš apskritai patikrinant jūsų programos autorizaciją. Su prieiga tik per tunelį klausytojas pasiekiamas tik iš adresų, kuriuos šliuzas nukreipia į tunelį, o svetimo SYN miršta šliuzo politikoje.

Šis skirtumas susijęs su pasiekiamumu, o ne su konfidencialumu. Peradresuota HTTPS paslauga nėra atviras tekstas, o VPN nepanaikina programos autentifikavimo poreikio: priėmimas į tunelį atsako, ar įrenginys gali siųsti paketus į šį tinklą, o failų programa atsako, ar vartotojas gali skaityti dokumentą. Šių dviejų maišymas yra tai, kaip komandos gauna VPN, kuris duoda visą LAN, ir programą su vienu bendru slaptažodžiu.

Tikrinkite klausytoją ir politiką atskirai, nes bet kuris iš jų gali būti platesnis, nei manote:

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

Jei ss rodo, kad klausytojas susietas su 0.0.0.0, programa pasiekiama iš bet kur, kur leidžia maršrutizavimas ir ugniasienės politika, o peradresavimas tėra vienas iš įėjimo būdų. Susiejimas su privačiu adresu arba šaltinio diapazono apribojimas ugniasienėje yra atskiras sprendimas nuo VPN pasirinkimo, ir būtent jis iš tikrųjų sumažina poveikį.

Matuokite kelią, o ne etiketę

Kai kas nors teigia, kad peradresavimas greitesnis, sąžiningas palyginimas išlaiko visa kita pastovu: tas pats klientas, tas pats prieigos tinklas, tas pats failas, ta pati TLS konfigūracija, tas pats programos mazgas. Paleiskite perdavimą du kartus kiekvienu keliu ir užrašykite bendrą laiką, gedimų skaičių ir reagavimą, o ne nesusijusio greičio testo išvestį.

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

Šie skaičiai atskiria ryšio užmezgimą nuo perdavimo laiko, kas svarbu, nes du keliai paprastai skiriasi kelionės pirmyn ir atgal vėlavimu bei MTU, o ne šifro kaina. TLS darbas vyksta galiniuose taškuose abiejuose sprendimuose, o tunelis prideda inkapsuliavimą, kitą maršrutą ir galbūt labiau apkrautą šliuzą. Jei tunelio kelias ilgesnis arba jo šliuzas apkrautas, skirtumas priklauso keliui, o ne žodžiui šifravimas.

Pasirinkite įėjimo politiką, kurios paslaugai tikrai reikia, tada nuspręskite, ar išmatuotas skirtumas pateisina ją keisti. Viešas peradresavimas tinka paslaugai, skirtai atviram internetui, su šaltinio apribojimais, atnaujintu TLS ir stebėjimu priešais. Prieiga tik per tunelį tinka vidiniam įrankiui, kurio vartotojai jau užregistruoti, jei šliuzo maršrutizavimas ir programos leidimai abu siauresni už visą LAN.

Prieš skelbdami sprendimą baigtu, patvirtinkite keturis dalykus: su kokiu adresu susietas klausytojas, kuri taisyklė ar maršrutas įleidžia paketą, ar grįžimo kelias veikia iš tikrojo kliento adreso ir ar dideli naudingi krūviai išgyvena MTU. Kiekvienam iš jų aukščiau yra komanda, ir nė vieno neatsako žodis saugu arba pralaidumo grafikas.

Susiję straipsniai