Kuidas NAT-i taga olev OpenVPN klient saab interneti väljapääsuks

Kolm Linuxi hosti, üks lahendus: avalikult kättesaadav OpenVPN-i keskjaam, tarbijasülearvuti ja väljapääsumasin tavalise koduruuteri taga, mis ei edasta midagi sissepoole. Väljapääs helistab keskjaama ise. Seejärel siseneb tarbija internetiliiklus sülearvutis tunnelisse ja väljub väljapääsu enda ülesvoolu kaudu. Kõik üllatav selles lahenduses tuleneb ühest detailist: ühenduse algatas väljapääs, seega tee sissepoole on juba olemas ja selle loomiseks pole porti edastamist vaja.

Järgnev jälgib paketi teekonda, mitte seadistuse järjekorda, sest seadistus on mõttekas alles siis, kui tead, milline komponent millise otsuse teeb. Iga kiht teeb täpselt ühe otsuse ja vead kuhjuvad sinna, kus kahte kihti peetakse üheks.

Kaks transpordiseanssi, üks sisemine tee

Iga host hoiab oma välist ühendust keskjaamaga ja kumbki neist ei tea teisest. Tarbija liiklus internetti on eraldi sisemine voog, mida kantakse tarbija tunnelis ja seejärel emiteeritakse uuesti väljapääsu tunnelist. Just seda sisemist voogu peab keskjaam marsruudima ja seda peab väljapääs edastama.

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

Kuna mõlemad välised ühendused on kliendi poolelt väljuvad, ei näe väljapääsu ruuter kunagi sissetulevat SYN-i ega vaja kunagi sihtkoha NAT-i reeglit. See peab ainult loodud transporti elus hoidma, mida ta teeb juba iga pikaajalise ühenduse puhul. Midagi avalikus internetis ei pea esmalt väljapääsuni jõudma, seepärast pole dünaamiline aadress sellel ülesvoolu lingil probleem. Ruuter peab siiski väljuvat seanssi lubama, kuid see on sama luba, mida brauser juba kasutab.

Mida iroute tegelikult serveris paigaldab

Keskjaam on ainus seade, mis otsustab, millisele partnerile milline sihtkoht kuulub, ja teeb selle otsuse oma kasutajaruumi marsruutimistabelis, mitte kerneli omas. Väljapääsu client-config-dir kirje nimega exit-node võib seal vaike-eesliite nõuda:

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

See rida ütleb serveriprotsessile: "sisemised paketid mis tahes sihtkohaga kuuluvad sellele kliendile". See ei lisa keskjaama operatsioonisüsteemi vaikemarsruuti ega tee keskjaamast interneti lüüsi. OpenVPN 2.6 viide hoiab kliendipõhise sisemise marsruutimise ja kerneli marsruutimise eraldi mehhanismidena ning just see eraldatus on põhjus, miks lahendus töötab keskjaama vaikemarsruuti puutumata.

Tarbija vajab peegelpildis juhist, mis toimetatakse push-ina, et tema enda liiklus läheks tunnelisse, mitte välja kohaliku lüüsi kaudu. Alumise võrgu topoloogia korral on bassein ühendatud marsruut väljapääsu tun-seadmel, seega tagasisuund ei vaja täiendavat push-i; mida väljapääs ei tohi saada, on allpool olev ümbersuunamine, mis saadaks tema enda ülesvoolu liikluse tagasi tunnelisse, mida ta kasutada püüab. Saada see ainult tarbijale ja loe rakendatud marsruudid kliendil, selle asemel et uskuda, et CCD-fail valiti.

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

Edastamise teeb väljapääsu kernel

Väljapääsu sees saabub tarbija pakett tun-liidesele, adresseeritud mõnele internetihostile. Kernel uurib oma marsruutimistabelit, leiab parima vasteena tegeliku ülesvoolu lingi ja rakendab seejärel kaks sõltumatut poliitikat: kas seda paketti tohib üldse edastada ja kas see tohib sellest liidesest selle lähteaadressiga lahkuda. Edastamine on sysctl ja paljudes distributsioonides on see vaikimisi väljas.

Seega vajab väljapääs püsivalt sisse lülitatud IPv4 edastamist, edastusreeglit, mis lubab tarbija tunneli lähted ülesvoolu lingi poole, ja vastusetee tagasi läbi tun-i. Edastamise sisselülitamine kogu hosti jaoks muudab ka kõige muu käitumist, mis selle kaudu marsruudib, seepärast peaks reegel nimetama lähted ja liidesed, mitte kõike vastu võtma.

Tagasitee ostab lähte tõlkimine

Internetihostil pole marsruuti aadressile 10.90.0.x, seega vastused jäetaks kõrvale enne, kui need väljapääsuni jõuaksid. Lähte ümberkirjutamine paketi ülesvoolu lingilt lahkumisel lahendab selle ja ühenduste jälgimine pöörab ümberkirjutuse tagasiteel tagasi.

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

Ülalolev reegel on ühe ülesvoolu liidese lähtepunkt, mitte tulemüüri poliitika. Kitsenda lähted tegelikult volitatud määramisteni ja hoia väljapääsu enda sisendpoliitika eraldi, et tunneli liikluse maskeerimine ei paljastaks vaikselt kohalikke teenuseid. Dünaamilise ülesvoolu aadressiga hostis säästab maskeerimine ka aadressi käsitsi jälgimisest.

Kus keskjaam saab kehtestada ja kus mitte

client-to-client ja traditsioonilise kasutajaruumi andmetee korral annab keskjaam sisemised paketid partnerite vahel üle serveriprotsessi sees. Need ei läbi kunagi keskjaama kerneli FORWARD-ahelat, seega kerneli reegel seal ei saa partneritevahelist läbiliikumist piirata, ükskõik kui hoolikalt see kirjutatud on. Kehtestamine peab elama serveri enda poliitikas: kes tohib ühenduda, millise CCD-faili ta saab ja kas väljapääsu vaikeomand üldse antakse.

Seepärast on vaikimisi iroute lai usaldusotsus. Väljapääs peab seaduslikult vastu võtma tagasiliiklust suvalistelt internetiaadressidelt ja see peab olema masin, mida te kontrollite, paigute ja jälgite. Sama omandi andmine partnerile, kellele te ruuterit ei usaldaks on viga, millele see lahendus kutsub.

Liikmelisus on tegelik kontroll. Iga klient, kes suudab oma marsruute seadistada, võib proovida väljapääsu kasutada, seega selle piiramine, kes tohib ühenduda või keda väljapääs teenindab, on lahenduse osa, mitte järelmõte.

Turvaliselt ebaõnnestuda, kui väljapääs kaob

Lülita väljapääs välja ja sisemine vaikeomand kaob koos selle seansiga. Mis ei tohi juhtuda, on see, et keskjaamast saab vaikselt asendusväljapääs: mingit vaikemarsruuti VPN-i basseinist keskjaama ülesvoolu lingile ja mingit laia maskeerimisreeglit keskjaamas, mis sama liiklust hea meelega edastaks. Testi seda tõrget meelega ja seejärel testi taastumist värske vooga, mitte lehega, mis oli juba avatud.

# 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

Kui tarbija liiklus jõuab pärast väljapääsu kadumist ikka internetti, kannab seda miski muu ja kavatsetud piiri ei ole olemas. Käsitle ka DNS-i ja IPv6-t eraldi otsustena: IPv4 marsruut pluss maskeerimine ei ütle AAAA liikluse kohta midagi ja keskjaama lükatud resolver vastab sealt, kust päring tegelikult väljub.