Hvernig OpenVPN-biðlari bak við NAT verður internetútgangur

Þrír Linux-vélar, ein hönnun: opinberlega aðgengileg OpenVPN-miðstöð, fartölva notanda og útgangsvél bak við venjulegan heimabeini sem sendir ekkert inn. Útgangurinn hringir sjálfur í miðstöðina. Svo fer internetumferð notandans inn í göngin í fartölvunni og út um eigin uppstreymistengingu útgangsins. Allt óvænt við þetta fyrirkomulag leiðir af einum smáatriði: útgangurinn hóf tenginguna, svo leiðin inn er þegar til og engin portfærsla þarf til að búa hana til.

Það sem hér fer á eftir fylgir leið pakkans frekar en röð stillinganna, því stillingarnar hafa aðeins merkingu þegar maður veit hvaða eining tekur hvaða ákvörðun. Hvert lag tekur nákvæmlega eina ákvörðun, og mistökin safnast þar sem tvö lög eru talin eitt.

Tvær flutningslotur, ein innri leið

Hver vél heldur sínum eigin ytri tengingu við miðstöðina, og hvorug þessara tenginga veit af hinni. Umferð notandans til internetsins er aðskilin innri streymi sem verður fyrir því að vera flutt inni í göngum notandans og er svo send út aftur úr göngum útgangsins. Það er þessa innri streymi sem miðstöðin þarf að beina og útgangurinn þarf að senda áfram.

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

Þar sem báðar ytri tengingarnar fara út frá biðlarahliðinni sér beinir útgangsins aldrei SYN inn og þarf aldrei NAT-reglu fyrir áfangastað. Hann þarf aðeins að halda uppsettu flutningnum lifandi, sem hann gerir nú þegar fyrir hverja langlífa tengingu. Ekkert á opna internetinu þarf að ná fyrst til útgangsins, þess vegna er kvikt netfang á þeirri uppstreymistengingu ekki vandamál. Beinirinn verður samt að leyfa útgöngulotuna, en það er sama heimild og vafri notar nú þegar.

Hvað iroute setur í raun upp inni í þjóninum

Miðstöðin er eina tækið sem ákveður hvaða jafningi á hvaða áfangastað, og tekur hún þá ákvörðun í eigin beinitöflu notendarýmis, ekki í kjarnanum. Færsla í client-config-dir fyrir útganginn að nafni exit-node getur krafist sjálfgefna forskeytisins þar:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

Sú lína segir þjónferlinu "innri pakkar með hvaða áfangastað sem er tilheyra þessum biðlara". Hún bætir ekki sjálfgefinni leið við stýrikerfi miðstöðvarinnar og gerir miðstöðina ekki að internetgátt. OpenVPN 2.6 tilvísun heldur biðlarasérstakri innri beiningu og beiningu kjarnans sem aðskildum kerfum, og sú aðskilnaður er ástæðan fyrir því að hönnunin virkar án þess að snerta sjálfgefna leið miðstöðvarinnar.

Notandinn þarf spegilmyndarskipunina, afhenta sem push, svo eigin umferð hans fari inn í göngin í stað þess að fara út um staðbundna gátt hans. Með undirnetstoppfræði er laugin tengd leið á tun-tæki útgangsins, svo bakstefnan þarf enga auka-push; það sem útgangurinn má ekki fá er endurbeiningin hér að neðan, sem myndi senda eigin uppstreymisumferð hans aftur inn í göngin sem hann er að reyna að nota. Sendu hana aðeins til notandans og lestu beittu leiðirnar á biðlaranum í stað þess að treysta því að CCD-skráin hafi verið valin.

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

Kjarni útgangsins sér um framsendinguna

Inni í útganginum berst pakki frá notandanum á tun-viðmótið, ávarpaður einhverri internetvél. Kjarninn skoðar beinitöfluna, finnur raunverulegu uppstreymistenginguna sem bestu samsvörun og beitir svo tveimur óháðum stefnum: má yfirhöfuð senda þennan pakka áfram, og má hann fara út um það viðmót með því frumheimilisfangi. Framsending er sysctl, og hún er sjálfgefið slökkt í mörgum dreifingum.

