Pordoadresado kontraŭ VPN-aliro: kien la pako vere iras

Pordoadresado reverkas la celon kaj haltas tie; VPN unue envolvas la pakon. Vidu, kiun tavolon ĉiu ŝanĝas kaj kion tio signifas por HTTPS.

Du dezajnoj, unu HTTPS-aplikaĵo, kaj la pako prenas malsaman vojon en ĉiu. Pordoadresado ŝanĝas, kie la pako estas liverata, kaj lasas la reston netuŝita. VPN portas tiun pakon unue ene de alia pako, do la aŭskultanto de la aplikaĵo vidas alian fonton kaj pli malgrandan maksimuman ŝarĝon. La ĉifrado, pri kiu homoj disputas, ĉeestas en ambaŭ kazoj, ĉar la aplikaĵo ankoraŭ estas HTTPS; kio malsamas, estas kiu povas malfermi konekton kaj kion la reto intere povas observi. Tiu distingo solvas la plej multajn praktikajn demandojn.

La regulo DNAT reverkas la celon kaj haltas tie

Sur Linuksa pordego, publikigi servon signifas regulon en la PREROUTING-ĉeno de la nat-tabelo, aŭ la ekvivalenton en nftables. La regulo kongruas la publikan adreson kaj pordon, poste reverkas la celon al la privata adreso de la aplikaĵo. Fontadreso, fontpordo kaj ŝarĝo restas netuŝitaj, kaj conntrack registras la mapadon por ke respondoj estu reverkataj survoje eksteren. La konduto estas la tradicia adres-traduka modelo priskribita en 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

La aŭskultanto de la aplikaĵo neniam ekscias, ke la konekto alvenis per traduko. Ĝi vidas la veran fontadreson de la kliento, kio utilas por alirprotokoloj kaj rapidaj limigoj, kaj ĝi respondas al la privata adreso ĉar conntrack inversigas la mapadon. Nenio sur tiu vojo malĉifras aŭ reĉifras: TLS daŭre funkcias inter la kliento kaj la propra atestilo de la aplikaĵo.

La regulo ankaŭ fiksas la malsukcesajn reĝimojn, kiujn vi renkontos poste. Se la pordego plusendas sed la gastiganto de la aplikaĵo ne havas revenan vojon al la kliento, respondoj eliras kun malĝusta fonto kaj la manpremo haltas. Se dua regulo kongruas unue, la ordo decidas la rezulton, kaj iptables -t nat -L -n -v montras la nombrilojn, kiuj pruvas, kiu regulo prenis la pakon.

La tunelo envolvas la pakon antaŭ ol la aŭskultanto vidas ĝin

VPN tute ne publikigas la aplikaĵon. La kliento konstruas eksteran pakon adresitan al la publika adreso de la pordego, ĉifras la internan pakon en ĝi, kaj la pordego malĉifras kaj enkursigas la internan pakon al la privata celo. Ĉe WireGuard la ekstera transporto estas UDP, kutime sur alta pordo; ĉe OpenVPN super TCP 443 la ekstera pako aspektas kiel TLS al io ajn, kio observas la vojon.

Ene de la tunelo la interna pako konservas privatajn adresojn: la tuneladreso de la kliento, ekzemple 10.8.0.6, kaj la aplikaĵo ĉe 10.20.30.40. La aŭskultanto do vidas fonton el la tunela baseno, kaj ĉiu kliento dividas tiun pordegon kiel sian sekvan salteton. Alirprotokoloj malantaŭ VPN ofte montras la pordegon anstataŭ la uzanton ĝuste pro tiu kialo, se la pordego ne konservas la originan fonton.

La envolvado kostas kaplinian spacon, kaj tio estas la sola diferenco je mekanisma nivelo kun mezurebla sekvo. Ekstera IP-kapo plus UDP plus la propra kapo de WireGuard manĝas la MTU-on de la vojo, do grandaj pakoj devas esti fragmentataj aŭ la interna TCP-stako devas limigi sian MSS. Transigo, kiu funkcias sur la plusendita vojo, povas halti sur la tunelo, kiam meza aparato faligas la ICMP-on, kiu signalus la pli malgrandan MTU-on.

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

