pfSense OpenVPN: dosiahnutie siete za iným routerom

Váš notebook sa dostane do LAN pfSense cez VPN a napriek tomu sa nedostane k službe o dva skoky ďalej, a rozdiel je jedno rozhodnutie o smerovaní na každého vlastníka. Tri zariadenia sa musia zhodnúť, kým paket dokončí svoju cestu tam a späť: klient, firewall a router, ktorý skutočne vlastní cieľovú sieť. Vynechajte ktorýkoľvek z nich a príznak vyzerá rovnako.

Pred zmenou pravidla prejdite jeden paket týmito tromi rozhodnutiami, pretože každý vlastník má inú kontrolu a iný spôsob zlyhania.

Jeden paket, tri rozhodnutia o smerovaní

Klient rozhoduje, či cieľ patrí do tunela, a môže rozhodovať len z toho, čo pozná: vloženú trasu, lokálnu trasu alebo predvolenú trasu, ktorá už pokrýva všetko. pfSense rozhoduje, kam paket poslať ďalej, čo pre sieť za iným routerom znamená statickú trasu cez dostupnú bránu na správnom rozhraní. Nižší router rozhoduje, či pozná cestu späť do poolu VPN, a ak nie, odpoveď sa zahodí alebo odošle na nepotrebné miesto. Každé rozhodnutie je nezávislé od ostatných dvoch.

Zlyhanie ktoréhokoľvek z nich vytvára rovnaké hlásenie používateľa. Preto na poradí ladenia záleží viac než na nástrojoch.

Dajte klientovi prefix, nie odhad

Na serveri pfSense SSL/TLS s IPv4 tunelovou sieťou väčšou ako /30 pole IPv4 Local network(s) distribuuje trasy klientom pri pripojení. Pridajte tam nižší prefix namiesto spoliehania sa, že si klient nejaký vymyslí. Potom po pripojení prečítajte skutočnú tabuľku klienta, pretože profil s route-nopull alebo filter trás môže ignorovať to, čo server poslal. Server môže byť úplne správny, zatiaľ čo klient nič nenainštaluje.

Iné režimy servera a topológie majú iné obmedzenia a zásada pre jednotlivého klienta alebo spojenie môže zmeniť, čo konkrétny klient dostane. Overujte to na klientovi, na ktorom záleží, nie na tom, ktorý ste náhodou testovali ako prvý.

Nasmerujte pfSense na interný router

Statická trasa v pfSense potrebuje definovanú a dostupnú bránu a rozhranie zvolené pre túto bránu musí byť to, ktoré k nej skutočne vedie, ako opisuje príručka statických trás od Netgate. V ilustratívnom usporiadaní je tranzitné spojenie 192.168.77.1 na firewalle a 192.168.77.2 na internom routeri, pričom servisná sieť je 172.16.30.0/25 za ním. Trasa potom pomenúva prefix a ďalší skok, nie adresu služby. Použitie adresy zo vzdialenej siete ako brány je bežný spôsob, ako postaviť trasu, ktorá vyzerá správne a nikam neposiela.

Priradenie mena rozhraniu neopisuje siete za ním. Statická trasa je tým opisom.

Vzdialená strana musí poznať pool

Nižší router potrebuje spätnú trasu pre pool, v tomto príklade 10.55.0.0/24 cez 192.168.77.1, ak ju už neposkytuje predvolená trasa alebo dynamický protokol. Brána samotného hostiteľa služby musí viesť k tomuto routeru, čo zvyčajne platí, keď je router jeho predvolenou bránou, a neplatí, keď bol hostiteľ nastavený ručne. Smerovanie podľa zásad na firewalle môže tiež prepísať tabuľku pre konkrétnu prevádzku, takže predtým, než usúdite, že trasa je nesprávna, skontrolujte, či pravidlo nevyberá inú bránu.

Tento návrh nevyžaduje žiadny preklad a ponechanie zdrojovej adresy klienta viditeľnej umožňuje nižšej sieti uplatniť jej vlastné zásady.

Pre prijatie prejdite jednu novú požiadavku cez vstup do tunela, interný výstup firewallu a odpoveď z cieľa. Ak sa namiesto toho zámerne používa preklad, zaznamenajte, aký zdroj nižšia sieť vidí a ako sa očakáva návrat odpovede.

Uložte plán troch vlastníkov vedľa povolenej aplikácie, aby nasledujúci správca mohol cestu zrekonštruovať, a nie ju znovu objavovať.