pfSense kot VPN strežnik in odjemalec: dve poti, en usmerjevalnik
Vhodna storitev in izhodni tunel si lahko delita eno napravo. Trije pogoji odločajo, ali njihove poti, prevajanje in napake ostanejo ločeni.
Ena naprava lahko gleda v dve smeri hkrati: gostujoči uporabniki se povezujejo navznoter, ista škatla pa se povezuje navzven k ponudniku izhoda, da izbrani promet odhaja po drugem omrežju. Omogočanje obeh storitev vzame minute; sožitje zahteva načrt, ker druga vloga prepisuje usmerjevalno tabelo, na kateri prva temelji. Trije pogoji odločajo, ali postavitev deluje, in sicer ali vhodna storitev ohrani svojo povratno pot, ali izhodni tunel še doseže svojega partnerja in ali je promet, ki ste ga hoteli posredovati, izbran za izhod. Eno zgrešite in dobite dva tunela, ki oba poročata povezano, medtem ko med njima ne prehaja nič koristnega. Spodnje preverbe vzpostavijo vsak pogoj v vrstnem redu, v katerem se napake običajno pojavljajo.
Poimenujte obe vlogi, preden se dotaknete katere koli nastavitve
Zapišite štiri dejstva za vsak primer: njegovega oddaljenega partnerja, material za preverjanje pristnosti, nabor naslovov, ki ga deli, in omrežja za njim. Oba primera sta na napravi ločena objekta in bi morala ostati ločena tudi v vaših zapiskih. Skoraj vsak poznejši zmedeni simptom izhaja iz mešanja njunih vrednosti, dva primera, ki si delita en nabor zapiskov, pa sta pot, po kateri napačen nabor konča v napačnem polju.
Vhodna storitev potrebuje tunelsko omrežje, ki se ne prekriva z naslovi izhodnega tunela niti s katerim koli zasebnim omrežjem, ki ga naprava usmerja. Prekrivanje je edina napaka, ki hkrati povzroči simptome v obeh vlogah, in na papirju jo je veliko ceneje ujeti. Primerjajte oba nabora in vsako usmerjeno zasebno omrežje na enem mestu, preden konfigurirate katero od storitev.
Deljena strojna oprema ne pomeni deljenih poverilnic, potrdilo odjemalca iz nabora za oddaljeni dostop pa ne bi smelo biti uporabno proti ponudniku izhoda. Ločen material tudi preklic spremeni v lokalno odločitev namesto dogodka za celotno floto.
Držite odgovore strežnika na poti WAN
Odgovori, ki jih naprava ustvari sama, so prva žrtev neprevidne privzete poti. Ko prispe zapakiran paket gostujočega uporabnika, je odgovor lokalno nastali promet in mora oditi skozi vmesnik, skozi katerega je ta uporabnik prišel. Če je izhodni odjemalec namestil privzeto pot, ki jo ujame, odgovor zaide v napačen tunel in seja se ustavi, medtem ko je storitev videti še zdrava.
Ni enega potrditvenega polja, ki bi to razrešilo, ker se odločitev nanaša na to, kateri promet sme izhodni odjemalec ujeti. Bodisi ne vlecite nobenih poti in usmerjajte le tisto, kar izberete, bodisi vlecite poti in dodajte izjeme, ki ohranjajo lastne storitve naprave v teku. Zapišite izbiro poleg primera, sicer bo naslednja oseba domnevala drugo.
netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn
Berite usmerjevalno tabelo po najdaljšem ujemanju, ne po vrstnem redu, v katerem ste kar koli konfigurirali. Vprašanje je, kateri vnos zmaga za naslov partnerja izhoda in kateri vnos zmaga za odgovor vhodne storitve, in ta odgovora se lahko razlikujeta.
Ne pustite izhodnemu tunelu, da požre svojo končno točko
Izhodni odjemalec mora doseči javni naslov svojega partnerja, da tunel sploh vzpostavi. Če je ta naslov sam usmerjen v tunel, odjemalec lovi lastni rep: prenos se nikoli ne dvigne ali pa se dvigne in pade v trenutku, ko se pot namesti. Dnevnik je videti kot prekoračitev časa preverjanja pristnosti in ne kot napaka usmerjanja, zato si pot zasluži prvo preverbo.
Preverite pot pred poverilnicami in znova po tem, ko je tunel dvignjen, ker je vnos lahko ob zagonu pravilen in minuto pozneje napačen. Naslov partnerja mora kazati na običajno pot WAN, nikoli na tunelsko napravo. Ko se prenos ustali, se zanimivo vprašanje preseli na posredovani promet, kar je naslednja odločitev.
netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10
Izberite, kateri uporabniki dobijo izhod
Politika vira spada na vhod, kjer promet vstopa v napravo, zato izberite nabor za oddaljeni dostop ali ožje identitete v njem. Ohranite zasebne cilje in izjeme upravljanja, ki jih nikoli ne smete poslati na izhod, in ta pravila postavite pred široko. Pot izhoda nato potrebuje lastno prevajanje ali usmerjeno povratno ureditev, kar v večini načrtov pomeni izhodni NAT na vmesniku izhoda, ki pokriva nabor. Prevajanje ne izbere izhoda; prepiše le tisto, kar je že odšlo, zato pravilo NAT na nepovezanem WAN ne spremeni ničesar pri izbiri.
Potrdite, da oddaljena stran dovoljuje posredovani promet iz tega načrta, ker nekateri ponudniki ga dovoljujejo, drugi ne. Razlika se pokaže kot tunel, ki se poveže in ne nosi ničesar, kar je lahko brati kot lokalno napako. Preizkusite tri tokove ločeno, ker odpovedo neodvisno, in dva od treh je na pol zgrajen načrt.
openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health
Prvi ukaz je zunanja povezava gostujočega uporabnika in deluje, ko odjemalec sporoči, da je inicializacijsko zaporedje končano. Drugi, zagnan s tega povezanega prenosnika, bi moral sporočiti naslov ponudnika izhoda namesto vašega naslova WAN. Tretji teče na napravi, vezan na naslov iz nabora, in preizkusi politiko vira za posredovani promet, ne da bi sploh vključil oddaljenega uporabnika. Če namesto tega odgovori z WAN, se politika ni ujemala, in nobeno urejanje NAT ne popravi težave z izbiro.
Odločite, kaj se zgodi, ko izhod odpove
Zapišite vedenje ob napaki, preden se zgodi: ko izhodni tunel pade, se uporabniki vrnejo na običajni WAN ali so blokirani, dokler se izhod ne vrne? Oba odgovora sta zagovorljiva in naprava ne bo izbrala namesto vas. Odstranjena pot ali politika, ki kaže na mrtva vrata, ne ustvari samodejno popolnoma blokiranega izida. Če želite blokiranje, mora politika to izrecno povedati, in preizkusiti jo je treba z odvzemom izhoda, ne z razmišljanjem o njem. Če želite vrnitev, jo objavite uporabnikom, ker je promet, ki tiho zavzame običajno pot, natanko tisti promet, za katerega je nekdo mislil, da je pokrit.
Onemogočite odjemalčev primer, poglejte, do česa povezani uporabnik še pride, in ga nato znova zaženite. Zahteva, ki poteče, je izid popolne blokade, ki ste ga zahtevali; tista, ki odgovori z naslovom WAN, je vrnitev, ki je niste dokumentirali. Preverbo ponovite za IPv6 in za DNS, ker politika, napisana za IPv4, ne pove ničesar o prometu AAAA in razreševalnik, ki ga potisne kateri koli tunel, odgovarja od tam, kjer poizvedba res odide.
pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2
Netgateov recept za usmerjeni OpenVPN pokaže, kako se politika vira, dodelitev vmesnika in izhodno prevajanje ujemajo, in njegov obseg med lokacijami je del, ki ga ne gre kopirati v celoti. Česa pa vam ne bo povedal, je, kateri od treh zgornjih pogojev je vaš lastni načrt že prelomil.