pfSense OpenVPN: dosažení sítě za jiným routerem

Váš notebook dosáhne na LAN pfSense přes VPN a přesto nedosáhne na službu o dva skoky dál, a rozdíl je jedno rozhodnutí o směrování na každého vlastníka. Tři zařízení se musí shodnout, než paket dokončí svou cestu tam a zpět: klient, firewall a router, který síť cíle skutečně vlastní. Vynechte kteréhokoli z nich a příznak vypadá stejně.

Než změníte pravidlo, projděte jeden paket těmito třemi rozhodnutími, protože každý vlastník má jinou kontrolu a jiný způsob selhání.

Jeden paket, tři rozhodnutí o směrování

Klient rozhoduje, zda cíl patří do tunelu, a může rozhodovat jen z toho, co zná: vloženou trasu, místní trasu nebo výchozí trasu, která už pokrývá všechno. pfSense rozhoduje, kam paket poslat dál, což pro síť za jiným routerem znamená statickou trasu přes dostupnou bránu na správném rozhraní. Nižší router rozhoduje, zda zná cestu zpět do poolu VPN, a pokud ne, odpověď se zahodí nebo odešle na nepotřebné místo. Každé rozhodnutí je nezávislé na ostatních dvou.

Selhání kteréhokoli z nich vytváří stejné hlášení uživatele. Proto na pořadí ladění záleží víc než na nástrojích.

Dejte klientovi prefix, ne odhad

Na serveru pfSense SSL/TLS s IPv4 tunelovou sítí větší než /30 pole IPv4 Local network(s) distribuuje trasy klientům při připojení. Přidejte tam nižší prefix, místo abyste spoléhali, že si klient nějaký vymyslí. Poté po připojení přečtěte skutečnou tabulku klienta, protože profil s route-nopull nebo filtr tras může ignorovat to, co server poslal. Server může být naprosto správný, zatímco klient nic nenainstaluje.

Jiné režimy serveru a topologie mají jiná omezení a zásada pro jednotlivého klienta nebo spojení může změnit, co konkrétní klient dostane. Ověřujte to na klientovi, na kterém záleží, ne na tom, který jste náhodou testovali jako první.

Namiřte pfSense na interní router

Statická trasa v pfSense potřebuje definovanou a dostupnou bránu a rozhraní zvolené pro tuto bránu musí být to, které k ní skutečně vede, jak popisuje průvodce statickými trasami od Netgate. V ilustrativním uspořádání je tranzitní spoj 192.168.77.1 na firewallu a 192.168.77.2 na interním routeru, přičemž servisní síť je 172.16.30.0/25 za ním. Trasa pak pojmenovává prefix a další skok, ne adresu služby. Použití adresy ze vzdálené sítě jako brány je běžný způsob, jak postavit trasu, která vypadá správně a nikam neposílá.

Přiřazení jména rozhraní nepopisuje sítě za ním. Statická trasa je tím popisem.

Vzdálená strana musí znát pool

Nižší router potřebuje zpětnou trasu pro pool, v tomto příkladu 10.55.0.0/24 přes 192.168.77.1, pokud ji už neposkytuje výchozí trasa nebo dynamický protokol. Brána samotného hostitele služby musí vést k tomuto routeru, což obvykle platí, když je router jeho výchozí branou, a neplatí, když byl hostitel nastaven ručně. Směrování podle zásad na firewallu může také pro konkrétní provoz přepsat tabulku, takže než usoudíte, že je trasa špatná, zkontrolujte, zda pravidlo nevybírá jinou bránu.

Tento návrh nevyžaduje žádný překlad a ponechání zdrojové adresy klienta viditelné umožňuje nižší síti uplatnit její vlastní zásady.

Pro přijetí projděte jeden nový požadavek přes vstup do tunelu, interní výstup firewallu a odpověď z cíle. Pokud se místo toho záměrně používá překlad, zaznamenejte, jaký zdroj nižší síť vidí a jak se očekává návrat odpovědi.

Uložte plán tří vlastníků vedle povolené aplikace, aby příští správce mohl cestu zrekonstruovat, místo aby ji znovu objevoval.