pfSense ako VPN server a klient: dve cesty, jeden router

Jedno zariadenie môže pozerať dvoma smermi naraz: roamingoví používatelia sa pripájajú dovnútra a tá istá krabica sa pripája von k poskytovateľovi výstupu, aby vybraná premávka odchádzala cez inú sieť. Zapnutie oboch služieb trvá minúty; ich spolunažívanie si vyžaduje návrh, pretože druhá rola prepisuje smerovaciu tabuľku, na ktorej prvá závisí. Tri podmienky rozhodujú, či usporiadanie funguje, totiž či si prichádzajúca služba zachová vlastnú spätnú cestu, či odchádzajúci tunel ešte dosiahne svojho partnera a či je premávka, ktorú ste chceli preposielať, vybraná pre výstup. Pomýlite jednu a máte dva tunely, ktoré oba hlásia spojenie, zatiaľ čo medzi nimi neprechádza nič užitočné. Kontroly nižšie zavádzajú každú podmienku v poradí, v akom sa poruchy zvyčajne objavujú.

Pomenujte obe roly, skôr než sa dotknete akéhokoľvek nastavenia

Zapíšte štyri skutočnosti pre každú inštanciu: jej vzdialeného partnera, autentifikačný materiál, fond adries, ktorý prideľuje, a siete za ňou. Obe inštancie sú na zariadení samostatné objekty a mali by zostať samostatné aj vo vašich poznámkach. Takmer každý mätúci príznak neskôr pochádza zo zmiešania ich hodnôt, a dve inštancie zdieľajúce jednu sadu poznámok sú spôsob, akým sa nesprávny fond ocitne v nesprávnom poli.

Prichádzajúca služba potrebuje tunelovú sieť, ktorá sa neprekrýva s adresami odchádzajúceho tunela ani so žiadnou súkromnou sieťou, ktorú zariadenie smeruje. Prekryv je jediná chyba, ktorá vyvoláva príznaky v oboch rolách naraz, a na papieri je oveľa lacnejšie ju zachytiť. Porovnajte oba fondy a každú smerovanú súkromnú sieť na jednom mieste, skôr než začnete konfigurovať ktorúkoľvek zo služieb.

Zdieľaný hardvér neznamená zdieľané prihlasovacie údaje a klientsky certifikát z fondu vzdialeného prístupu by nemal byť použiteľný proti poskytovateľovi výstupu. Oddelený materiál mení aj odvolanie na lokálne rozhodnutie namiesto udalosti pre celú flotilu.

Držte odpovede servera na ceste WAN

Odpovede, ktoré zariadenie samo generuje, sú prvou obeťou nepozornej predvolenej trasy. Keď príde zapuzdrený paket roamingového používateľa, odpoveď je lokálne vzniknutá premávka a musí odísť rozhraním, ktorým ten používateľ prišiel. Ak odchádzajúci klient nainštaloval predvolenú trasu, ktorá ju zachytí, odpoveď vstúpi do nesprávneho tunela a relácia sa zastaví, zatiaľ čo služba stále vyzerá zdravo.

Neexistuje jedno zaškrtávacie pole, ktoré to vyrieši, pretože rozhodnutie sa týka toho, ktorú premávku smie odchádzajúci klient zachytávať. Buď nestahujte žiadne trasy a smerujte len to, čo vyberiete, alebo stiahnite trasy a pridajte výnimky, ktoré udržia vlastné služby zariadenia v chode. Zapíšte voľbu vedľa inštancie, inak ďalší človek bude predpokladať tú druhú.

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

Čítajte smerovaciu tabuľku podľa najdlhšej zhody, nie podľa poradia, v akom ste čo konfigurovali. Otázkou je, ktorý záznam vyhrá pre adresu partnera výstupu a ktorý záznam vyhrá pre odpoveď prichádzajúcej služby, a tieto dve odpovede sa môžu líšiť.

Nenechajte odchádzajúci tunel zjesť jeho vlastný koncový bod

