pfSense si server dhe klient VPN: dy rrugë, një router

Një pajisje mund të shikojë në dy drejtime njëherësh: përdoruesit nomadë lidhen brenda, dhe e njëjta kuti lidhet jashtë me një ofrues daljeje që trafiku i zgjedhur të dalë përmes një rrjeti tjetër. Aktivizimi i të dy shërbimeve merr minuta; bashkëjetesa e tyre kërkon një projekt, sepse roli i dytë rishkruan tabelën e rrugëtimit nga e cila varet i pari. Tri kushte vendosin nëse rregullimi funksionon, domethënë nëse shërbimi hyrës ruan rrugën e vet të kthimit, nëse tuneli dalës ende arrin partnerin e tij dhe nëse trafiku që kishit ndërmend të përcillnit zgjidhet për daljen. Gabo njërën dhe merr dy tunele që të dy raportojnë të lidhur ndërsa asgjë e dobishme nuk kalon mes tyre. Kontrollet më poshtë vendosin çdo kusht në rendin në të cilin dështimet zakonisht shfaqen.

Emërtoni dy rolet para se të prekni çdo cilësim

Shkruani katër fakte për çdo instancë: partnerin e saj të largët, materialin e vërtetimit, grupin e adresave që shpërndan dhe rrjetet prapa tij. Dy instancat janë objekte të veçanta në pajisje dhe duhet të mbeten të veçanta edhe në shënimet tuaja. Pothuajse çdo simptomë konfuze më vonë vjen nga përzierja e vlerave të tyre, dhe dy instanca që ndajnë një grup shënimesh është mënyra se si grupi i gabuar përfundon në fushën e gabuar.

Shërbimi hyrës ka nevojë për një rrjet tuneli që nuk mbivendoset me adresat e tunelit dalës ose me çdo rrjet privat që pajisja rrugëton. Mbivendosja është gabimi i vetëm që prodhon simptoma në të dy rolet njëherësh, dhe është shumë më lirë ta kapësh në letër. Krahasoni të dy grupet dhe çdo rrjet privat të rrugëtuar në një vend përpara se të konfiguroni cilindo nga shërbimet.

Hardueri i përbashkët nuk nënkupton kredenciale të përbashkëta, dhe një certifikatë klienti nga grupi i aksesit në distancë nuk duhet të jetë e përdorshme kundër ofruesit të daljes. Materiali i veçantë e kthen edhe revokimin në vendim lokal në vend të një ngjarjeje për të gjithë flotën.

Mbajini përgjigjet e serverit në rrugën WAN

Përgjigjet që pajisja gjeneron vetë janë viktima e parë e një rruge të paracaktuar të pakujdesshme. Kur mbërrin paketa e inkapsuluar e një përdoruesi nomad, përgjigja është trafik i krijuar lokalisht dhe duhet të dalë përmes ndërfaqes nga e cila hyri ai përdorues. Nëse klienti dalës ka instaluar një rrugë të paracaktuar që e kap atë, përgjigja hyn në tunelin e gabuar dhe sesioni ngec ndërsa shërbimi ende duket i shëndoshë.

Nuk ka një kuti të vetme shenjimi që e zgjidh këtë, sepse vendimi ka të bëjë me atë se çfarë trafiku klienti dalës mund të kapë. Ose nuk tërhiqni asnjë rrugë dhe drejtoni vetëm atë që zgjidhni, ose tërhiqni rrugë dhe shtoni përjashtimet që i mbajnë shërbimet e vetë pajisjes në punë. Shkruani zgjedhjen pranë instancës, përndryshe personi tjetër do të supozojë tjetrën.

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

Lexoni tabelën e rrugëtimit sipas përputhjes më të gjatë dhe jo sipas rendit në të cilin keni konfiguruar diçka. Pyetja është cila hyrje fiton për adresën e partnerit dalës dhe cila hyrje fiton për përgjigjen e shërbimit hyrës, dhe këto dy përgjigje mund të ndryshojnë.

Mos lejoni që tuneli dalës të hajë pikën e vet terminale

Klienti dalës duhet të arrijë adresën publike të partnerit të tij që të krijojë fare tunelin. Nëse ajo adresë rrugëtohet vetë brenda tunelit, klienti ndjek bishtin e vet: transporti nuk ngrihet kurrë, ose ngrihet dhe bie në momentin kur instalohet rruga. Regjistri duket si skadim i vërtetimit dhe jo si defekt rrugëtimi, prandaj rruga meriton kontrollin e parë.

