Port forwarding gegn VPN-aðgangi: hvert fer pakkinn í raun

Port forwarding endurskrifar áfangastaðinn og stoppar þar; VPN umbúðir pakkann fyrst. Sjáðu hvaða lag hvort breytir og hvað það þýðir fyrir HTTPS.

Tvær hönnunarleiðir, eitt HTTPS-forrit, og pakkinn fer mismunandi leið í hvorri. Port forwarding breytir því hvar pakkinn er afhentur og lætur restina ósnerta. VPN ber pakkann fyrst inni í öðrum pakka, svo hlustari forritsins sér aðra uppsprettu og minna hámarksnýtingarálag. Dulkóðunin sem deilt er um er til staðar í báðum tilvikum, því forritið er enn HTTPS; það sem er frábrugðið er hver getur opnað tengingu og hvað netið á milli getur fylgst með. Þessi greinarmunur leysir flestar hagnýtar spurningar.

DNAT-reglan endurskrifar áfangastaðinn og stoppar þar

Á Linux-hliði þýðir birting þjónustu regla í PREROUTING-keðju nat-töflunnar, eða samsvarandi í nftables. Reglan passar við opinbera vistfangið og portið og endurskrifar síðan áfangastaðinn á einka-vistfang forritsins. Uppsprettuvistfang, uppsprettuport og nytsemisálag eru ósnert, og conntrack skráir varpinu svo svör séu endurskrifuð út. Hegðunin er hefðbundið vistfangafærslulíkanið sem lýst er í 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

Hlustari forritsins kemst aldrei að því að tengingin kom gegnum þýðingu. Hann sér raunverulegt uppsprettuvistfang biðlarans, sem er gagnlegt fyrir aðgangsskrár og hraðatakmarkanir, og hann svarar á einka-vistfangið því conntrack snýr varpinu við. Ekkert á þeirri leið afkóðar eða dulkóðar aftur: TLS gengur enn milli biðlarans og eigin vottorðs forritsins.

Reglan ákvarðar líka bilanirnar sem þú munt rekast á síðar. Ef hliðið sendir áfram en hýsill forritsins hefur enga leið til baka til biðlarans, fara svör út með röngu uppsprettu og handabandið stöðvast. Ef önnur regla passar fyrst ræður röðin niðurstöðunni, og iptables -t nat -L -n -v sýnir teljarana sem sanna hvaða regla tók pakkann.

Göngin umbúða pakkann áður en hlustarinn sér hann

VPN birtir forritið alls ekki. Biðlarinn byggir ytri pakka sem er stilaður á opinbert vistfang hliðsins, dulkóðar innri pakkann inni í honum, og hliðið afkóðar og beinir innri pakkanum á einkaaðfangastaðinn. Með WireGuard er ytri flutningurinn UDP, venjulega á háu porti; með OpenVPN yfir TCP 443 lítur ytri pakkinn út eins og TLS fyrir allt sem fylgist með leiðinni.

Inni í göngunum heldur innri pakkinn einkavistföngum: gönguvistfang biðlarans, segjum 10.8.0.6, og forritið á 10.20.30.40. Hlustarinn sér því uppsprettu úr göngulóninu, og hver biðlari deilir því hliði sem næsta hoppi. Aðgangsskrár bak við VPN sýna oft hliðið í stað notandans einmitt af þessari ástæðu, nema hliðið varðveiti upprunalegu uppsprettuna.

Umbúðirnar kosta hauspláss og það er eini munurinn á vélbúnaðarstigi sem hefur mælanlegar afleiðingar. Ytri IP-haus ásamt UDP ásamt eigin haus WireGuard étur af MTU leiðarinnar, svo stóra pakka verður að sundra eða innri TCP-stakkinn verður að takmarka MSS sinn. Flutningur sem virkar á framsendu leiðinni getur stöðvast á göngunum þegar millitæki hendir ICMP-inu sem hefði tilkynnt minna 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

Útsetning ákvarðast við innganginn, ekki af dulrituninni

Báðar hönnunarleiðir enda á sama TLS-hlustara, svo báðar erfa sama vottorð, sömu prótókólútgáfur og sama innskráningu forritsins. Það sem breytist er hver má hefja handaband. Með opinberri framsendingu fær hver hýsill sem nær í 203.0.113.10:443 TCP-handaband og TLS ClientHello áður en heimild forritsins er jafnvel skoðuð. Með aðgangi eingöngu um göngin er hlustarinn aðeins aðgengilegur frá vistföngum sem hliðið beinir inn í göngin, og SYN ókunnugs manns deyr á stefnu hliðsins.

Sá munur snýst um aðgengi, ekki um trúnað. Framsend HTTPS-þjónusta er ekki látlaus texti, og VPN fjarlægir ekki þörfina fyrir sannvottun forritsins: innganga í göngin svarar því hvort tæki megi senda pakka inn í þetta net, en skráaforritið svarar því hvort notandi megi lesa skjal. Að rugla þessu tvennu er hvernig teymi enda með VPN sem gefur allt LAN-ið og forrit með einu sameiginlegu lykilorði.

Skoðaðu hlustarann og stefnuna sitt í hvoru lagi, því hvorugt getur verið víðtækara en þú gerir ráð fyrir:

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

Ef ss sýnir að hlustarinn er bundinn við 0.0.0.0, er forritið aðgengilegt hvaðan sem beining og eldveggsstefna leyfa, og framsendingin er aðeins ein leið inn. Að binda við einkavistfangið, eða takmarka uppsprettubilið í eldveggnum, er ákvörðun aðskilin frá því að velja VPN, og hún er ákvörðunin sem minnkar útsetninguna í raun.

Mældu leiðina, ekki merkið

Þegar einhver fullyrðir að framsendingin sé hraðari heldur heiðarlegur samanburður öllu öðru stöðugu: sami biðlari, sama aðgangsnet, sama skrá, sama TLS-stilling, sami hýsill forrits. Keyrðu flutninginn tvisvar á hverri leið og skráðu heildartíma, fjölda bila og svörun, ekki úttak ótengdrar hraðaprófunar.

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

Þessar tölur aðskilja tengingaruppsetningu frá flutningstíma, sem skiptir máli því leiðirnar tvær eru yfirleitt frábrugðnar í hringferðartöf og MTU frekar en í kostnaði dulritunar. TLS-vinna fer fram á endapunktunum í báðum hönnunum, og göngin bæta við umbúðum, annarri leið og hugsanlega annasamara hliði. Ef gönguleiðin er lengri eða hliðið er hlaðið tilheyrir munurinn leiðinni en ekki orðinu dulkóðun.

Veldu þá inngangsstefnu sem þjónustan þarf í raun, og ákvarðaðu síðan hvort mældur munur réttlæti að breyta henni. Opinber framsending hentar þjónustu sem er ætluð opnu internetinu, með uppsprettutakmörkunum, uppfærðu TLS og eftirliti fyrir framan. Aðgangur eingöngu um göngin hentar innra tóli sem notendur eru þegar skráðir inn í, að því tilskildu að beining hliðsins og heimildir forritsins séu bæði þrengri en allt LAN-ið.

Áður en þú lýsir hönnuninni lokinni skaltu staðfesta fjóra hluti: við hvaða vistfang hlustarinn er bundinn, hvaða regla eða leið hleypir pakkanum inn, virkar bakleiðin frá raunverulegu vistfangi biðlarans, og standast stóru álögin MTU-ið. Hvert þeirra hefur skipun að ofan, og ekkert þeirra er svarað með orðinu öruggt eða bandvíddargrafi.

Tengdir greinar