Kako odjemalec OpenVPN za NAT postane internetni izhod

Trije gostitelji Linux, ena zasnova: javno dosegljivo zvezdišče OpenVPN, uporabniški prenosnik in izhodni stroj za običajnim domačim usmerjevalnikom, ki ničesar ne posreduje navznoter. Izhod sam pokliče zvezdišče. Nato internetni promet uporabnika vstopi v tunel na prenosniku in izstopi po lastni vzponski povezavi izhoda. Vse presenetljivo pri tej postavitvi izhaja iz ene podrobnosti: povezavo je začel izhod, zato pot navznoter že obstaja in za njeno ustvarjanje ni potrebno posredovanje vrat.

Naslednje sledi poti paketa in ne vrstnemu redu konfiguracije, ker ima konfiguracija smisel šele, ko veste, katera komponenta odloča o čem. Vsak sloj odloča o natanko eni stvari, napake pa se kopičijo tam, kjer dveh slojev ne ločimo.

Dve transportni seji, ena notranja pot

Vsak gostitelj vzdržuje svojo zunanjo povezavo do zvezdišča in nobena od teh povezav ne ve za drugo. Promet uporabnika v internet je ločen notranji tok, ki se slučajno prenaša znotraj uporabnikovega tunela in nato znova odda iz tunela izhoda. Prav ta notranji tok mora zvezdišče usmerjati in prav tega mora izhod posredovati.

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

Ker obe zunanji povezavi odhajata s strani odjemalca, usmerjevalnik izhoda nikoli ne vidi dohodnega SYN in nikoli ne potrebuje pravila NAT za cilj. Vzdrževati mora le vzpostavljeni transport, kar že počne za vsako dolgotrajno povezavo. Nič na javnem internetu se ne mora najprej prebiti do izhoda, zato dinamični naslov na tej vzponski povezavi ni problem. Usmerjevalnik mora še vedno dovoliti odhodno sejo, a to je isto dovoljenje, ki ga brskalnik že uporablja.

Kaj iroute dejansko namesti znotraj strežnika

Zvezdišče je edina naprava, ki odloča, kateri partner ima katero ciljno točko, in to odločitev sprejme v svoji usmerjevalni tabeli uporabniškega prostora, ne v jedrni. Vnos client-config-dir za izhod z imenom exit-node lahko tam zahteva privzeto predpono:

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

Ta vrstica pove strežniškemu procesu "notranji paketi s katero koli ciljno točko pripadajo temu odjemalcu". Ne doda privzete poti v operacijski sistem zvezdišča in ne naredi zvezdišča internetnega prehoda. Referenca OpenVPN 2.6 ohranja notranje usmerjanje, značilno za odjemalca, in usmerjanje jedra kot ločena mehanizma, in prav ta ločitev je razlog, da zasnova deluje brez poseganja v privzeto pot zvezdišča.

Uporabnik potrebuje zrcalno navodilo, dostavljeno kot push, da njegov promet vstopi v tunel, namesto da bi odšel skozi lokalni prehod. Pri topologiji podomrežja je bazen povezana pot na napravi tun izhoda, zato povratna smer ne potrebuje dodatnega pusha; česar izhod ne sme prejeti, je preusmeritev spodaj, ki bi njegov lastni vzponski promet poslala nazaj v tunel, ki ga poskuša uporabiti. Pošiljajte jo samo uporabniku in berite uporabljene poti na odjemalcu, namesto da bi zaupali, da je bila izbrana datoteka CCD.

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

Posredovanje opravi jedro izhoda

Znotraj izhoda paket od uporabnika prispe na vmesnik tun, naslovljen na nek internetni gostitelj. Jedro pogleda svojo usmerjevalno tabelo, najde dejansko vzponsko povezavo kot najboljše ujemanje in nato uporabi dve neodvisni politiki: ali se ta paket sploh sme posredovati in ali sme zapustiti ta vmesnik s tem izvornim naslovom. Posredovanje je sysctl in je v mnogih distribucijah privzeto izklopljeno.

Izhod torej potrebuje trajno vklopljeno posredovanje IPv4, pravilo, ki spusti izvore uporabnikovega tunela proti vzponski povezavi, in pot odgovora nazaj skozi tun. Vklop posredovanja za ves gostitelj spremeni tudi vedenje vsega drugega, kar se usmerja skozenj, zato naj pravilo imenuje izvore in vmesnike, namesto da bi sprejelo vse.

Povratno pot kupi pretvorba izvora

Internetni gostitelj nima poti do naslova 10.90.0.x, zato bi bili odgovori zavrženi, še preden bi dosegli izhod. Prepis izvora, ko paket zapusti vzponsko povezavo, to reši, sledenje povezavam pa prepis na poti nazaj obrne.

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

Pravilo zgoraj je izhodišče za en vzponski vmesnik, ne požarna politika. Zožite izvor na dodelitve, ki ste jih resnično odobrili, in držite lastno vhodno politiko izhoda ločeno, da maskiranje tunelskega prometa ne razkrije tiho lokalnih storitev. Na gostitelju z dinamičnim vzponskim naslovom vas maskiranje reši tudi ročnega sledenja naslova.

Kje lahko zvezdišče uveljavlja pravila in kje ne

S client-to-client in klasično podatkovno potjo v uporabniškem prostoru zvezdišče predaja notranje pakete med partnerji znotraj strežniškega procesa. Nikoli ne prečkajo verige FORWARD jedra zvezdišča, zato pravilo v jedru tam ne more omejiti prehoda med partnerji, ne glede na to, kako skrbno je napisano. Uveljavljanje mora živeti v lastni politiki strežnika: kdo se sme povezati, katero datoteko CCD dobi in ali se privzeta lastnina izhoda sploh podeli.

Zato je privzeti iroute široka odločitev o zaupanju. Izhod mora zakonito sprejemati povratni promet s poljubnih internetnih naslovov in mora biti stroj, ki ga nadzorujete, posodabljate in spremljate. Podeliti isto lastnino partnerju, ki mu ne bi zaupali usmerjevalnika je napaka, h kateri vabi ta zasnova.

Članstvo je resnični nadzor. Vsak odjemalec, ki zna nastaviti svoje poti, lahko poskusi uporabiti izhod, zato je omejevanje, kdo se sme povezati ali katerim partnerjem bo izhod služil, del zasnove in ne poznejša misel.

Varno odpovedati, ko izhod izgine

Izklopite izhod in notranja privzeta lastnina izgine skupaj z njegovo sejo. Kar se ne sme zgoditi, je da zvezdišče tiho postane nadomestni izhod: nobene privzete poti iz bazena VPN v vzponsko povezavo zvezdišča in nobenega širokega pravila maskiranja na zvezdišču, ki bi z veseljem posredovalo isti promet. To odpoved preizkusite namerno, nato pa obnovitev preizkusite s svežim tokom, ne s stranjo, ki je bila že odprta.

# 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

Če promet uporabnika tudi po izginotju izhoda doseže internet, ga nosi nekaj drugega in predvidena meja ne obstaja. Tudi DNS in IPv6 obravnavajte kot ločeni odločitvi: pot IPv4 z maskiranjem ne pove ničesar o prometu AAAA, razreševalnik, ki ga potisne zvezdišče, pa bo odgovoril od tam, kjer poizvedba v resnici odide.