Hogyan lesz egy NAT mögötti OpenVPN-kliens az internet kijárata

Három Linux-gazdagép, egy terv: nyilvánosan elérhető OpenVPN-hub, egy fogyasztói laptop és egy kijárat-gép egy közönséges otthoni útválasztó mögött, amely semmit nem továbbít befelé. A kijárat maga tárcsázza a hubot. A fogyasztó internettforgalma ezután a laptopnál belép a csatornába, és a kijárat saját felfelé irányuló linkjén távozik. Minden meglepő ebben az elrendezésben egyetlen részletből következik: a kijárat indította a kapcsolatot, tehát a befelé vezető út már létezik, és nem kell porttovábbítás a létrehozásához.

A következők a csomag útját követik, nem a konfiguráció sorrendjét, mert a konfigurációnak csak akkor van értelme, ha tudja, melyik komponens melyik döntést hozza. Minden réteg pontosan egy döntést hoz, és a hibák ott halmozódnak, ahol két réteget egynek tekintenek.

Két szállítási munkamenet, egy belső út

Minden gazdagép a saját külső kapcsolatát tartja a hubhoz, és ezek egyike sem tud a másikról. A fogyasztó internettre irányuló forgalma külön belső folyam, amely véletlenül a fogyasztó csatornájában utazik, majd a kijárat csatornájából újra kibocsátódik. Ezt a belső folyamot kell a hubnak irányítania, és ezt kell a kijáratnak továbbítania.

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

Mivel mindkét külső kapcsolat a kliens oldaláról kifelé indul, a kijárat útválasztója soha nem lát bejövő SYN-t, és soha nem kell cél-NAT-szabály. Csak a létrehozott szállítást kell életben tartania, amit már minden hosszú életű kapcsolatnál megtesz. A nyilvános interneten semminek nem kell előbb elérnie a kijáratot, ezért a dinamikus cím azon a felfelé linken nem probléma. Az útválasztónak továbbra is engedélyeznie kell a kimenő munkamenetet, de ez ugyanaz az engedély, amelyet a böngésző már használ.

Mit telepít valójában az iroute a szerveren belül

A hub az egyetlen eszköz, amely eldönti, melyik partner melyik célt birtokolja, és ezt a saját felhasználói térbeli útválasztási táblázatában hozza meg, nem a kernelében. A kijárathoz tartozó exit-node nevű client-config-dir bejegyzés ott igényelheti az alapértelmezett előtagot:

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

Ez a sor azt mondja a szerverfolyamatnak: "a belső csomagok bármilyen céllal ehhez a klienshez tartoznak". Nem ad hozzá alapértelmezett útvonalat a hub operációs rendszeréhez, és nem teszi a hubot internetátjáróvá. OpenVPN 2.6 referencia a kliensspecifikus belső útválasztást és a kernel útválasztását külön mechanizmusként tartja, és ez a szétválasztás az oka, hogy a terv a hub alapértelmezett útvonalának érintése nélkül működik.

A fogyasztónak a tükörutasítást kell megkapnia push formájában, hogy a saját forgalma a csatornába lépjen a helyi átjárón való kilépés helyett. Alhálózati topológiánál a pool összekapcsolt útvonal a kijárat tun-eszközén, ezért a visszirány nem igényel további pusht; amit a kijárat nem kaphat meg, az a lentebbi átirányítás, amely a saját felfelé forgalmát visszaküldené abba a csatornába, amelyet használni próbál. Csak a fogyasztónak küldje, és a klienesen olvassa ki az alkalmazott útvonalakat, ahelyett hogy bízna a CCD-fájl kiválasztásában.

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

A kijárat kerrnelje végzi a továbbítást

