pfSense kao VPN poslužitelj i klijent: dvije staze, jedan usmjerivač

Jedan uređaj može gledati u dva smjera istovremeno: roaming korisnici se spajaju unutra, a isti uređaj se spaja van ka provajderu izlaza tako da odabrani saobraćaj izlazi kroz drugu mrežu. Uključivanje obje usluge traje nekoliko minuta; njihovo zajedničko postojanje zahtijeva projekt, jer druga uloga prepisuje tabelu rutiranja na koju se prva oslanja. Tri uslova odlučuju da li raspored radi, naime da li dolazna usluga zadržava svoju povratnu putanju, da li odlazni tunel još uvijek može doći do svog partnera i da li se saobraćaj koji ste namjeravali proslijediti bira za izlaz. Pogriješite li jedno, dobijate dva tunela koja oba izvještavaju da su povezana dok između njih ne prelazi ništa korisno. Provjere ispod uspostavljaju svaki uslov redom kojim se kvarovi obično pojavljuju.

Imenujte dvije uloge prije nego što dotaknete bilo koju postavku

Zapišite četiri činjenice za svaku instancu: njen udaljeni partner, njen materijal za autentifikaciju, bazen adresa koji dodjeljuje i mreže iza nje. Dvije instance su odvojeni objekti na uređaju i treba da ostanu odvojeni i u vašim bilješkama. Gotovo svaki zbunjujući simptom kasnije dolazi iz miješanja njihovih vrijednosti, a dvije instance koje dijele jedan skup bilježaka su način na koji pogrešan bazen završi u pogrešnom polju.

Dolaznoj usluzi treba tunelska mreža koja se ne preklapa sa adresama odlaznog tunela ni sa bilo kojom privatnom mrežom koju uređaj rutira. Preklapanje je jedina greška koja istovremeno proizvodi simptome u obje uloge, i mnogo je jeftinije uhvatiti je na papiru. Uporedite oba bazena i svaku rutiranu privatnu mrežu na jednom mjestu prije nego što konfigurišete bilo koju od usluga.

Dijeljeni hardver ne znači dijeljene akreditive, a klijentski sertifikat iz bazena za udaljeni pristup ne treba da bude upotrebljiv prema provajderu izlaza. Odvojen materijal takođe pretvara opoziv u lokalnu odluku umjesto događaja na nivou cijele flote.

Zadržite odgovore servera na WAN putanji

Odgovori koje uređaj sam generiše prva su žrtva nepažljive podrazumijevane rute. Kada stigne enkapsulirani paket roaming korisnika, odgovor je lokalno nastali saobraćaj i mora izaći kroz interfejs kojim je taj korisnik došao. Ako je odlazni klijent instalirao podrazumijevanu rutu koja ga hvata, odgovor ulazi u pogrešan tunel i sesija staje dok usluga još izgleda zdrava.

Ne postoji jedno polje za potvrdu koje to rješava, jer odluka se odnosi na to koji saobraćaj odlazni klijent smije hvatati. Ili ne povlačite nikakve rute i usmjeravajte samo ono što odaberete, ili povucite rute i dodajte izuzetke koji drže vlastite usluge uređaja u pogonu. Zapišite izbor pored instance, inače će sljedeća osoba pretpostaviti onaj drugi.

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

Čitajte tabelu rutiranja po najdužem podudaranju, a ne po redoslijedu kojim ste bilo šta konfigurisali. Pitanje je koji zapis pobjedi za adresu partnera izlaza i koji zapis pobjedi za odgovor dolazne usluge, a ta dva odgovora se mogu razlikovati.

Ne dozvolite da odlazni tunel pojede vlastitu završnu tačku

Odlazni klijent mora doći do javne adrese svog partnera da bi uopšte uspostavio tunel. Ako je ta adresa sama rutirana u tunel, klijent juri vlastiti rep: transport se nikad ne podiže, ili se podigne pa padne u trenutku kada se ruta instalira. Dnevnik izgleda kao istek vremena za autentifikaciju, a ne kao greška rutiranja, zato ruta zaslužuje prvu provjeru.

