Smerovať klientov OpenVPN cez Cloudflare? Najprv skontrolujte rolu
Klient zariadenia nie je router. Potvrďte, že rola Cloudflare preposiela pakety iných hostiteľov, a ponechajte vlastný tunel servera na jeho starej ceste.
Máte funkčný server OpenVPN a hostiteľa, ktorý tiež spúšťa softvér zariadenia od Cloudflare, a zrejmý ďalší krok vyzerá ako smerovanie klientskej prevádzky k nemu. Dve funkčné spojenia na jednom stroji netvoria tranzitnú bránu. Chýba rola dokumentovaná na preposielanie paketov, ktoré patria niekomu inému, a politika, ktorá tieto pakety pri príchode klasifikuje.
Pred každým pravidlom stoja štyri otázky: aká prevádzka vstupuje, kam ide ďalej, ako si odpovede nájdu cestu späť a čo robí návrh, keď táto druhá cesta zlyhá. Prvé dve sú otázky schopností.
Dve služby na jednom hostiteľovi nie sú tranzitná cesta
Klient zariadenia je určený na obsluhu prevádzky, ktorá vzniká na stroji, kde beží. Zachytáva preklad názvov alebo vybranú prevádzku aplikácií a posiela ju vlastným tunelom, a jeho politika je napísaná pre používateľa tohto zariadenia a procesy tohto zariadenia. Paket preposlaný z klienta OpenVPN nie je lokálny výstup, takže ho rovnaké pravidlá neklasifikujú. To nie je detail konfigurácie, ktorý možno zakryť širším pravidlom, pretože práve on rozhoduje, či softvér paket vôbec vidí.
Preto je otázka návrhu otázkou schopností. Buď má nainštalovaný produkt dokumentovanú rolu, ktorá preposiela prevádzku pre iné siete, alebo tranzitná funkcia patrí celkom inam.
Ktorá rola Cloudflare smie preposielať
Klient zariadenia od Cloudflare ponúka režimy, ktoré sa líšia rozsahom: iba preklad názvov, prevádzka zo zariadenia a niekedy oboje. Žiadny z týchto režimov nerobí z hostiteľa router pre privátny rozsah, ktorý prichádza iným tunelom. Vyhradená rola smerovania je samostatný produkt s vlastným konektorom, registráciou a sieťovým modelom.
| 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 |
Pred navrhovaním trás okolo nej skontrolujte nainštalovanú rolu. Prečítajte si, ktoré rozhranie konektor vytvára, či inzeruje konkrétne prefixy alebo predvolenú trasu a či sa miestna politika vzťahuje aj na preposielané pakety, nielen na miestne. Ak sa spracúva len miestna prevádzka, server OpenVPN nemôže byť tranzitným bodom, nech je pravidlo prekladu napísané akokoľvek.
Tu treba tiež presne sformulovať požiadavku na verejný výstup. Výstup, ktorý Cloudflare poskytuje pre preposielanú klientsku prevádzku, je konkrétny prípad použitia a treba ho potvrdiť voči službe, ktorú skutočne máte.
Udržte vonkajší tunel nezávislý od novej trasy
V okamihu, keď pridáte predvolenú trasu k novému rozhraniu, vlastná odchádzajúca prevádzka servera o ňu začne súťažiť, a to zahŕňa odpovede klientom OpenVPN a vašu SSH reláciu k stroju. Zvyčajným príznakom je tunel, ktorý sa nadviaže a potom zomrie, alebo administrátor uzamknutý vonku, kým sa zdá, že zmena fungovala. Porovnajte ip route get pre koncový bod pred a po a použite smerovanie podľa politiky alebo trasu k hostiteľovi, aby vlastná doprava servera zostala tam, kde bola. Toto porovnanie vykonajte zo samotného stroja, pretože rozhodujúci je pohľad servera na jeho vlastnú trasu.
Výnimka pre verejnú adresu servera sama o sebe nestačí, pretože spätná cesta každého vzdialeného administrátora je iný tok. Rozhodnite, ktoré z týchto tokov musia zmenu prežiť, a potom overte každý, namiesto toho, aby ste predpokladali, že prvý pokrýva ostatné.
Obmedzte preposielanie a preklad na jeden tok
Prijaté pakety sledujú cestu preposielania, nie cestu miestneho výstupu, takže rozhodujúce pravidlo žije v háku forward. Kde ďalšie rozhranie potrebuje preklad, obmedzte zdroj na klientsky fond, cieľ na povolené a výstup na toto jediné rozhranie. Pravidlo masquerade naviazané len na rozhranie samo nevyberá trasu a neumožňuje preposielanie popri žiadnom inom filtri.
Rozhodnite o správaní pri zlyhaní vopred a potom ho otestujte. Zastavte ďalšiu cestu a potvrďte, že klienti stratia zamýšľaný výstup, namiesto toho aby sa ticho vrátili k obvyklému vzostupnému spoju, pretože to je výsledok, ktorý si nikto nevšimne, kým prevádzka nezačne vychádzať nesprávnymi dverami. Zopakujte kontrolu pre preklad názvov a pre IPv6, pretože sada pravidiel len pre v4 necháva cestu v6 otvorenú.
Zapíšte štyri odpovede, na ktorých ste sa ustálili, a pozorovanie, ktoré každú z nich dokazuje. Tranzitná cesta, ktorú dokážete opísať, je tá, ktorú dokážete obhájiť na ďalšej revízii incidentov.