Proč klienti OpenVPN míjejí selektory IPsec na bráně

Pošlete ping na host za vzdáleným tunelem IPsec z brány a on čistě odpoví, takže tunel vypadá zdravě a tiket jde dál. Pak připojený klient zkusí stejný host a nedostane nic zpět. Ten ping nikdy nebyl důkazem pro klientův tok, protože vyšel s vlastní zdrojovou adresou brány a odpovídal jinému selektoru IPsec. Pochopení, proč se ty dva případy rozcházejí, je většina opravy.

Ping z brány testuje tok, který váš klient nikdy nepoužívá

Zdrojová adresa rozhoduje, která politika se použije. Paket vytvořený na bráně vychází s adresou z její místní LAN nebo z jejího koncového bodu tunelu a politika, která mu odpovídá, byla napsána přesně pro tento případ. Paket klienta přichází na rozhraní OpenVPN s adresou z klientského poolu, což je úplně jiný selektor.

Proto porucha vypadá jako problém směrování, i když je ve skutečnosti problémem rozsahu politiky. Dostupnost z brány dokazuje, že protistrana žije a návrhy byly vyjednány, a nedokazuje nic o tom, zda je pool chráněn.

Pushujte vzdálený prefix, který aplikace skutečně potřebuje

Vezměte ilustrativní dvojici 10.8.0.0/24 pro připojené klienty a 172.30.239.0/25 pro chráněnou vzdálenou síť. Klient potřebuje trasu k druhému prefixu, ne k LAN brány a ne k nějaké jiné adrese tunelu. Právě trasa pushovaná do poolu způsobí, že klient tento provoz vůbec předá bráně. Bez ní se paket nikdy nedostane k rozhodnutí o politice, které ladíte.

Na serveru Community, který přijímá pushované trasy, direktiva přebírá skutečnou masku: push "route 172.30.239.0 255.255.255.128". Access Server konfiguruje stejný cíl přes nastavení privátní sítě nebo přístupových pravidel instalované verze, přičemž směrovaný nebo překládaný režim se volí záměrně. Úprava generovaných řetězců firewallu místo vlastní konfigurace je způsob, jak se funkční instalace stane nereprodukovatelnou.

Po připojení čtěte routovací tabulku klienta, ne záměr serveru. Trasa, která pokrývá jen pool, znamená, že push nedorazil, a výchozí trasa tunelem je širší než tento požadavek a později vás překvapí. Zkontrolujte masku i prefix, protože /25 pushovaná jako /24 posílá provoz sousedních adres cestou, která ho neunese. Pak potvrďte, že klient pro tento cíl zvolil rozhraní tunelu.

Zahrňte klientský pool do selektorů

Pro směrovaný přístup, který zachovává adresy klientů, musí politika IPsec chránit provoz mezi poolem a vzdáleným prefixem. Selektory napsané pro vlastní LAN brány pustí ping a zahodí klientův požadavek, a to je přesně ta asymetrie, která toto vyšetřování spustila.

Prohlédněte vyjednanou politiku i nakonfigurované návrhy, například pomocí ipsec statusall na strongSwanu nebo ekvivalentního stavového příkazu pro vaši implementaci. U IPsec založeného na politikách může běžná trasa ukazovat na fyzické rozhraní, zatímco odpovídající provoz je stále šifrován, takže chybějící tunelové zařízení nic nedokazuje. Porovnejte dvojice selektorů s poolem a prefixem, které jste si zapsali.

Obecný zdrojový NAT na bráně může shodu rozbít také. Pokud pravidlo masquerade přepíše zdroj klienta před kontrolou politiky, paket už nevypadá jako vámi napsaný selektor. To je jeden z důvodů, proč je široké pravidlo masquerade špatnou opravou druhého VPN: mění, která politika se použije a kterou adresu vzdálená strana loguje. Vyjměte provoz, který chcete směrovat, nebo ho záměrně přeložte a aktualizujte selektory.

Zvolte směrování nebo překlad záměrně

Směrování drží adresu klienta viditelnou pro vzdálenou stranu, takže vzdálené logy a pravidla podle zdroje zůstávají smysluplné, a vyžaduje, aby vzdálená brána znala zpětnou cestu k poolu. Překlad skrývá pool za jedinou adresou, což odstraňuje problém zpětné trasy a ničí identitu každého klienta.

Vyberte jeden návrh a zapište ho, protože oba potřebují různé selektory a různé pořadí firewallu. Napůl aplikovaný masquerade leží mezi nimi a neuspokojuje ani jeden. Zapsaná volba je také to, co dalšímu inženýrovi umožní rozeznat chybu od záměrného rozhodnutí.

Uzavřete smyčku na předávání a odpovědi

Brána musí předávat protokol a cíl, které zamýšlíte, což znamená zapnuté IP forwarding a řetězec předávání, který dvojici povolí. Vzdálená strana pak musí posílat odpovědi zpět cestou IPsec, a to je rozhodnutí o směrování na jejich bráně, ne na vaší. Obě poloviny jsou běžná konfigurace a obě lze snadno nechat nedokončené. Testujte je odděleně, aby chybějící pravidlo předávání nebylo zaměněno za rozbitý tunel.

Ověřte jedním skutečným požadavkem z klienta do aplikace a sledujte, jak prochází rozhraním OpenVPN, rozhodnutím IPsec a vzdáleným hostem. Odpověď zkoumejte jako samostatné pozorování, protože dorazivší požadavek a odpověď, která se nikdy nevrátí, vypadají z místa klienta stejně. Jeden trasovaný požadavek má větší cenu než jakýkoli počet pingů z brány.

Během testování držte autorizaci cíle úzkou a potvrďte, že klient bez pravidla se k službě nedostane. Nainstalovaná trasa plus navázaná asociace není totéž jako udělený přístup.