Çfarë ndalon në të vërtetë route-nopull i OpenVPN që serveri të shtyjë

E vendosët route-nopull në një profil klienti për të ndaluar tunelin të gëlltisë rrugën tuaj të paracaktuar, dhe tani nënrrjeti i zyrës është i paarritshëm ndërsa klienti vazhdon të thotë se është i lidhur. Të dyja vëzhgimet janë të vërteta, dhe asgjë nuk ka dështuar. Flamuri i thotë klientit të anashkalojë rrugët dhe zërat DHCP që serveri shtyn, një udhëzim më i ngushtë nga sa presin shumica kur e shtojnë. Ajo që mbetet është një tunel funksional pa mendim për atë se cilat destinacione duhet ta përdorin.

Ai boshllëk është i gjithë vendimi për të cilin është ky artikull. Ose serveri përshkruan rrjetin, ose klienti, dhe flamuri ia dorëzon atë punë klientit pa bërë asgjë prej saj për ju.

Çfarë fik flamuri në momentin e lidhjes

Një klient OpenVPN që tërheq normalisht merr nga serveri pas vërtetimit një pako: rrugë, një ridrejtim të portës së paracaktuar, serverë DNS dhe disa direktiva akordimi. Me route-nopull në fuqi klienti vazhdon të pranojë sesionin, vazhdon të verifikojë certifikatat, vazhdon të negociojë shifrat dhe keepalive, dhe vazhdon të ngrejë ndërfaqen. Ajo që hedh poshtë është zbatimi i rreshtave route të shtyra dhe i rreshtave dhcp-option të shtyra, DNS përfshirë.

Konfuzioni vjen nga një tregues i gjelbër pranë një aplikacioni të vdekur. Tuneli ekziston; pasqyrimi i destinacioneve në atë tunel nuk ekziston. Asgjë në panelin e statusit të klientit nuk dallon «i lidhur dhe rrugëton» nga «i lidhur dhe joaktiv», sepse nga këndvështrimi i tunelit të dyja janë i njëjti gjendje.

Pse një tunel i gjallë mund të mos rrugëtojë asgjë

Ndërfaqja shfaqet me adresën e vet dhe, në një lidhje pikë-për-pikë, shpesh nuk ka asgjë më të veçantë sesa një rrugë hosti drejt partnerit. Një nënrrjet privat bëhet i arritshëm vetëm kur një rrugë me prefiksin e duhur tregon drejt asaj ndërfaqeje, dhe me shtyrjen e fikur ajo rrugë nuk vjen kurrë. Profili i shkarkuar gjithashtu zakonisht nuk mund të ndihmojë, sepse është shkruar duke supozuar se serveri do të furnizonte pikërisht këtë informacion. Kjo është arsyeja pse ndërfaqja mund të duket e shëndetshme ndërsa nënrrjeti mbetet i errët.

Leximi i profilit, pra, dëshmon shumë pak. Lexoni gjendjen në punë, në makinën e lidhur:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Një adresë pa rrugë nënrrjeti në komandën e dytë është nënshkrimi i këtij problemi. Komanda e tretë pastaj përgjigjet pyetjes që u intereson vërtet përdoruesve, sepse raporton ndërfaqen që bërthama do të zgjidhte për një destinacion të caktuar në vend të listës që shpresonit se do të përdorte. Nëse përgjigjet përmes lidhjes tuaj fizike, tuneli nuk është fare në rrugë.

Zgjidhja e emrave dështon për një arsye të lidhur, jo për një të veçantë. Zërat dhcp-option DNS të shtyra anashkalohen nga i njëjti flamur, kështu që pyetësorët për hostet e brendshme shkojnë te çdo zgjidhës që ka ofruar rrjeti lokal. Ai zgjidhës nuk ka zonë për zyrën, kështu që pyetësori dështon ose kthen një përgjigje publike, dhe dështimi duket si problem serveri ndërsa është problem konfigurimi i klientit. Testimi i adresës para emrit është ajo që i ndan të dyja.

Zgjedhja midis flamurit dhe një filtri prefiksi