Elmetiĝo decidiĝas ĉe la enirejo, ne per la ĉifrilo

Ambaŭ dezajnoj finiĝas ĉe la sama TLS-aŭskultanto, do ambaŭ heredas la saman atestilon, la samajn protokolversiojn kaj la saman aplikaĵan ensaluton. Kio ŝanĝiĝas, estas kiu rajtas komenci manpremon. Ĉe publika plusendo, ĉiu gastiganto, kiu atingas 203.0.113.10:443, ricevas TCP-manpremon kaj TLS ClientHello antaŭ ol via aplikaĵa rajtigo eĉ konsultiĝas. Ĉe aliro nur tra tunelo, la aŭskultanto estas atingebla nur de adresoj, kiujn la pordego enkursigas en la tunelon, kaj la SYN de fremdulo mortas ĉe la pordega politiko.

Tiu diferenco rilatas al atingeblo, ne al konfideco. Plusendita HTTPS-servo ne estas klarteksto, kaj VPN ne forigas la bezonon de aplikaĵa aŭtentikigo: tunela akcepto respondas, ĉu aparato rajtas sendi pakojn en ĉi tiun reton, dum la dosiera aplikaĵo respondas, ĉu uzanto rajtas legi dokumenton. Konfuzi la du estas kiel teamoj finiĝas kun VPN, kiu donas la tutan lokan reton, kaj aplikaĵo kun unu komuna pasvorto.

Ekzamenu la aŭskultanton kaj la politikon aparte, ĉar ĉiu el ili povas esti pli larĝa ol vi supozas:

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

Se ss montras, ke la aŭskultanto estas ligita al 0.0.0.0, la aplikaĵo estas atingebla de kie ajn enkursigo kaj fajroŝirma politiko permesas, kaj la plusendo estas nur unu el la enirejoj. Ligi al la privata adreso aŭ limigi la fontan intervalon en la fajroŝirmilo estas aparta decido de la elekto de VPN, kaj ĝi estas la decido, kiu vere malvastigas elmetiĝon.

Mezuru la vojon, ne la etikedon

Kiam iu asertas, ke la plusendo estas pli rapida, la honesta komparo tenas ĉion alian konstanta: sama kliento, sama alirreto, sama dosiero, sama TLS-agordo, sama aplikaĵa gastiganto. Rulu la transigon dufoje por vojo kaj notu totalan tempon, malsukcesan nombron kaj respondecon, ne la eligon de nerilata rapidotesto.

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

Tiuj nombroj apartigas konektokreadon de transiga tempo, kio gravas ĉar la du vojoj kutime diferenciĝas je rondira latento kaj MTU, ne je ĉifra kosto. TLS-laboro okazas ĉe la finpunktoj en ambaŭ dezajnoj, kaj tunelo aldonas enkapsuligon, alian itineron kaj eble pli okupatan pordegon. Se la tunela vojo estas pli longa aŭ ĝia pordego estas ŝarĝita, la diferenco apartenas al la vojo, ne al la vorto ĉifrado.

Elektu la eniran politikon, kiun la servo vere bezonas, poste decidu, ĉu mezurita diferenco pravigas ŝanĝi ĝin. Publika plusendo taŭgas por servo celita al la malferma interreto, kun fontlimigoj, ĝisdatigita TLS kaj monitorado antaŭe. Aliro nur tra tunelo taŭgas por interna ilo, kies uzantoj jam estas registritaj, kondiĉe ke la enkursigo de la pordego kaj la permesoj de la aplikaĵo ambaŭ estas pli mallarĝaj ol la tuta loka reto.

Antaŭ ol vi nomi la dezajnon finita, konfirmu kvar aferojn: al kiu adreso la aŭskultanto estas ligita, kiu regulo aŭ itinero enlasas la pakon, ĉu la reena vojo funkcias de la vera adreso de la kliento, kaj ĉu grandaj ŝarĝoj postvivas la MTU-on. Ĉiu el tiuj havas komandon supre, kaj neniun el ili respondas la vorto sekura aŭ bendlarĝa diagramo.

Rilataj artikoloj