A kijáraton belül a fogyasztó csomagja a tun-interfészen érkezik valamelyik internethoszt címére. A kernel megnézi az útválasztási táblázatát, megtalálja a valódi felfelé linket legjobb egyezésként, majd két független szabályt alkalmaz: egyáltalán továbbítható-e ez a csomag, és elhagyhatja-e azt az interfészt azzal a forráscímmel. A továbbítás sysctl, és sok disztribúción alapértelmezés szerint ki van kapcsolva.

Tehát a kijáratnak tartósan bekapcsolt IPv4-továbbításra, a fogyasztó csatornaforrásait a felfelé link felé beengedő szabályra és a tunon át visszavezető válaszútra van szüksége. A továbbítás bekapcsolása az egész gazdagépre megváltoztatja minden más viselkedését is, ami rajta keresztül irányul, ezért a szabálynak a forrásokat és interfészeket kell megneveznie, nem pedig mindent elfogadnia.

A visszautat a forrásfordítás vásárolja meg

Egy internethosztnak nincs útvonala egy 10.90.0.x címhez, ezért a válaszok még a kijárat elérése előtt eldobódnának. A forrás átírása, miközben a csomag elhagyja a felfelé linket, megoldja ezt, a kapcsolatkövetés pedig visszafelé megfordítja az átírást.

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

A fenti szabály egyetlen felfelé interfész kiindulópontja, nem tűzfalpolitika. Szűkítse a forrást a ténylegesen engedélyezett kiosztásokra, és tartsa külön a kijárat saját bemeneti politikáját, hogy a csatornaforgalom maszkolása ne tegye csendben elérhetővé a helyi szolgáltatásokat. Dinamikus felfelé címmel rendelkező gazdagépen a maszkolás a cím kézi követését is megspórolja.

Ahol a hub érvényt szerezhet és ahol nem

A client-to-client és a hagyományos felhasználói térbeli adatút mellett a hub a szerverfolyamaton belül adja át a belső csomagokat a partnerek között. Soha nem haladnak át a hub kernelfének FORWARD-láncán, ezért egy ottani kernelszabály nem korlátozhatja a partnerek közötti átjárást, bármilyen gondosan írják is. Az érvényesítésnek a szerver saját politikájában kell élnie: ki csatlakozhat, melyik CCD-fájlt kapja, és egyáltalán megkapja-e a kijárat alapértelmezett birtoklását.

Ezért az alapértelmezett iroute széles bizalmi döntés. A kijáratnak jogszerűen el kell fogadnia tetszőleges internetcímekről érkező visszaforgalmat, és olyan gépnek kell lennie, amelyet Ön irányít, javít és figyel. Ugyanazt a birtoklást adni egy olyan partnernek, akire nem bízna útválasztót az a hiba, amelyre ez a terv hív.

A tagság az igazi ellenőrzés. Bármely kliens, amely saját útvonalakat tud beállítani, megpróbálhatja használni a kijáratot, ezért annak korlátozása, hogy ki csatlakozhat, vagy mely partnereket szolgál ki a kijárat, a terv része, nem utólagos gondolat.

Biztonságos meghibásodás, amikor a kijárat eltűnik

Kapcsolja ki a kijáratot, és a belső alapértelmezett birtoklás eltűnik a munkamenetével. Ami nem történhet meg, az az, hogy a hub csendben helyettesítő kijárattá válik: semmilyen alapértelmezett útvonal a VPN-poolból a hub felfelé linkjére, és semmilyen széles maszkolási szabály a hubon, amely szívesen továbbítaná ugyanazt a forgalmat. Tesztelje ezt a hibát szándékosan, majd a helyreállást friss folyammal, nem pedig egy már nyitott oldallal.

# 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

Ha a fogyasztó forgalma a kijárat távozása után is eléri az internetet, valami más szállítja, és a szándékolt határ nem létezik. A DNS-t és az IPv6-ot is külön döntésként kezelje: egy IPv4-útvonal plusz maszkolás semmit nem mond az AAAA-forgalomról, és a hub által küldött feloldó onnan válaszol, ahonnan a lekérdezés valóban kilép.