pfSense jako VPN server i klient: dvě cesty, jeden router

Jeden přístroj může mířit dvěma směry současně: roamingoví uživatelé se připojují dovnitř a stejná krabice se připojuje ven k poskytovateli výstupu, aby vybraný provoz odcházel přes jinou síť. Zapnout obě služby trvá minuty; přimět je k soužití vyžaduje návrh, protože druhá role přepisuje směrovací tabulku, na níž první závisí. Tři podmínky rozhodují, zda uspořádání funguje, totiž zda si příchozí služba zachová vlastní zpáteční cestu, zda odchozí tunel ještě dosáhne na svůj protějšek a zda je provoz, který jste chtěli předávat, vybrán pro výstup. Spletete jednu a máte dva tunely, které oba hlásí spojení, zatímco mezi nimi nepřechází nic užitečného. Kontroly níže zavádějí každou podmínku v pořadí, v jakém se poruchy obvykle objevují.

Pojmenujte obě role, než se dotknete jakéhokoli nastavení

Zapište čtyři skutečnosti pro každou instanci: její vzdálený protějšek, autentizační materiál, fond adres, který přiděluje, a sítě za ní. Obě instance jsou na přístroji samostatné objekty a měly by zůstat samostatné i ve vašich poznámkách. Téměř každý matoucí příznak později pochází ze smíchání jejich hodnot, a dvě instance sdílející jednu sadu poznámek jsou způsob, jak se špatný fond ocitne ve špatném poli.

Příchozí služba potřebuje tunelovou síť, která se nepřekrývá s adresami odchozího tunelu ani s žádnou privátní sítí, kterou přístroj směruje. Překryv je jediná chyba, která vyvolává příznaky v obou rolích najednou, a na papíře je mnohem levnější ji zachytit. Porovnejte oba fondy a každou směrovanou privátní síť na jednom místě, než začnete konfigurovat kteroukoli ze služeb.

Sdílený hardware neznamená sdílené přihlašovací údaje a klientský certifikát z fondu vzdáleného přístupu by neměl být použitelný proti poskytovateli výstupu. Oddělený materiál také mění odvolání v místní rozhodnutí namísto události pro celou flotilu.

Udržte odpovědi serveru na cestě WAN

Odpovědi, které přístroj sám generuje, jsou první obětí neopatrné výchozí trasy. Když dorazí zapouzdřený paket roamingového uživatele, odpověď je lokálně vzniklý provoz a musí odejít rozhraním, kterým ten uživatel přišel. Pokud odchozí klient nainstaloval výchozí trasu, která ji zachytí, odpověď vstoupí do špatného tunelu a relace se zasekne, zatímco služba stále vypadá zdravě.

Neexistuje jedno zaškrtávací políčko, které to vyřeší, protože rozhodnutí se týká toho, který provoz smí odchozí klient zachytávat. Buď nestahujte žádné trasy a nasměrujte jen to, co vyberete, nebo stáhněte trasy a přidejte výjimky, které udrží vlastní služby přístroje v chodu. Zapište volbu vedle instance, jinak příští člověk bude předpokládat tu druhou.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Čtěte směrovací tabulku podle nejdelší shody, nikoli podle pořadí, v jakém jste co konfigurovali. Otázkou je, která položka vyhraje pro adresu protějšku výstupu a která položka vyhraje pro odpověď příchozí služby, a tyto dvě odpovědi se mohou lišit.

Nenechte odchozí tunel sníst jeho vlastní koncový bod

Odchozí klient musí dosáhnout veřejné adresy svého protějšku, aby vůbec tunel navázal. Pokud je tato adresa sama směrována do tunelu, klient honí vlastní ocas: transport nikdy nevstane, nebo vstane a spadne v okamžiku, kdy se trasa nainstaluje. Protokol vypadá jako vypršení autentizace, nikoli jako porucha směrování, a proto si trasa zaslouží kontrolu první.

Zkontrolujte trasu před přihlašovacími údaji a znovu poté, co tunel vstane, protože položka může být při startu správná a o minutu později špatná. Adresa protějšku musí ukazovat na běžnou cestu WAN, nikdy na tunelové zařízení. Jakmile je transport stabilní, zajímavá otázka se přesouvá k předávanému provozu, což je další rozhodnutí.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Vyberte, kteří uživatelé dostanou výstup

Zdrojová politika patří na vstup, kde provoz vstupuje do přístroje, takže vyberte fond vzdáleného přístupu nebo užší identity v něm. Zachovejte privátní cíle a výjimky správy, které se nikdy nesmějí poslat na výstup, a umístěte tato pravidla před široké. Cesta výstupu pak potřebuje vlastní překlad nebo směrované zpětné uspořádání, což pro většinu návrhů znamená odchozí NAT na výstupním rozhraní pokrývající fond. Překlad nevybírá výstup; pouze přepisuje to, co už odešlo, takže pravidlo NAT na nesouvisející WAN nemění na výběru nic.

Ověřte, že vzdálená strana povoluje předávaný provoz z tohoto návrhu, protože někteří poskytovatelé ano a někteří ne. Rozdíl se projeví jako tunel, který se spojí a nic nenese, což lze snadno číst jako místní poruchu. Testujte tři toky odděleně, protože selhávají nezávisle a dva ze tří je napůl postavený návrh.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

První příkaz je vnější spojení roamingového uživatele a funguje, když klient hlásí dokončení inicializační sekvence. Druhý, spuštěný z toho připojeného notebooku, by měl hlásit adresu poskytovatele výstupu, nikoli vaši adresu WAN. Třetí běží na přístroji vázán na adresu z fondu a testuje zdrojovou politiku pro předávaný provoz, aniž by vůbec zapojil vzdáleného uživatele. Pokud místo toho odpoví z WAN, politika neseděla a žádné množství úprav NAT neopraví problém s výběrem.

Rozhodněte, co se stane, když výstup selže

Zapište chování při poruše dřív, než nastane: když odchozí tunel spadne, vracejí se uživatelé na běžnou WAN, nebo jsou zablokováni, dokud se výstup nevrátí? Obě odpovědi jsou obhajitelné a přístroj za vás nevybere. Odebraná trasa nebo politika ukazující na mrtvou bránu automaticky nevede k výsledku úplného zablokování. Chcete-li blokování, politika to musí říct výslovně a musí se to otestovat odebráním výstupu, ne uvažováním o něm. Chcete-li návrat, oznamte to uživatelům, protože provoz, který tiše jde běžnou cestou, je přesně ten provoz, o němž si někdo myslel, že je pokrytý.

Vypněte klientskou instanci, sledujte, k čemu se připojený uživatel ještě dostane, a pak ji znovu spusťte. Požadavek, který vyprší, je výsledek úplného zablokování, který jste chtěli; ten, který odpoví adresou WAN, je návrat, který jste nedokumentovali. Kontrolu zopakujte pro IPv6 a pro DNS, protože politika psaná pro IPv4 neříká nic o provozu AAAA a resolver protlačený kterýmkoli tunelem odpovídá odtud, odkud dotaz skutečně vychází.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Recept Netgate na směrovaný OpenVPN ukazuje, jak do sebe zapadají zdrojová politika, přiřazení rozhraní a odchozí překlad, a jeho rozsah mezi lokalitami je část, kterou nemá smysl kopírovat celou. Co vám ale neřekne, je, kterou ze tří podmínek výše váš vlastní návrh už porušil.