OpenVPN-kliensek átirányítása a Cloudflaren keresztül? Először a szerepet ellenőrizze
Az eszközökliens nem router. Erősítse meg, hogy a Cloudflare szerepe továbbítja más hosztok csomagjait, majd tartsa a szerver saját alagútját a régi útvonalán.
Van egy működő OpenVPN-szervere és egy hosztja, amely a Cloudflare eszközszoftverét is futtatja, és a nyilvánvaló következő lépés az ügyfélforgalom felé irányítása. Két működő kapcsolat egy gépen nem alkot tranzitátjárót. Hiányzik egy dokumentált szerep, amely máshoz tartozó csomagokat továbbít, és egy szabályzat, amely ezeket a csomagokat megérkezésükkor osztályozza.
Minden szabály előtt négy kérdés áll: milyen forgalom lép be, hova megy tovább, hogyan találják meg a válaszok a visszautat, és mit tesz a tervezés, amikor ez a második útvonal meghibásodik. Az első kettő képességkérdés.
Két szolgáltatás egy hoszton nem tranzitútvonal
Az eszközökliens arra készült, hogy a futtató gépen keletkező forgalmat kezelje. Elfogja a névfeloldást vagy a kiválasztott alkalmazásforgalmat, és a saját alagútján küldi tovább, a szabályzata pedig az adott eszköz felhasználójára és folyamataira íródott. Az OpenVPN-kliensből továbbított csomag nem helyi kimenet, ezért ugyanazok a szabályok nem osztályozzák. Ez nem olyan konfigurációs részlet, amelyet szélesebb szabállyal el lehet fedni, mert ez dönti el, hogy a szoftver egyáltalán látja-e a csomagot.
Ezért a tervezési kérdés képességkérdés. Vagy van a telepített terméknek dokumentált szerepe, amely más hálózatok forgalmát továbbítja, vagy a tranzitfunkció egészen máshová tartozik.
A Cloudflare melyik szerepe továbbíthat
A Cloudflare eszközökliens eltérő hatókörű módokat kínál: csak névfeloldás, az eszközről jövő forgalom, és néha mindkettő. Egyik mód sem teszi a hosztot routerré olyan privát tartomány számára, amely másik alagúton érkezik. A dedikált útválasztási szerep külön termék, saját csatlakozóval, regisztrációval és hálózati modellel.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
Ellenőrizze a telepített szerepet, mielőtt útvonalakat tervezne köré. Olvassa el, melyik interfészt hozza létre a csatlakozó, hirdet-e konkrét előtagokat vagy alapértelmezett útvonalat, és a helyi szabályzat vonatkozik-e a továbbított csomagokra is, nem csak a helyiekre. Ha csak a helyi forgalmat kezeli, az OpenVPN-szerver nem lehet a tranzitpont, akárhogyan is íródik a fordítási szabály.
Itt kell a nyilvános kijárat követelményét is pontosan megfogalmazni. A Cloudflare által a továbbított ügyfélforgalomhoz biztosított kijárat konkrét felhasználási eset, és a ténylegesen meglévő szolgáltatáshoz képest kell megerősíteni.
Tartsa a külső alagutat függetlenül az új útvonaltól
Abban a pillanatban, amikor alapértelmezett útvonalat ad az új interfészhez, a szerver saját kimenő forgalma versenyezni kezd érte, és ez magában foglalja az OpenVPN-klienseknek küldött válaszokat és a géphez irányuló SSH-munkamenetét. A szokásos tünet egy alagút, amely felépül, majd meghal, vagy egy kizárt adminisztrátor, miközben a változás működni látszik. Hasonlítsa össze az ip route get parancsot a végpontra előtte és utána, és használjon szabályzat alapú útválasztást vagy hosztútvonalat, hogy a szerver saját szállítása ott maradjon, ahol volt. Ezt az összehasonlítást magáról a gépről futtassa, mert a szerver saját útvonaláról alkotott képe az, ami számít.
A szerver nyilvános címére tett kivétel önmagában nem elég, mert minden távoli adminisztrátor visszaútja más folyam. Döntse el, mely folyamoknak kell túlélniük a változást, majd ellenőrizze mindegyiket ahelyett, hogy feltételezné, az első lefedi a többit.
Korlátozza a továbbítást és a fordítást egy folyamra
A fogadott csomagok a továbbítási útvonalat követik, nem a helyi kimeneti útvonalat, ezért a számító szabály a forward-horogban él. Ahol a következő interfésznek fordításra van szüksége, korlátozza a forrást az ügyfélkészletre, a célt az engedélyezettre és a kijáratot arra az egyetlen interfészre. Az csak egy interfészhez kötött masquerade-szabály önmagában nem választ útvonalat, és nem engedélyez továbbítást más szűrő mellett.
Döntse el előre a meghibásodáskor bezáró viselkedést, majd tesztelje. Állítsa le a következő útvonalat, és erősítse meg, hogy az ügyfelek elveszítik a szánt kijáratot, ahelyett hogy csendesen visszaesnének a szokásos felső kapcsolatra, mert ez az az eredmény, amelyet senki sem vesz észre, amíg a forgalom a rossz ajtón nem távozik. Ismételje meg az ellenőrzést a névfeloldásra és az IPv6-ra, mert a csak v4-re vonatkozó szabálykészlet nyitva hagy egy v6-os útvonalat.
Írja le azt a négy választ, amely mellett maradt, és a megfigyelést, amely mindegyiket bizonyítja. Egy tranzitútvonal, amelyet le tud írni, olyan, amelyet a következő incidensátvizsgáláson meg tud védeni.