Směrovat klienty OpenVPN přes Cloudflare? Nejprve zkontrolujte roli
Klient zařízení není router. Ověřte, že role Cloudflare předává pakety jiných hostitelů, a ponechte vlastní tunel serveru na jeho staré cestě.
Máte funkční server OpenVPN a hostitele, který také spouští software zařízení od Cloudflare, a zřejmý další krok vypadá jako směrování klientského provozu k němu. Dvě funkční spojení na jednom stroji netvoří tranzitní bránu. Chybí role dokumentovaná k předávání paketů, které patří někomu jinému, a politika, která tyto pakety při příchodu klasifikuje.
Před každým pravidlem stojí čtyři otázky: jaký provoz vstupuje, kam dál jde, jak si odpovědi najdou cestu zpět a co návrh dělá, když tato druhá cesta selže. První dvě jsou otázky schopností.
Dvě služby na jednom hostiteli nejsou tranzitní cesta
Klient zařízení je určen k obsluze provozu, který vzniká na stroji, kde běží. Zachycuje překlad jmen nebo vybraný provoz aplikací a posílá jej vlastním tunelem a jeho politika je napsána pro uživatele tohoto zařízení a procesy tohoto zařízení. Paket předaný z klienta OpenVPN není lokální výstup, takže jej stejná pravidla neklasifikují. To není detail konfigurace, který můžete zakrýt širším pravidlem, protože právě on rozhoduje, zda software paket vůbec uvidí.
Proto je otázka návrhu otázkou schopností. Buď má nainstalovaný produkt dokumentovanou roli, která předává provoz pro jiné sítě, nebo tranzitní funkce patří zcela jinam.
Která role Cloudflare smí předávat
Klient zařízení od Cloudflare nabízí režimy, které se liší rozsahem: pouze překlad jmen, provoz ze zařízení a někdy obojí. Žádný z těchto režimů nepromění hostitele v router pro privátní rozsah, který přichází jiným tunelem. Vyhrazená role směrování je samostatný produkt s vlastním konektorem, registrací a síťovým modelem.
| 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 |
Před navrhováním tras kolem něj zkontrolujte nainstalovanou roli. Přečtěte si, které rozhraní konektor vytváří, zda inzeruje konkrétní prefixy nebo výchozí trasu a zda se místní politika vztahuje na předávané pakety stejně jako na místní. Pokud se zpracovává jen místní provoz, server OpenVPN nemůže být tranzitním bodem, ať je pravidlo překladu napsáno jakkoli.
Zde je také třeba přesně formulovat požadavek na veřejný výstup. Výstup, který Cloudflare poskytuje pro předávaný klientský provoz, je konkrétní případ použití a je nutné jej potvrdit proti službě, kterou skutečně máte.
Udržte vnější tunel nezávislý na nové trase
Ve chvíli, kdy přidáte výchozí trasu k novému rozhraní, začne o ni soupeřit vlastní odchozí provoz serveru, a to včetně odpovědí klientům OpenVPN a vaší SSH relace ke stroji. Obvyklým příznakem je tunel, který se naváže a potom zemře, nebo administrátor uzamčený venku, zatímco se zdá, že změna fungovala. Porovnejte ip route get pro koncový bod před a po a použijte politické směrování nebo trasu k hostiteli, abyste vlastní transport serveru udrželi tam, kde byl. Toto porovnání spusťte ze samotného stroje, protože rozhodující je pohled serveru na jeho vlastní trasu.
Výjimka pro veřejnou adresu serveru sama o sobě nestačí, protože zpětná cesta každého vzdáleného administrátora je jiný tok. Rozhodněte, které z těchto toků musí změnu přežít, a potom každý ověřte, místo abyste předpokládali, že první pokrývá ostatní.
Omezte předávání a překlad na jeden tok
Přijaté pakety sledují cestu předávání, nikoli cestu místního výstupu, takže rozhodující pravidlo žije v háku forward. Kde další rozhraní potřebuje překlad, omezte zdroj na klientský fond, cíl na povolené a výstup na toto jediné rozhraní. Pravidlo masquerade navázané jen na rozhraní samo žádnou trasu nevybírá a neumožňuje předávání přes žádný jiný filtr.
Rozhodněte o chování při selhání předem a potom je otestujte. Zastavte další cestu a potvrďte, že klienti ztratí zamýšlený výstup, místo aby se tiše vrátili k obvyklému vzestupnému spoji, protože to je výsledek, kterého si nikdo nevšimne, dokud provoz nezačne vycházet špatnými dveřmi. Zopakujte kontrolu pro překlad jmen a pro IPv6, protože sada pravidel jen pro v4 nechává cestu v6 otevřenou.
Zapište si čtyři odpovědi, na kterých jste se shodli, a pozorování, které každou z nich dokládá. Tranzitní cesta, kterou dokážete popsat, je ta, kterou dokážete obhájit při příští revizi incidentů.