Downstream kliensek egy upstream VPN mögött: útvonal vagy NAT?

Egy átjáró WireGuardot futtat a saját eszközeidnek, és egy OpenVPN klienst valaki más hálózata felé. A továbbítás a két belső interfész között működik, és könnyű arra jutni, hogy a downstream alhálózat most az upstream szolgáltatás része. Nem az. A kliens által lekért útvonal megmondja az átjáródnak, hova küldje a kéréseket; semmit nem mond arról, hogyan küldi vissza a távoli hálózat a forgalmat olyan eszközöknek, amelyekről soha nem hallott. Válassz olyan visszatérési modellt, amelyet az upstream valóban támogat, mielőtt egyetlen szabályt is hozzáadnál.

Döntsd el a visszatérési modellt, mielőtt az útválasztáshoz nyúlsz

Ebben a bemutatóban a downstream kliensek a 10.90.0.0/24 címet használják, az átjárónak kiosztott upstream alagútcím 10.80.0.6, és a jóváhagyott távoli erőforrás 172.20.0.30. Két modell illik ehhez a formához: megtartani a downstream forrást, és rávenni a túloldalt, hogy irányítsa, vagy a forrást az átjáró saját alagútcímére fordítani. Minden e döntés után mechanikus, és maga a döntés a szolgáltatás tulajdonosát igényli. A fenti egyik sor útvonal-megállapodás a túloldallal; a másik helyi házirend-változás, amelyet egyedül is megtehetsz. A kettő összekeverése az, ami egy tízperces változtatást tárgyalássá tesz.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Válassz egy sort, és tartsd magad hozzá. A sorok alternatívák, nem lépések, és keverésük olyan tervet ad, amelyet senki nem tud elmagyarázni a felülvizsgálaton.

Forgalomirányított forrásmegőrzés

A túloldal egy downstream címről kap kérést, ezért támogatott útvonalra és peer-tulajdonjogra van szüksége ahhoz az alhálózathoz, valamint engedélyre annak elfogadásához. Ezek távoli beállítások, és egyetlen helyi Linux útvonal sem hozza létre őket. Kérd őket kifejezetten és írásban, az előtaggal és azzal az alagút-peerrrel, amely szállítani fogja, és számíts rá, hogy a válasz attól függ, támogat-e a szolgáltatás egyáltalán telephely-telephely megállapodásokat.

Ha a válasz igen, a helyi konfiguráció kicsi: továbbítás engedélyezve, a downstream tartományt lefedő WireGuard peer allowed-ips bejegyzései, és egy tűzfalszabály, amely mindkét irányban engedi az átkelést.

Szándékos forrásfordítás

Ha a szolgáltatás csak a csatlakozott kliens címére küldi vissza a forgalmat, fordítsd a forrást kifelé arra a címre, és tartsd meg a conntrack állapotot, amely a válaszokhoz visszafordítja. Szűkítsd a szabályt a szándékolt downstream forrásokra, a szándékolt távoli célokra és az upstream interfészre. Az a szabály, amely minden interfész minden kimenő forgalmát fordítja, sokkal nagyobb házirend, mint ez a követelmény, és később meg fog lepni.

Az IPv6 saját tervet igényel; egy IPv4 masquerade sor lemásolása nem architektúra. Teszteld a fordított útvonalat új kapcsolattal, ne gyorsítótárazottal.

A helyi adatútvonalnak még mindig működnie kell

A fordítás nem szünteti meg a helyi munkát: az átjárónak továbbra is kell útvonal a downstream célokhoz, a helyes WireGuard peer forrás-tulajdonjog, engedélyezett továbbítás és szűk tűzfalszabály az interfészek között. Az átjárón magán keletkező kérés egyiket sem gyakorolja ezek közül az engedélyek közül, ezért a helyi tesztek átmennek az átjárón, a downstream eszközök viszont továbbra is elbuknak.

Valódi downstream eszközről tesztelj, ne az átjáróról. A forráscím a gyakorlat egész értelme.

Egy forrás egy munkamenet-identitást jelent

A távoli szolgáltatás az átjáró hitelesített munkamenetét és annak fordított címét látja, nem külön hitelesítést minden downstream eszközhöz. Tartsd explicit módon az eszközönkénti engedélyeket és az alkalmazásidentitásokat, és erősítsd meg a szolgáltatás tulajdonosával, hogy egy több eszközt képviselő átjáró egyáltalán engedélyezett. A fordítás nem módja az eszközönkénti regisztrációs követelmény megkerülésének; ha a szolgáltatás minden eszköz regisztrációját kéri, használd azt a modellt, vagy tárgyalj telephely-telephely megállapodást.

Írd be ezt a megerősítést a runbookba a szabály mellé, mert a következő ellenőrző meg fogja kérdezni, hogy a tervet jóváhagyták-e, vagy csak kényelmes volt.

Határozd meg a szakadt állapotot, majd tesztelj három kérést

Döntsd el, mi történik, ha az upstream alagút leesik. Az engedélyezett távoli forgalom nem követheti csendben a szokásos WAN tartalékutat ott, ahol ez tilos, ezért az átkelést engedő tűzfalszabálynak zárt állapotban is el kell buknia. Ezután tesztelj három esetet valódi downstream eszközről: egy működő engedélyezett kérést, egy elbukó tiltott kérést, és egy upstream hibát, amely megállítja az engedélyezettet.

Rögzítsd a visszaállítást szabályonként egy sorban, hogy a változtatás a szándék újrateremtése nélkül visszavonható legyen.