Provjerite rutu prije akreditiva i ponovo nakon što tunel bude podignut, jer zapis može biti tačan pri podizanju i pogrešan minut kasnije. Adresa partnera mora pokazivati na običnu WAN putanju, nikada na tunelski uređaj. Kad se transport stabilizuje, zanimljivo pitanje prelazi na proslijeđeni saobraćaj, što je sljedeća odluka.

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

Odaberite koji korisnici dobijaju izlaz

Politika izvora pripada ulazu gdje saobraćaj ulazi u uređaj, zato odaberite bazen za udaljeni pristup ili uže identitete unutar njega. Sačuvajte privatne destinacije i izuzetke za upravljanje koji nikada ne smiju ići na izlaz, i postavite ta pravila prije širokog. Putanja izlaza zatim treba vlastito prevođenje ili rutirano povratno rješenje, što za većinu projekata znači odlazni NAT na izlaznom interfejsu koji pokriva bazen. Prevođenje ne bira izlaz; ono samo prepisuje ono što je već otišlo, pa NAT pravilo na nepovezanom WAN-u ne mijenja ništa u odabiru.

Potvrdite da udaljena strana dozvoljava proslijeđeni saobraćaj iz ovog projekta, jer neki provajderi dozvoljavaju a neki ne. Razlika se vidi kao tunel koji se poveže i ne nosi ništa, što je lako pročitati kao lokalnu grešku. Testirajte tri toka odvojeno, jer padaju nezavisno i dva od tri je napola izgrađen projekt.

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

Prva komanda je vanjska veza roaming korisnika i radi kada klijent izvijesti da je niz za inicijalizaciju završen. Druga, pokrenuta s tog povezanog laptopa, treba da izvijesti adresu provajdera izlaza umjesto vaše WAN adrese. Treća se izvršava na uređaju vezana za adresu iz bazena i provjerava politiku izvora za proslijeđeni saobraćaj bez ikakvog uključivanja udaljenog korisnika. Ako umjesto toga odgovori s WAN-a, politika se nije poklopila i nikakvo uređivanje NAT-a ne popravlja problem odabira.

Odlučite šta se dešava kada izlaz padne

Zapišite ponašanje pri kvaru prije nego što se dogodi: kada odlazni tunel padne, vraćaju li se korisnici na obični WAN ili su blokirani dok se izlaz ne vrati? Oba odgovora su odbranjiva, a uređaj neće odabrati umjesto vas. Uklonjena ruta ili politika koja pokazuje na mrtav gejtvej ne proizvode automatski rezultat potpune blokade. Ako želite blokadu, politika to mora izričito reći i mora se testirati oduzimanjem izlaza, a ne razmišljanjem o njemu. Ako želite vraćanje, objavite to korisnicima, jer saobraćaj koji tiho preuzme običnu putanju upravo je saobraćaj za koji je neko vjerovao da je pokriven.

Onemogućite klijentsku instancu, gledajte do čega povezani korisnik još može doći, pa je ponovo pokrenite. Zahtjev koji istekne po vremenu je rezultat potpune blokade koji ste tražili; onaj koji odgovori WAN adresom je vraćanje koje niste dokumentovali. Ponovite provjeru za IPv6 i za DNS, jer politika napisana za IPv4 ne govori ništa o AAAA saobraćaju, a resolver koji gurne bilo koji tunel odgovara odakle upit zaista izlazi.

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

Netgate recept za rutirani OpenVPN pokazuje kako se politika izvora, dodjela interfejsa i odlazno prevođenje uklapaju, a njegov obuhvat između lokacija je dio koji ne treba kopirati u cjelini. Ono što vam neće reći jeste koje je od tri uslova gore vaš vlastiti projekt već prekršio.