Pordisuunamine vs VPN-i juurdepääs: kuhu pakett tegelikult läheb

Pordisuunamine kirjutab sihtkoha ümber ja jääb sinna; VPN pakib paketi esmalt sisse. Vaadake, millist kihti kumbki muudab ja mida see HTTPS-i jaoks tähendab.

Kaks lahendust, üks HTTPS-rakendus ja pakett läbib kummaski erineva tee. Pordisuunamine muudab, kuhu pakett toimetatakse, ja jätab ülejäänu puutumata. VPN kannab selle paketi esmalt teise paketi sees, nii et rakenduse kuulaja näeb teistsugust allikat ja väiksemat maksimaalset kasulikku koormust. Krüpteerimine, mille üle vaieldakse, on mõlemal juhul olemas, sest rakendus on endiselt HTTPS; erineb see, kes saab ühenduse avada ja mida vahepealne võrk jälgida suudab. See erinevus lahendab enamiku praktilistest küsimustest.

DNAT-reegel kirjutab sihtkoha ümber ja jääb sinna

Linuxi lüüsil tähendab teenuse avaldamine reeglit nat-tabeli PREROUTING-ahelas või nftablesis samaväärset. Reegel sobib avaliku aadressi ja pordiga ning kirjutab seejärel sihtkoha ümber rakenduse privaatsele aadressile. Allikaaadress, allikaport ja kasulik koormus jäävad puutumata ning conntrack salvestab vastenduse, et vastused väljumisel tagasi kirjutataks. Käitumine on traditsiooniline aadressitõlke mudel, mida kirjeldab 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

Rakenduse kuulaja ei saa kunagi teada, et ühendus saabus tõlke kaudu. Ta näeb kliendi tegelikku allikaaadressi, mis on kasulik juurdepääsulogide ja kiiruspiirangute jaoks, ning vastab privaatsele aadressile, sest conntrack pöörab vastenduse ümber. Midagi sellel teel ei dekrüpteeri ega krüpteeri uuesti: TLS töötab endiselt kliendi ja rakenduse enda sertifikaadi vahel.

Reegel määrab ka tõrkerežiimid, millega hiljem kokku puutute. Kui lüüs edastab, kuid rakenduse hostil puudub tagasitee kliendini, väljuvad vastused vale allikaga ja käepigistus jääb seisma. Kui teine reegel sobib esimesena, otsustab järjekord tulemuse, ja iptables -t nat -L -n -v näitab loendureid, mis tõestavad, milline reegel paketi võttis.

Tunnel mähkib paketi enne, kui kuulaja seda näeb

VPN ei avalda rakendust üldse. Klient koostab välise paketi, mis on adresseeritud lüüsi avalikule aadressile, krüpteerib selle sees oleva sisemise paketi, ning lüüs dekrüpteerib ja suunab sisemise paketi privaatsesse sihtkohta. WireGuardi puhul on väline transport UDP, tavaliselt kõrgel pordil; OpenVPN puhul üle TCP 443 näeb väline pakett kõige tee jälgija jaoks välja nagu TLS.

Tunneli sees hoiab sisemine pakett privaatseid aadresse: kliendi tunneliaadress, ütleme 10.8.0.6, ja rakendus aadressil 10.20.30.40. Seetõttu näeb kuulaja allikat tunnelipullist ning iga klient jagab seda lüüsi järgmise hüppena. VPN-i taga näitavad juurdepääsulogid sageli just sel põhjusel lüüsi, mitte kasutajat, kui lüüs ei säilita algset allikat.

Mähkimine maksab päise ruumi ja see on ainus mehhanismitasandi erinevus, millel on mõõdetav tagajärg. Väline IP-päis pluss UDP pluss WireGuardi enda päis söövad tee MTU-d, seega tuleb suured paketid fragmenteerida või sisemine TCP-pinu peab oma MSS-i piirama. Ülekanne, mis toimib suunatud teel, võib tunnelis takerduda, kui vahepealne seade viskab kõrvale ICMP, mis oleks väiksemat MTU-d teatanud.

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

