Ein SSH-lota, eitt vefforrit og ein nafsuppfletting geta deilt einni VPN-tengingu án þess að slást um port. Biðlarinn byggir eina dulkóðaða straum til gáttarinnar og hvert forritssamtal ferðast inni í henni. Að utan sjást aðeins eigin flutningur og port göngunnar. Að innan heldur hver þjónusta sínu eigin porti og þarf enn sína eigin heimild.

Hvað ytri straumurinn ber og hvað hann felur

Biðlarinn vefur hvert pakka í flutning göngunnar áður en það yfirgefur vélina. Sá ytri straumur hefur eitt áfangaport, fastsett þegar VPN-ið var stillt. Inni í umbúðunum heldur hvert upprunalegt pakki vistfangi og porti þeirrar þjónustu sem það miðar á. Gáttin fjarlægir umbúðirnar og beinir eftir innri hausnum, svo áfangastaðurinn sér venjulegan biðlara koma úr netinu.

Upptaka á WAN-viðmótinu sýnir því eitt samtal, ekki þrjú. Innri portin birtast aðeins eftir afkóðun. Þess vegna getur ein eldveggsopna borið SSH, HTTPS og DNS á sama tíma.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

TUN/TAP-skjölin fjalla um afhendinguna þar sem beint TUN-tæki sendir IP-pakka milli kjarnans og ferlis í notendarými. Þessi afhending er það sem gerir innri hausinn sýnilegan fyrir beiningar- og eldveggskóða gáttarinnar. Hún útskýrir líka hvers vegna ytra portið segir ekkert um hvaða þjónustur eru leyfðar.

NAT-framsendingin tilheyrir hlustandanum, ekki forritunum

Sjálfhýst gátt bak við IPv4-NAT þarf eina innkomna þýðingu: opinbert vistfang og port eru varpuð á VPN-hlustandann. Engin regla er nauðsynleg fyrir SSH, HTTPS eða DNS bara af því að notendur göngunnar ná til þeirra. Að birta þessi port myndi afhjúpa þjónustur sem gangan verndar þegar. Framsendingarreglan lýsir aðgengi hlustandans, ekki heimild fyrir neinu inni.

Hið gagnstæða gildir líka. Að opna port göngunnar afhjúpar ekkert annað, svo þjónusta sem aðeins er aðgengileg í gegnum gönguna heldur opinberu yfirborði sínu lokuðu. Þessi aðgreining er venjulega einmitt ástæðan til að halda þjónustunni einkalegri.

Innri stefnan er þar sem aðgangur er í raun ákveðinn

Dulkóðun verndar leiðina; hún heimilar ekki áfangastað. Leiðir biðlarans velja hvaða forskeyti fara inn í gönguna, framsendingarstefna gáttarinnar ákveður hvort pakkar megi yfirgefa hana, og eldveggur áfangastaðarins ásamt innskráningu ákveður hvort þjónustan svari. DNS er skýrasta tilfellið: að bera fyrirspurnir fær ekki leysir til að samþykkja þær úr biðlarasafninu þínu. Hvert lag getur sjálfstætt sagt nei.

Prófaðu hverja þjónustu fyrir sig í gegnum gönguna. Árangursrík uppfletting segir ekkert um vefportið og árangursrík vefbeiðni segir ekkert um SSH.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

Þegar gangan er uppi og allt bregst, lestu fyrst leiðatöflu biðlarans. Þegar ein þjónusta bregst meðan hinar virka, er bilunin á þeim áfangastað. Þessar tvær athuganir benda á ólíka eigendur, og að blanda þeim saman eyðir tíma.

WireGuard dregur sömu línuna

WireGuard nefnir ytri hlustanda sinn ListenPort, og innra forrit notar enn hvaða þjónustuport sem það þarf. AllowedIPs er safn beindra forskeyta, ekki listi yfir leyfð þjónustuport. Að lesa það sem portheimildalista framleiðir reglur sem passa ekki við það sem gangan gerir. Nafngiftin er önnur; lagskiptingin ekki.

Leyfðu þjónustuna í staðbundinni inntaksstefnu þegar hún keyrir á endapunktinum sjálfum, eða í framsendingarstefnu þegar hún er bak við þann endapunkt. Aðgreiningin ákveður hvaða reglusafn sér pakkann.

Almenna formið er einn ytri flutningur með mörgum innri samtölum. Vörur sem þurfa nokkrar ytri skiptingar eða annað IP-samskiptalag minna á að mynstrið með einu opinberu porti lýsir þessari hönnun en ekki hverju VPN-i.

Tengdir greinar