E njëjta IP serveri, dy rrugë: shënjimi i rrjedhës së jashtme të OpenVPN

Mbrojtja e zakonshme nga cikli është një rrugë pritësi: dërgoni trafikun drejt adresës publike të serverit VPN përmes uplink-ut, që sesioni i kriptuar të mos hyjë kurrë në tunelin e vet. Kjo funksionon deri në momentin kur doni të arrini përmes tunelit edhe një shërbim web në të njëjtin server, sepse përjashtimi lidhet me destinacionin dhe destinacioni është i njëjtë. Rruga e daljes është të ndaloni klasifikimin sipas destinacionit dhe të filloni të klasifikoni sipas asaj se cili socket e dërgoi paketën.

Filloni me dy rrjedhat që doni të ndani

Një rrjedhë është vetë transporti i kriptuar OpenVPN, i cili duhet të dalë përmes uplink-ut, përndryshe tuneli do të mbante lidhjen e vet të jashtme. Tjetra është një kërkesë e zakonshme HTTPS drejt të njëjtës adresë publike, që e doni brenda tunelit, që të arrijë te shërbimi nga një burim tuneli. I njëjti destinacion, në shumë raste i njëjti numër porte, rrugë tjetër e nevojshme.

Për këtë përshkrim, supozoni një klient në 10.90.0.10 përmes tun1, një adresë publike serveri 198.51.100.25 dhe një tabelë kryesore të paprekur, rruga e paracaktuar e së cilës tregon uplink-un e zakonshëm. Ana e serverit duhet gjithashtu ta pranojë shërbimin web në rrugën e brendshme dhe ta kthejë trafikun te burimi i tunelit; dërgimi i një pakete në një adresë publike nuk e anulon dëgjuesin ose politikën e firewall-it të serverit.

Përpara se të ndryshoni ndonjë gjë, regjistroni rregullat aktuale të pritësit dhe zgjidhni vlera që askush tjetër nuk i përdor: një shenjë, një numër tabele dhe tre përparësi rregulli. Mbani një rrugë kthimi në makinë që nuk kalon përmes kësaj lidhjeje, sepse një gabim këtu ju heq aksesin tuaj në distancë, jo thjesht prish një skedë të shfletuesit.

Shënoni socketin që mbart zarfin

Konfigurimi i klientit merr një shenjë për paketat e tij të kriptuara në dalje dhe ndalon instalimin e rrugëve vetë, kështu që politika e zëvendësimit është e vetmja që vendos për rrugët:

mark 42
route-noexec
disable-dco

Dhjetorja 42 është heksadecimalja 0x2a, dhe forma heksadecimal është ajo me të cilën do të përputhen rregullat e rrugëzimit. Referenca e link-options e përshkruan mark si diçka që zbatohet për paketat e kriptuara në dalje në Linux, që është pikërisht socketi rrugën e të cilit duhet të kontrolloni. Çaktivizimi i shkarkimit të kanalit të të dhënave e mban këtë shembull në rrugën e hapësirës së përdoruesit, ku sjellja e shenjës është ajo e përshkruara.

route-noexec i shtyp shtesat dhe heqjet automatike të rrugëve nga OpenVPN. Nuk instalon asgjë në vend të tyre, prandaj nga ky moment pronari i rrugëve duhet të mirëmbajë çdo rrugë që i nevojitet tunelit. Nëse një destinacion privat zhduket pas ndryshimit, kjo është politika e zëvendësimit që mungon, jo një defekt në shenjë.

Mos mbani një rrugë pritësi në tabelën kryesore për 198.51.100.25 ndërsa e bëni këtë. Një rrugë e tillë e rifut pikërisht përjashtimin që dizajni po përpiqet ta ngushtojë, dhe do të fitojë për rrjedhën HTTPS përpara se të konsultohet ndonjë nga politikat më poshtë.

Dërgoni çdo gjë tjetër në tabelën e tunelit

Sapo ndërfaqja e tunelit ekziston dhe mban adresën e saj, politika duket kështu:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

Rregulli i parë i mban të dukshme rrugët specifike të pritësit, përfshirë çdo rrjet lokal të miratuar, ndërsa e bën të padukshme rrugën e paracaktuar të tabelës kryesore për këtë kërkim. Ky dallim ka rëndësi: shtypja e rrugës së paracaktuar nuk është e njëjtë me injorimin e tabelës, dhe përjashtimet lokale që ju duhen ende mbijetojnë pikërisht për shkak të saj. Lexoni ato përjashtime një nga një, në vend që të supozoni se rezultati është një çelës ndalimi universal.