Kontrolloni rrugën para kredencialeve dhe përsëri pasi tuneli të jetë ngritur, sepse një hyrje mund të jetë e saktë në nisje dhe e gabuar një minutë më vonë. Adresa e partnerit duhet të tregojë rrugën e zakonshme WAN, kurrë pajisjen e tunelit. Kur transporti stabilizohet, pyetja interesante kalon te trafiku i përcjellë, që është vendimi i radhës.

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

Zgjidhni cilët përdorues marrin daljen

Politika e burimit i përket hyrjes ku trafiku hyn në pajisje, prandaj zgjidhni grupin e aksesit në distancë, ose identitete më të ngushta brenda tij. Ruani destinacionet private dhe përjashtimet e menaxhimit që nuk duhet të dërgohen kurrë në dalje, dhe vendosni ato rregulla para asaj të gjerë. Rruga e daljes pastaj ka nevojë për përkthimin e vet ose një rregullim kthimi të rrugëtuar, që për shumicën e projekteve do të thotë NAT dalës në ndërfaqen e daljes që mbulon grupin. Përkthimi nuk zgjedh një dalje; ai rishkruan vetëm atë që ka dalë tashmë, prandaj një rregull NAT në një WAN të palidhur nuk ndryshon asgjë në zgjedhje.

Konfirmoni që skaji i largët lejon trafikun e përcjellë nga ky projekt, sepse disa ofrues e lejojnë dhe disa jo. Diferenca shfaqet si një tunel që lidhet dhe nuk mbart asgjë, gjë që lexohet lehtë si defekt lokal. Testoni tre rrjedhat veçmas, sepse dështojnë në mënyrë të pavarur, dhe dy nga tre është një projekt gjysmë i ndërtuar.

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

Komanda e parë është lidhja e jashtme e përdoruesit nomad, dhe funksionon kur klienti raporton se sekuenca e inicializimit ka përfunduar. E dyta, e ekzekutuar nga ai laptop i lidhur, duhet të raportojë adresën e ofruesit të daljes në vend të adresës tuaj WAN. E treta ekzekutohet në pajisje e lidhur me një adresë nga grupi, dhe teston politikën e burimit për trafikun e përcjellë pa përfshirë fare një përdorues të largët. Nëse përkundrazi përgjigjet nga WAN, politika nuk u përputh, dhe asnjë sasi redaktimi NAT nuk rregullon një problem zgjedhjeje.

Vendosni çfarë ndodh kur dalja dështon

Shkruani sjelljen në dështim para se të ndodhë: kur tuneli dalës bie, përdoruesit kthehen në WAN-in e zakonshëm apo bllokohen derisa dalja të kthehet? Të dyja përgjigjet janë të mbrojtshme, dhe pajisja nuk do të zgjedhë në vendin tuaj. Një rrugë e hequr ose një politikë që tregon një portë të vdekur nuk prodhojnë automatikisht një rezultat plotësisht të bllokuar. Nëse doni bllokim, politika duhet ta thotë shprehimisht, dhe duhet testuar duke hequr daljen dhe jo duke menduar për të. Nëse doni kthim, shpalleni atë për përdoruesit, sepse trafiku që merr në heshtje rrugën e zakonshme është pikërisht trafiku që dikush mendonte se ishte i mbuluar.

Çaktivizoni instancën e klientit, shikoni çfarë arrin ende një përdorues i lidhur, pastaj rinisni atë. Një kërkesë që skadon është rezultati plotësisht i bllokuar që kërkuat; ajo që përgjigjet me adresën WAN është kthimi që nuk e dokumentuat. Përsëritni kontrollin për IPv6 dhe për DNS, sepse një politikë e shkruar për IPv4 nuk thotë asgjë për trafikun AAAA dhe një zgjidhës i shtyrë nga cilido tunel përgjigjet nga aty ku kërkesa me të vërtetë del.

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

Receta e Netgate për OpenVPN të rrugëtuar tregon se si politika e burimit, caktimi i ndërfaqes dhe përkthimi dalës përshtaten së bashku, dhe shtrirja e saj nga sajti në sajt është pjesa që nuk duhet kopjuar e tëra. Ajo që nuk do t'ju thotë është cila nga tri kushtet më sipër është thyer tashmë nga projekti juaj.