Portu pāradresēšana pret VPN piekļuvi: kur pakete patiešām aiziet

Portu pāradresēšana pārraksta galamērķi un tur apstājas; VPN vispirms iesaiņo paketi. Skatiet, kuru slāni katrs maina, un ko tas nozīmē HTTPS.

Divi risinājumi, viena HTTPS lietotne, un pakete katrā iet citu ceļu. Portu pāradresēšana maina, kur pakete tiek piegādāta, un pārējo atstāj neskartu. VPN vispirms nes šo paketi citā paketē, tāpēc lietotnes klausītājs redz citu avotu un mazāku maksimālo lietderīgo kravu. Šifrēšana, par ko cilvēki strīdas, ir abos gadījumos, jo lietotne joprojām ir HTTPS; atšķiras tas, kas var atvērt savienojumu un ko var novērot starpniektīkls. Šī atšķirība atrisina lielāko daļu praktisko jautājumu.

DNAT noteikums pārraksta galamērķi un tur apstājas

Linux vārtejā pakalpojuma publicēšana nozīmē noteikumu nat tabulas PREROUTING ķēdē vai ekvivalentu nftables. Noteikums atbilst publiskajai adresei un portam, pēc tam pārraksta galamērķi uz lietotnes privāto adresi. Avota adrese, avota ports un lietderīgā krava paliek neskartas, un conntrack ieraksta kartējumu, lai atbildes izejot tiktu pārrakstītas atpakaļ. Uzvedība ir tradicionālais adrešu tulkošanas modelis, kas aprakstīts 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

Lietotnes klausītājs nekad neuzzina, ka savienojums ienāca caur tulkošanu. Tas redz īsto klienta avota adresi, kas noder piekļuves žurnālos un ātruma ierobežojumos, un atbild uz privāto adresi, jo conntrack apgriež kartējumu. Nekas šajā ceļā neatšifrē un no jauna nešifrē: TLS joprojām darbojas starp klientu un pašas lietotnes sertifikātu.

Noteikums nosaka arī kļūmju režīmus, ar kuriem saskarsities vēlāk. Ja vārteja pārsūta, bet lietotnes resursdatoram nav atgriešanās ceļa pie klienta, atbildes iziet ar nepareizu avotu un rokas paspiešana apstājas. Ja otrs noteikums atbilst pirmais, kārtība nosaka rezultātu, un iptables -t nat -L -n -v parāda skaitītājus, kas pierāda, kurš noteikums paņēma paketi.

Tunelis iesaiņo paketi, pirms klausītājs to redz

VPN lietotni nemaz nepublisko. Klients veido ārējo paketi, kas adresēta vārtejas publiskajai adresei, iekšpusē šifrē iekšējo paketi, un vārteja atšifrē un maršrutē iekšējo paketi uz privāto galamērķi. Ar WireGuard ārējais transports ir UDP, parasti augstā portā; ar OpenVPN pa TCP 443 ārējā pakete izskatās kā TLS visam, kas vēro ceļu.

Tuneļa iekšpusē iekšējā pakete saglabā privātās adreses: klienta tuneļa adresi, teiksim 10.8.0.6, un lietotni 10.20.30.40. Tāpēc klausītājs redz avotu no tuneļa baseina, un katrs klients dala šo vārteju kā nākamo lēcienu. Piekļuves žurnāli aiz VPN bieži rāda vārteju, nevis lietotāju tieši šī iemesla dēļ, ja vien vārteja nesaglabā sākotnējo avotu.

Iesaiņošana maksā virsraksta vietu, un tā ir vienīgā mehānisma līmeņa atšķirība ar izmērāmu sekām. Ārējais IP virsraksts plus UDP plus paša WireGuard virsraksts apēd ceļa MTU, tāpēc lielas paketes ir jāsadala vai iekšējam TCP stekam ir jāierobežo savs MSS. Pārsūtītajā ceļā strādājoša pārsūtīšana var iesprūst tunelī, kad starpniekierīce nomet ICMP, kas būtu paziņojis par mazāku 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

