Një Pi, dy instanca OpenVPN: çfarë lexon secila njësi

Numëroni proceset OpenVPN përpara se të prekni një profil. Një Pi që pranon përdorues roaming dhe njëkohësisht lidhet me një shërbim të mësipërm ekzekuton dy demonë, dhe secili lexon një skedar konfigurimi të zgjedhur nga emri i instancës që shtypët. Modelet e paketës pastaj i japin secilit demon direktorinë e vet të punës, skedarin e vet të gjendjes së ekzekutimit dhe pajisjen e vet të tunelit. Nëse këtë ndarje e bëni gabim, do të kaloni një mbrëmje duke ndryshuar një cilësim të saktë brenda një skedari që procesi në punë nuk e hap kurrë.

Çdo emër instance zgjedh skedarin e vet

Në skedarët e njësisë që vijnë me OpenVPN 2.6, argumentet e nisjes mbajnë një vendmbajtës instance që mbushet me tekstin pas shenjës @. Modeli i serverit ekzekutohet nga direktoria e konfigurimit të serverit dhe zgjidh argumentin e vet ndaj %i.conf atje, ndërsa modeli i klientit bën të njëjtën gjë nga direktoria e klientit. Pra [email protected] lexon admits.conf në direktorinë e serverit dhe [email protected] lexon uplink.conf në direktorinë e klientit, dhe asnjëri prej këtyre emrave nuk ka ndonjë kuptim në direktorinë tjetër.

Verifikoni hartëzimin në makinë në vend që të supozoni se paketa ka mbajtur vlerat e parazgjedhura. Një drop-in i shpërndarjes mund të zëvendësojë plotësisht direktorinë e punës ose argumentin e konfigurimit.

systemctl cat [email protected]
systemctl cat [email protected]

Lexoni rreshtin WorkingDirectory dhe argumentin e konfigurimit në atë dalje, sepse vetëm njësia e aktivizuar vendos cili skedar ngarkohet. Një drop-in që shton --config në ExecStart fiton mbi modelin edhe kur rruga e modelit duket e saktë. Kërkoni rrugët e fragmenteve dhe të drop-in-ave kur doni të dini nëse është në lojë një mbivendosje lokale. Nëse të dy rolet zgjidhen në një skedar të vetëm, keni një proces të vetëm që përpiqet të jetë edhe server edhe klient, dhe opsioni i mëvonshëm në atë skedar fiton në heshtje.

Transporti lokal dhe ngarkesa e ridrejtuar nuk përputhen me të njëjtat grepa

Lidhja e kriptuar e serverit me çdo përdorues roaming krijohet në vetë Pi-n, kështu që përgjigjet e saj të jashtme dalin përmes grepës lokale të daljes. Lidhja e klientit me partnerin e tij të mësipërm është gjithashtu dalje e krijuar lokalisht, edhe pse arrin një rrjet të largët. Ngarkesa e ridrejtuar është kategoria e tretë, dhe kerneli e përputh atë vetëm pasi ka zgjedhur tashmë një pajisje dalëse për paketën.

Një rregull që përputh një ndërfaqe dalëse brenda një zinxhiri forward mund të lejojë ose të hedhë poshtë një paketë që rrugëtimi ia ka caktuar tashmë asaj ndërfaqeje, por nuk e zgjedh kurrë ndërfaqen. Kur një host përfundon një tunel dhe nis një tjetër, politika që dërgon ngarkesën e përdoruesve në tunelin e mësipërm dhe politika që mbron përgjigjet e kriptuara të vetë Pi-t janë dy vendime të ndara. Ato përfundojnë rastësisht në të njëjtën NIC fizike, prandaj ngatërrohen.

Ky dallim shpjegon një dështim të gjysmës të zakonshëm. Përdoruesit lidhen, handshake përfundon, dhe trafiku i tyre prapë del në rrugën e gabuar, sepse handshake ishte lokal dhe ngarkesa ishte forward dhe vetëm njëra nga të dyja ishte testuar ndonjëherë.

Një rrugë e importuar mund të gëlltisë përgjigjet për përdoruesit tuaj

Cilësimi i sigurisë i profilit të klientit vendos çfarë mund të shtyjë ana e mësipërme në tabelën e rrugëtimit të Pi-t, dhe një ridrejtim i gjerë është opsioni që e kthen një host funksional me dy role në një të prishur. Nëse rruga e shtyrë mbulon adresat publike të përdoruesve roaming, përgjigjet që serveri gjeneron drejt tyre mund të ndjekin rrugën e re në tunelin e mësipërm në vend që të dalin përmes shtresës bazë. Njerëzit shpesh verifikojnë se tuneli drejt ofruesit ende funksionon dhe ndalen aty, sepse ai trafik është transporti i vetë tunelit dhe vazhdon të rrjedhë ndërsa gjithçka tjetër sillet gabim.

Politika e bazuar në burim ose në mark është mënyra si dy rrjedhat mbeten të ndara. Opsioni mark i Linux-it në OpenVPN shënon paketat e kriptuara të vetë demonit me një mark firewalls, të cilin një rregull rrugëtimi mund ta dërgojë më pas në një tabelë të dedikuar. Adresat burimore funksionojnë po aq mirë kur përgjigjet e jashtme të serverit dalin gjithmonë nga një adresë e vetme bazë. Të dyja qasjet kanë nevojë për rrugë të vlefshme në tabelën që zgjedhin dhe një përjashtim për endpoint-in e ofruesit, përndryshe vetë tuneli nuk ngrihet më.

Pyetni kernelin se cilën rrugë do të merrte vërtet një përgjigje përpara se të shkruani çdo rregull. Adresat më poshtë janë vendmbajtës për një adresë bazë të Pi-t dhe adresën publike të një përdoruesi roaming.

ip rule show
ip route get 198.51.100.7 from 192.0.2.10

Verifikoni ndarjen, pastaj ndaloni një rol në një herë

Provoni tre rrjedhat veçmas, sepse një handshake që funksionon nuk provon asgjë për dy të tjerat. Pranoni një lidhje të re hyrëse, dërgoni një aplikacion të lejuar përmes daljes së mësipërme dhe konfirmoni se të dy proceset ende arrijnë partnerët e tyre.

Pastaj ndaloni rolin e klientit dhe vëzhgoni çfarë mban roli i serverit. Kjo është mënyra më e lirë për të gjetur një rregull rruge ose mark që ishte menduar për një instancë dhe është zbatuar për të dyja.

systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pager

Ajo që doni të shihni është dëgjuesi ende i lidhur, pajisja e tunelit ende e pranishme dhe regjistri pa gabime të reja ndërsa roli i klientit është i ndalur. Nëse ndalimi i klientit pret edhe përgjigjet e serverit për përdoruesit ekzistues, dy rolet ndajnë diçka që duhej të ishte kufizuar vetëm në njërën prej tyre. Shënoni cila instancë, cili skedar konfigurimi dhe cili pronar i rrjedhës u prek nga çdo ndryshim, sepse personi tjetër që do të korrigjojë këtë host përndryshe do të përsëritë të njëjtin zbulim nga zeroja.