Trafiku i pashënuar pastaj bie në tabelën e tunelit, merr burimin e tunelit dhe del përmes VPN-së. Trafiku i shënuar dështon në testin fwmark në dy rregullat e ardhshme dhe vazhdon te kërkimi kryesor i zakonshëm më poshtë në listë, ku ende ndodhet rruga e paracaktuar e uplink-ut. Rregulli përfundimtar unreachable është ai që e pengon një rrjedhë të pashënuar të bjerë në heshtje përsëri në uplink kur mungon rruga e tunelit. Përzgjedhësi është shenja nga fillimi në fund, dhe adresa e destinacionit nuk hyn kurrë në vendim.

Mbajeni atë roje në vend ndërmjet shkëputjeve dhe instalojeni bashkë me pjesën tjetër të politikës, jo me dorë. Një rregull që zhduket me ndërfaqen nuk është politikë, është rastësi. Fshirja e politikës kur tuneli bie e ndryshon mënyrën e dështimit nga “bllokuar” në “rrjedhur”, dhe një rrugë e vjetruar e tunelit që skadon më vonë është një problem shumë më i lehtë për t'u shpjeguar sesa trafiku që doli përmes ndërfaqes së gabuar.

Lëreni rrugën e kthimit të shohë të njëjtën shenjë

Shenjat në dalje janë vetëm gjysma e mekanizmit, dhe kjo është pjesa që shumica e riprodhimeve e lënë jashtë. Përgjigjet për sesionin e kriptuar mbërrijnë përmes uplink-ut dhe i nënshtrohen validimit të rrugës së kthimit, i cili pyet nëse burimi do të rrugëzohej mbrapsht në të njëjtën rrugë. Pa ndihmë, ai kërkim zbaton politikën tuaj të pashënuar të tunelit dhe arrin në përfundimin se paketa është në ndërfaqen e gabuar.

Rregullimi i takon pronarit të firewall-it: ruani shenjën në lidhjen në dalje, rivendoseni atë në paketat hyrëse që përputhen dhe aktivizoni trajtimin e shenjave të validuara nga burimi për rrugën përkatëse. Fakti që OpenVPN vendos një shenjë socketi nuk bën asnjë nga këto tre gjëra, dhe një recetë që rendit vetëm opsionet e klientit është e paplotë. Kërkoni atë integrim me shkrim, sepse është pjesa më pak e dukshme e dizajnit dhe më e lehta për t'u humbur në një rindërtim.

As verifikimi i lirshëm i rrugës së kthimit nuk është zëvendësim. Modaliteti i lirshëm kërkon ende që të ekzistojë një rrugë për burimin, dhe roja unreachable që shtuat e heq qëllimisht një për kërkimet e pashënuara. Përfundoni dhe rishikoni integrimin e shenjës së lidhjes përpara se të mbështeteni në këtë dizajn, dhe trajtojini filtrat e pritësit si një çështje më vete: shenja është sinjal rrugëzimi, jo leje. Nëse integrimi mungon, simptomi është një sesion që vendoset dhe pastaj hesht sapo fillojnë të mbërrijnë përgjigjet.

Vërtetojeni me dy kërkime rrugësh

Krahasoni çfarë vendos kerneli për dy kontekstet, dhe lexoni fushat dev dhe src në vend të statusit të daljes:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

Kërkimi i parë duhet të zgjidhet në tun1 me burimin e tunelit, dhe i dyti në uplink. Këto janë kërkime sintetike, prandaj vërtetojnë politikën dhe jo procesin që punon: konfirmoni veçmas rrugën reale të transportit të klientit që punon, pastaj bëni një kërkesë reale HTTPS me verifikimin e certifikatës të ndezur.

Shkruani çka nuk mbulon dizajni përpara se ta shpallni të përfunduar. DNS, IPv6 dhe cikli i jetës së rregullave kërkojnë secila vendimin e vet, dhe ky është një shembull rrugëzimi IPv4, jo një konfigurim i plotë privatësie. Vlera e tij është përzgjedhësi: zarfi merr përjashtimin e uplink-ut, dhe një shërbim i zakonshëm në të njëjtën adresë nuk duhet ta trashëgojë atë.