Prečo klienti OpenVPN míňajú selektory IPsec brány

Pošlite ping na host za vzdialeným tunelom IPsec z brány a odpovie čisto, takže tunel vyzerá zdravo a tiket ide ďalej. Potom pripojený klient skúsi ten istý host a nedostane nič späť. Ten ping nikdy nebol dôkazom pre tok klienta, pretože vyšiel s vlastnou zdrojovou adresou brány a zodpovedal inému selektoru IPsec. Pochopenie, prečo sa tieto dva prípady rozchádzajú, je väčšina opravy.

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

Zdrojová adresa rozhoduje, ktorá politika sa uplatní. Paket vytvorený na bráne vychádza s adresou z jej lokálnej LAN alebo z koncového bodu tunela a politika, ktorá mu zodpovedá, bola napísaná presne pre tento prípad. Paket klienta prichádza na rozhranie OpenVPN s adresou z klientskeho poolu, čo je úplne iný selektor.

Preto porucha vyzerá ako problém smerovania, hoci v skutočnosti je problémom rozsahu politiky. Dostupnosť z brány dokazuje, že partner žije a návrhy boli vyjednané, a nedokazuje nič o tom, či je pool chránený.

Pushnite vzdialený prefix, ktorý aplikácia naozaj potrebuje

Vezmite ilustratívnu dvojicu 10.8.0.0/24 pre pripojených klientov a 172.30.239.0/25 pre chránenú vzdialenú sieť. Klient potrebuje trasu k druhému prefixu, nie k LAN brány a nie k nejakej inej adrese tunela. Práve trasa pushnutá do poolu spôsobí, že klient tento tok vôbec odovzdá bráne. Bez nej sa paket nikdy nedostane k rozhodnutiu o politike, ktoré ladíte.

Na serveri Community, ktorý prijíma pushnuté trasy, direktíva preberá skutočnú masku: push "route 172.30.239.0 255.255.255.128". Access Server konfiguruje rovnaký cieľ cez nastavenia súkromnej siete alebo prístupových pravidiel inštalovanej verzie, pričom smerovaný alebo prekladaný režim sa volí zámerne. Úprava generovaných reťazcov firewallu namiesto vlastnej konfigurácie je spôsob, akým sa funkčná inštalácia stane nereprodukovateľnou.

Po pripojení čítajte smerovaciu tabuľku klienta, nie zámer servera. Trasa pokrývajúca len pool znamená, že push nikdy nedorazil, a predvolená trasa cez tunel je širšia než táto požiadavka a neskôr vás prekvapí. Skontrolujte masku aj prefix, pretože /25 pushnutá ako /24 posiela tok susedných adries cestou, ktorá ho neunesie. Potom potvrďte, že klient pre tento cieľ zvolil rozhranie tunela.

Nechajte selektory zahŕňať klientsky pool

Pre smerovaný prístup, ktorý zachováva adresy klientov, politika IPsec musí chrániť tok medzi poolom a vzdialeným prefixom. Selektory napísané pre vlastnú LAN brány pustia ping a zahodia požiadavku klienta, a to je presne tá asymetria, ktorá začala toto vyšetrovanie.

Preskúmajte vyjednanú politiku aj nakonfigurované návrhy, napríklad pomocou ipsec statusall na strongSwane alebo ekvivalentného stavového príkazu pre vašu implementáciu. Pri IPsec založenom na politikách môže bežná trasa ukazovať na fyzické rozhranie, kým zodpovedajúci tok je stále šifrovaný, takže chýbajúce tunelové zariadenie nič nedokazuje. Porovnajte dvojice selektorov s poolom a prefixom, ktoré ste si zapísali.

Všeobecný zdrojový NAT na bráne môže zhodu pokaziť tiež. Ak pravidlo masquerade prepíše zdroj klienta pred kontrolou politiky, paket už nevyzerá ako selektor, ktorý ste napísali. To je jeden z dôvodov, prečo je široké pravidlo masquerade zlou opravou pre druhý VPN: mení, ktorá politika platí a ktorú adresu vzdialená strana zaznamená. Vylúčte tok, ktorý chcete smerovať, alebo ho zámerne preložte a aktualizujte selektory.

Zvoľte smerovanie alebo preklad zámerne

Smerovanie drží adresu klienta viditeľnú pre vzdialenú stranu, takže vzdialené záznamy a pravidlá podľa zdroja zostávajú zmysluplné, a vyžaduje, aby vzdialená brána poznala spiatočnú cestu k poolu. Preklad skrýva pool za jedinou adresou, čo odstraňuje problém spiatočnej trasy a ničí identitu každého klienta.

Vyberte jeden dizajn a zapíšte ho, pretože oba potrebujú rôzne selektory a iné poradie firewallu. Napoly použitý masquerade skončí medzi nimi a neuspokojí ani jeden. Zapísaná voľba je aj to, čo ďalšiemu inžinierovi umožňuje rozlíšiť chybu od zámerného rozhodnutia.

Uzavrite slučku na preposielaní a odpovedi

Brána musí preposielať protokol a cieľ, ktoré máte na mysli, čo znamená zapnuté preposielanie IP a reťazec preposielania, ktorý dvojicu povoľuje. Potom vzdialená strana musí posielať odpovede späť cestou IPsec, a to je rozhodnutie o smerovaní na ich bráne, nie na vašej. Obe polovice sú bežná konfigurácia a obe sa dajú ľahko nechať nedokončené. Testujte ich oddelene, aby chýbajúce pravidlo preposielania nebolo zamenené za rozbitý tunel.

Overte jednou skutočnou požiadavkou z klienta do aplikácie a sledujte, ako prechádza rozhraním OpenVPN, rozhodnutím IPsec a vzdialeným hostom. Odpoveď skúmajte ako samostatné pozorovanie, pretože prichádzajúca požiadavka a odpoveď, ktorá sa nikdy nevráti, vyzerajú z miesta klienta rovnako. Jedna sledovaná požiadavka má väčšiu cenu než akýkoľvek počet pingov z brány.

Počas testovania držte autorizáciu cieľa úzku a potvrďte, že klient bez pravidla sa k službe nedostane. Nainštalovaná trasa plus nadviazaná asociácia nie je to isté ako udelený prístup.