OpenVPN shtyn DNS, por zgjidhësi yt mund të mos e shohë kurrë

Regjistri i klientit tregon serverin DNS të shtyrë, tuneli është i lidhur dhe një emër i brendshëm ende nuk zgjidhet në asgjë. Në vetë dërgimin nuk ka asgjë të prishur. Opsioni mbërriti dhe zgjidhësi i sistemit operativ nuk e përdori kurrë, sepse në shumicën e klientëve Unix OpenVPN e dorëzon vlerën dhe e lë aplikacionin platformës.

Simptoma: regjistri tregon DNS dhe emrat ende dështojnë

OpenVPN dhcp-option mbart informacion DNS dhe domeni, dhe klienti regjistron atë që mori. Në disa implementime klienti i zbaton ato cilësime brenda; në të tjera i eksporton për një skript integrimi ose një shërbim rrjeti. Rreshti i regjistrit përshkruan vetëm gjysmën e parë të historisë. Gjysma e dytë ndodh diku ku klienti nuk kontrollon. Aty zakonisht jeton dështimi.

Kjo është arsyeja pse një tunel i lidhur dhe një emër i brendshëm që dështon bashkëjetojnë kaq shpesh. Vlera është aty, konsumatori mungon ose është konfiguruar gabimisht, dhe zgjidhësi vazhdon në heshtje të përdorë serverin publik që përdorte para lidhjes.

Marrja nuk është zbatimi

Një klient mund të regjistrojë një vlerë DNS të shtyrë ndërsa zgjidhësi i sistemit mbetet pronë e një shërbimi tjetër. Një shfletues mund të ketë gjithashtu politikën e vet të DNS të kriptuar që anashkalon plotësisht zgjidhësin e sistemit, çka krijon situatën e paharrueshme ku një aplikacion zgjidh emra të brendshëm dhe një tjetër jo.

Kontrollo integrimin e mbështetur të implementimit në vend që të supozosh se çdo klient Unix rishkruan të njëjtin skedar. Ky supozim është arsyeja pse njerëzit modifikojnë një konfigurim zgjidhësi që asgjë nuk e lexon.

Gjej pronarin e zgjidhësit për çdo platformë

Në Windows, tabela e politikës së zgjidhjes së emrave mund të drejtojë prapashtesa të caktuara drejt serverëve të caktuar, dhe klienti VPN mund të instalojë rregulla atje. Kontrollo politikën, jo vetëm listën DNS të përshtatësit. Në Linux, NetworkManager ose systemd-resolved mund të zotërojnë konfigurimin, dhe cili prej tyre e zotëron përcakton çfarë do të ruajë një rilidhje.

Lexo gjendjen efektive me mjetin që me të vërtetë u përgjigjet pyetjeve: resolvectl query internal.example.net në një host me systemd-resolved, ose ekuivalentin e platformës. Pastaj krahaso atë përgjigje me serverin DNS që regjistri i klientit pretendon se ka dërguar.

Shmang ekzekutimin e disa shërbimeve që mbishkruajnë cilësimet e zgjidhësit pa koordinim. Dy pronarë prodhojnë një rezultat që duket i ndërprerë, dhe çdo rilidhje duket se e rregullon ose e prish atë rastësisht.

Skriptet dhe foreign_option

OpenVPN eksporton opsionet e shtyra te skriptet përmes variablave të quajtur foreign_option_N, dhe një skript mund t'i përkthejë ato në komanda zgjidhësi. Ky rregullim është integrim i mbështetur, jo sjellje automatike, dhe duhet të instalohet e të thirret në klient.

Nëse mbështetesh te një skript, regjistro ekzekutimin dhe statusin e daljes. Një skript që ekzekutohet por dështon në heshtje lë të njëjtin simptom si pa skript, dhe është më e vështirë ta vësh re sepse konfigurimi duket i plotë. Kontrollo daljen e skriptit, jo skedarin e skriptit. Një skedar që ekziston nuk është skript që ka ekzekutuar.

Testo emrin, jo regjistrin

Pas lidhjes pyet klientin për një emër hosti vetëm të brendshëm, pastaj pyet për një emër publik, pastaj kontrollo cili server u përgjigj. Në një konfigurim që funksionon, dy përgjigjet vijnë nga vende të ndryshme, dhe të dyja duhet të përputhen me projektin.

Nëse emri zgjidhet por shërbimi dështon, kalo te rrugëtimi dhe aksesi i aplikacioneve në vend që të ndryshosh përsëri DNS. Manuali i OpenVPN dokumenton dhcp-option dhe mjedisin e skripteve; përdore për të konfirmuar çfarë pritet të zbatojë klienti yt përpara se të modifikosh një skedar tjetër zgjidhësi.