Kokkupuude otsustatakse sissepääsul, mitte šifriga

Mõlemad lahendused lõpevad sama TLS-kuulaja juures, seega pärivad mõlemad sama sertifikaadi, samad protokolliversioonid ja sama rakenduse sisselogimise. Muutub see, kellel on lubatud käepigistust alustada. Avaliku suunamise korral saab iga host, mis jõuab aadressini 203.0.113.10:443, TCP-käepigistuse ja TLS ClientHello enne, kui teie rakenduse autoriseerimist üldse vaadatakse. Ainult tunneli kaudu juurdepääsul on kuulaja kättesaadav vaid aadressidelt, mille lüüs tunnelisse suunab, ja võõra SYN sureb lüüsi poliitikal.

See erinevus puudutab kättesaadavust, mitte konfidentsiaalsust. Suunatud HTTPS-teenus ei ole lihttekst ning VPN ei kõrvalda rakenduse autentimise vajadust: tunnelisse lubamine vastab, kas seade tohib sellesse võrku pakette saata, samas kui failirakendus vastab, kas kasutaja tohib dokumenti lugeda. Nende kahe segamine ongi see, kuidas meeskonnad jõuavad VPN-ini, mis annab kogu lokaalvõrgu, ja rakenduseni ühe ühise parooliga.

Uurige kuulajat ja poliitikat eraldi, sest kumbki võib olla laiem, kui eeldate:

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

Kui ss näitab, et kuulaja on seotud aadressiga 0.0.0.0, on rakendus kättesaadav sealt, kus marsruutimine ja tulemüüri poliitika lubavad, ning suunamine on vaid üks sissepääsuteedest. Privaatse aadressiga sidumine või allikavahemiku piiramine tulemüüris on VPN-i valikust eraldi otsus ja just see otsus kitsendab kokkupuudet tegelikult.

Mõõtke teed, mitte silti

Kui keegi väidab, et suunamine on kiirem, hoiab aus võrdlus kõik muu muutumatuna: sama klient, sama juurdepääsuvõrk, sama fail, sama TLS-konfiguratsioon, sama rakenduse host. Käivitage ülekanne iga tee kohta kaks korda ning kirjutage üles koguaeg, tõrgete arv ja reageerivus, mitte mõne kõrvalise kiirustesti väljund.

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

Need numbrid eraldavad ühenduse loomise ülekandeajast, mis on oluline, sest kaks teed erinevad tavaliselt edasi-tagasi latentsuse ja MTU poolest, mitte šifri kulukuse poolest. TLS-töö toimub mõlemas lahenduses otspunktides ning tunnel lisab kapseldamise, teistsuguse marsruudi ja võib-olla koormatum lüüsi. Kui tunnelitee on pikem või selle lüüs on koormatud, kuulub erinevus tee juurde, mitte sõna krüpteerimine juurde.

Valige sissepääsupoliitika, mida teenus tegelikult vajab, ja otsustage siis, kas mõõdetud erinevus õigustab selle muutmist. Avalik suunamine sobib avatud internetti mõeldud teenusele, kus on allikapiirangud, ajakohastatud TLS ja monitooring ees. Ainult tunneli kaudu juurdepääs sobib sisemisele tööriistale, mille kasutajad on juba registreeritud, eeldusel et lüüsi marsruutimine ja rakenduse load on mõlemad kogu lokaalvõrgust kitsamad.

Enne kui nimetate disaini valmis, kinnitage neli asja: millise aadressiga on kuulaja seotud, milline reegel või marsruut paketi sisse laseb, kas tagasitee töötab kliendi tegelikult aadressilt ja kas suured koormused läbivad MTU. Igaühe jaoks on ülal käsk ning ühelegi neist ei vasta sõna turvaline ega ribalaiuse graafik.

Seotud artiklid