Pakļautību nosaka pie ieejas, nevis šifrs

Abi risinājumi beidzas pie viena TLS klausītāja, tāpēc abi manto to pašu sertifikātu, tās pašas protokola versijas un to pašu lietotnes pieteikšanos. Mainās tas, kam atļauts sākt rokas paspiešanu. Ar publisku pāradresēšanu jebkurš resursdators, kas sasniedz 203.0.113.10:443, saņem TCP rokas paspiešanu un TLS ClientHello vēl pirms jūsu lietotnes autorizācija vispār tiek apskatīta. Ar piekļuvi tikai caur tuneli klausītājs ir sasniedzams tikai no adresēm, ko vārteja maršrutē tunelī, un svešinieka SYN mirst vārtejas politikā.

Šī atšķirība attiecas uz sasniedzamību, nevis uz konfidencialitāti. Pāradresēts HTTPS pakalpojums nav atklāts teksts, un VPN nenovērš lietotnes autentifikācijas nepieciešamību: uzņemšana tunelī atbild, vai ierīce drīkst sūtīt paketes šajā tīklā, bet failu lietotne atbild, vai lietotājs drīkst lasīt dokumentu. Šo divu sajaukšana ir veids, kā komandas nonāk pie VPN, kas dod visu LAN, un lietotnes ar vienu kopīgu paroli.

Pārbaudiet klausītāju un politiku atsevišķi, jo jebkurš no tiem var būt plašāks, nekā pieņemat:

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

Ja ss rāda, ka klausītājs ir piesaistīts 0.0.0.0, lietotne ir sasniedzama no jebkurienes, kur to atļauj maršrutēšana un ugunsmūra politika, un pāradresēšana ir tikai viens no ieejas veidiem. Piesaiste privātajai adresei vai avota diapazona ierobežošana ugunsmūrī ir atsevišķs lēmums no VPN izvēles, un tieši tas faktiski sašaurina pakļautību.

Mēriet ceļu, nevis etiķeti

Kad kāds apgalvo, ka pāradresēšana ir ātrāka, godīgs salīdzinājums visu pārējo notur nemainīgu: tas pats klients, tas pats piekļuves tīkls, tā pati datne, tā pati TLS konfigurācija, tas pats lietotnes resursdators. Palaidiet pārsūtīšanu divreiz katrā ceļā un pierakstiet kopējo laiku, kļūmju skaitu un atsaucību, nevis nesaistīta ātruma testa izvadi.

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 skaitļi atdala savienojuma izveidi no pārsūtīšanas laika, kas ir svarīgi, jo abi ceļi parasti atšķiras ar turp un atpakaļ latentumu un MTU, nevis ar šifra izmaksām. TLS darbs notiek galapunktos abos risinājumos, un tunelis pievieno iekapsulēšanu, citu maršrutu un varbūt noslogotāku vārteju. Ja tuneļa ceļš ir garāks vai tā vārteja ir noslogota, atšķirība pieder ceļam, nevis vārdam šifrēšana.

Izvēlieties ieejas politiku, kas pakalpojumam patiešām vajadzīga, pēc tam izlemiet, vai izmērītā atšķirība attaisno tās maiņu. Publiska pāradresēšana piemērota pakalpojumam atvērtajam internetam, ar avota ierobežojumiem, atjauninātu TLS un uzraudzību priekšā. Piekļuve tikai caur tuneli piemērota iekšējam rīkam, kura lietotāji jau reģistrēti, ja vārtejas maršrutēšana un lietotnes atļaujas abas ir šaurākas par visu LAN.

Pirms pasludināt risinājumu pabeigtu, apstipriniet četras lietas: ar kādu adresi klausītājs ir saistīts, kurš noteikums vai maršruts ielaiž paketi, vai atgriešanās ceļš darbojas no klienta īstās adreses un vai lielas lietderīgās kravas pārdzīvo MTU. Katrai no tām augstāk ir komanda, un nevienu neatbild vārds droši vai joslas platuma diagramma.

Saistītie raksti