Útgangurinn þarf því varanlega virka IPv4-framsendingu, reglu sem hleypir uppstreymisheimildum ganganna í notandans inn og svarleiðina aftur um tun. Að virkja framsendingu fyrir alla vélina breytir einnig hegðun alls annars sem beinir um hana, þess vegna ætti reglan að nefna heimildirnar og viðmótin í stað þess að samþykkja allt.

Bakleiðin er keypt með þýðingu frumheimilisfangs

Internetvél hefur enga leið að 10.90.0.x-heimilisfangi, svo svörum yrði hent áður en þau næðu útganginum. Að endurskrifa frumheimilisfangið þegar pakkinn yfirgefur uppstreymistenginguna leysir það, og tengingarakning snýr endurskrifuninni við á bakleiðinni.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

Reglan hér að ofan er upphafspunktur fyrir eitt uppstreymisviðmót, ekki eldveggsstefna. Þrengdu heimildina að þeim úthlutunum sem þú hefur í raun heimilað, og haltu eigin inntaksstefnu útgangsins aðskilinni svo hylming gangnaumferðar afhjúpi ekki staðbundna þjónustu í kyrrþey. Á vél með kvikt uppstreymisheimilisfang sparar hylmingin þér líka að fylgjast með heimilisfanginu í höndunum.

Hvar miðstöðin getur framfylgt og hvar ekki

Með client-to-client og hefðbundinni gagnaleið notendarýmis afhendir miðstöðin innri pakka milli jafningja inni í þjónferlinu. Þeir fara aldrei um FORWARD-keðju kjarna miðstöðvarinnar, svo kjarnaregla þar getur ekki takmarkað ferð milli jafningja, hversu vandlega sem hún er skrifuð. Framfylgd verður að lifa í eigin stefnu þjónsins: hver má tengjast, hvaða CCD-skrá hann fær og hvort sjálfgefið eignarhald útgangsins er yfirhöfuð veitt.

Þess vegna er sjálfgefið iroute víðtæk traustsákvörðun. Útgangurinn verður löglega að taka við bakumferð frá handahófskenndum internetheimilisföngum, og hann verður að vera vél sem þú stjórnar, plástrar og fylgist með. Að veita sama eignarhald til jafnings sem þú myndir ekki fela beini er mistökið sem þessi hönnun býður upp á.

Aðild er hin raunverulega stjórn. Sérhver biðlari sem getur stillt eigin leiðir getur reynt að nota útganginn, svo að takmarka hver má tengjast, eða hvaða jafningja útgangurinn þjónar, er hluti af hönnuninni en ekki eftirhugsun.

Mistaka örugglega þegar útgangurinn hverfur

Taktu útganginn úr sambandi og innra sjálfgefna eignarhaldið hverfur með lotu hans. Það sem má ekki gerast er að miðstöðin verði í kyrrþey varamiðstöð útgangs: engin sjálfgefinn leið frá VPN-laupunni að uppstreymistengingu miðstöðvarinnar, og engin víðtæk hylmingarregla á miðstöðinni sem myndi gjarnan senda sömu umferð áfram. Prófaðu þessa mistöku viljandi og prófaðu svo endurheimt með nýju streymi en ekki síðu sem var þegar opin.

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Ef umferð notandans nær enn til internetsins eftir að útgangurinn er farinn er eitthvað annað að flytja hana og mörkin sem þú ætlaðir þér eru ekki til. Meðhöndlaðu DNS og IPv6 einnig sem aðskildar ákvarðanir: IPv4-leið auk hylmingar segir ekkert um AAAA-umferð, og leysir sem miðstöðin ýtir mun svara þaðan sem fyrirspurnin fer í raun út.