Odchádzajúci klient musí dosiahnuť verejnú adresu svojho partnera, aby vôbec tunel nadviazal. Ak je táto adresa sama smerovaná do tunela, klient naháňa vlastný chvost: transport nikdy nevstane, alebo vstane a padne v okamihu, keď sa trasa nainštaluje. Protokol vyzerá ako vypršanie autentifikácie, nie ako porucha smerovania, a preto si trasa zaslúži prvú kontrolu.

Skontrolujte trasu pred prihlasovacími údajmi a znova po tom, čo tunel vstane, pretože záznam môže byť pri štarte správny a o minútu neskôr nesprávny. Adresa partnera musí ukazovať na bežnú cestu WAN, nikdy na tunelové zariadenie. Keď je transport stabilný, zaujímavá otázka sa presúva k preposielanej premávke, čo je ďalšie rozhodnutie.

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

Vyberte, ktorí používatelia dostanú výstup

Zdrojová politika patrí na vstup, kde premávka vstupuje do zariadenia, takže vyberte fond vzdialeného prístupu alebo užšie identity v ňom. Zachovajte súkromné ciele a výnimky správy, ktoré sa nikdy nesmú poslať na výstup, a umiestnite tieto pravidlá pred široké. Cesta výstupu potom potrebuje vlastný preklad alebo smerované spätné usporiadanie, čo pre väčšinu návrhov znamená odchádzajúci NAT na výstupnom rozhraní pokrývajúci fond. Preklad nevyberá výstup; iba prepisuje to, čo už odišlo, takže pravidlo NAT na nesúvisiacej WAN nič nemení vo výbere.

Overte, že vzdialená strana povoľuje preposielanú premávku z tohto návrhu, pretože niektorí poskytovatelia áno a niektorí nie. Rozdiel sa prejaví ako tunel, ktorý sa spojí a nič nenesie, čo sa dá ľahko čítať ako lokálna porucha. Testujte tri toky oddelene, pretože zlyhávajú nezávisle, a dva z troch je napoly postavený návrh.

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

Prvý príkaz je vonkajšie spojenie roamingového používateľa a funguje, keď klient hlási dokončenie inicializačnej sekvencie. Druhý, spustený z toho pripojeného notebooku, by mal hlásiť adresu poskytovateľa výstupu namiesto vašej adresy WAN. Tretí beží na zariadení viazaný na adresu z fondu a testuje zdrojovú politiku pre preposielanú premávku bez toho, aby vôbec zapojil vzdialeného používateľa. Ak namiesto toho odpovie z WAN, politika nesedela a žiadne množstvo úprav NAT neopraví problém s výberom.

Rozhodnite, čo sa stane, keď výstup zlyhá

Zapíšte správanie pri poruche skôr, než nastane: keď odchádzajúci tunel padne, vracajú sa používatelia na bežnú WAN, alebo sú zablokovaní, kým sa výstup nevráti? Obe odpovede sú obhájiteľné a zariadenie za vás nevyberie. Odstránená trasa alebo politika ukazujúca na mŕtvu bránu automaticky nevedie k výsledku úplného zablokovania. Ak chcete blokovanie, politika to musí povedať výslovne a musí sa to otestovať odobratím výstupu, nie uvažovaním o ňom. Ak chcete návrat, oznámte to používateľom, pretože premávka, ktorá potichu ide bežnou cestou, je presne tá premávka, o ktorej si niekto myslel, že je pokrytá.

Vypnite klientsku inštanciu, sledujte, k čomu sa pripojený používateľ ešte dostane, a potom ju znova spustite. Požiadavka, ktorá vyprší, je výsledok úplného zablokovania, ktorý ste chceli; tá, ktorá odpovie adresou WAN, je návrat, ktorý ste nedokumentovali. Kontrolu zopakujte pre IPv6 a pre DNS, pretože politika písaná pre IPv4 nehovorí nič o premávke AAAA a resolver pretlačený ktorýmkoľvek tunelom odpovedá odtiaľ, odkiaľ dopyt skutočne vychádza.

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 smerovaný OpenVPN ukazuje, ako do seba zapadajú zdrojová politika, priradenie rozhrania a odchádzajúci preklad, a jeho rozsah medzi lokalitami je časť, ktorú netreba kopírovať celú. Čo vám však nepovie, je, ktorú z troch podmienok vyššie váš vlastný návrh už porušil.