Të dyja opsionet zgjidhin forma të ndryshme të së njëjtës ankesë, dhe zgjedhja e keqe është ajo që prodhon gjendjen i lidhur-por-i padobishëm. Njëri zëvendëson plotësisht politikën e shtyrë, tjetri e redakton sipas prefiksit. Tabela jep versionin e shkurtër, dhe paragrafi pas saj mbulon pjesën që i kap njerëzit.

pull-filter është një përputhës prefiksesh me tre folje, kështu që mund të pranojë një familje rreshtash, t'i injorojë në heshtje ose ta refuzojë lidhjen plotësisht kur shfaqet një prefiks. Pikërisht sjellja e fundit ia vlen të njihet: një rregull refuzimi e kthen një mosmarrëveshje politike në një shtrëngim duarsh të dështuar në vend të një heqjeje të heshtur. Manuali i OpenVPN 2.6 rendit prefikset e pranuara dhe semantikën e saktë të secilës folje.

Një rrugë e mesme e zakonshme është të refuzohet vetëm redirect-gateway dhe të lihen rrugët e zyrës dhe DNS të vijnë siç është menduar. Kjo e mban shtyrjen funksionale për pjesët që serveri i kupton më mirë se ju, duke parandaluar njëkohësisht atë rreshtin e vetëm që do të merrte rrugën tuaj të paracaktuar.

Shtimi i rrugëve dhe një zgjidhësi me dorë

Nëse e mbani flamurin, profili duhet të thotë atë që do të kishte thënë serveri. Direktivat route në anën e klientit zbatohen pasi lidhja është vendosur, kështu që ato funksionojnë së bashku me flamurin në vend që të bllokohen prej tij. Vendosini në profil, jo në një rresht komandash interaktiv, përndryshe lidhja e ardhshme nuk do të riprodhojë gjendjen funksionale.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

Rreshti DNS ndodhet në një pozicion të sikletshëm: është direktivë në anën e klientit, por disa klientë e zbatojnë vetëm përmes integrimit DNS të platformës, i cili mund ta mbishkruajë kur lidhja ndryshon. Në një host systemd, vendosja e zgjidhësit drejtpërdrejt në ndërfaqen e tunelit është më e parashikueshme sesa shpresa që klienti të fitojë garën e prioriteteve:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Domeni i rrugëtimit ka po aq rëndësi sa adresa. Pa atë, pyetësorët për emra publikë mund të dërgohen edhe te zgjidhësi i brendshëm, dhe çdo zgjidhës i brendshëm që refuzon rekursionin do të prishë shfletimin ndërsa zona private vazhdon të punojë. Me atë, vetëm emrat nën atë prapashtesë rrugëtohen te zgjidhësi i tunelit dhe gjithçka tjetër ndjek lidhjen fizike.

Verifikimi i rezultatit: adresa, emri dhe rruga e jashtme

Tre teste i ndajnë dështimet e mundshme. Merrni adresën private me IP, pastaj të njëjtin host me emër, pastaj një sajt publik të zakonshëm. Një IP që punon me një emër që dështon tregon zgjidhësin; një IP që dështon me një emër që punon tregon rrugëtimin; dështimi i të dyjave zakonisht do të thotë që tuneli nuk është në rrugë.

Pastaj shikoni nga jashtë, jo nga brenda. Rruga e vetë pikës fundore të tunelit duhet t'i mbijetojë ndryshimit, dhe çdo dështim bllokues duhet të kufizohet te tuneli pa kapur pikën fundore. Një klient që vazhdon të shfletuar pasi tuneli bie është problem politike, jo rrugëtimi, dhe nuk do të shfaqet në asnjë nga tre testet më lart.

Shkruani listën përfundimtare në dokumentacionin e profilit: rrugët, zgjidhësin, domenet dhe arsyen pse ekziston secili. Një rilidhje që riprodhon të njëjtën tabelë është e vetmja provë se politika lokale është e plotë. Nëse aplikacionet vazhdojnë të dështojnë me tunelin lart dhe të tre testet e kaluara, vendi tjetër për të shikuar është klasa e problemeve i lidhur-por-jashtë linje, jo certifikatat që tashmë janë verifikuar.