OpenVPN je poslao DNS server, ali Linux ga ignorira

Poslani DNS server je u logu, tunel je podignut, a interna imena i dalje ne rade. U samom slanju ništa nije pokvareno; postavka je stigla i tu se zaustavila. Poslana DNS opcija je poruka klijentu, a ne uputa rezolveru operativnog sistema, i upravo je prijenos između njih mjesto gdje završava većina ovakvih slučajeva. Pet provjera, po redu, pronalazi prijenos koji se nije dogodio.

Provjera prva: kako konekcija počinje

Vlasnik konekcije određuje ko može primijeniti postavke rezolvera. Direktna openvpn komanda iz ljuske ne posjeduje ništa osim vlastitog procesa, dok systemd jedinica, NetworkManager ili klijent dobavljača svaki ima svoj način objavljivanja DNS-a. Pročitajte listu procesa i naziv jedinice prije nego pretpostavite bilo šta od toga.

Proces iz komandne linije nije automatski NetworkManager konekcija, a NetworkManager konekcija nije automatski ono što je napisalo resolv.conf. Te dvije pretpostavke objašnjavaju većinu izgubljenih sati u ovoj istrazi. Pitajte koja bi komponenta objavila DNS za interfejs koji zaista vidite.

Zapišite vlasnika prije nego nastavite. Svaka kasnija provjera zavisi od toga.

Provjera druga: šta veza rezolvera zapravo drži

Na systemd-resolved hostu resolvectl status ispisuje svaku vezu s njenim DNS serverima i domenima. Nađite vezu tunela i pročitajte njene unose, i ne pretpostavljajte da se interfejs zove tun0, jer numeracija slijedi red nastanka. Ako poslana adresa nije na vezi, prijenos je zakazao, a ne upit.

Ako je adresa prisutna, sljedeće pitanje je koje domene ta veza polaže pravo. Veza bez liste domena odgovara samo na imena o kojima se pita direktno, a to je rijetko ono što split-DNS implementacija želi. Sama adresa je neophodna, ali nije dovoljna.

Uporedite naziv veze u izlazu rezolvera s nazivom interfejsa u VPN logu prije nego donesete bilo kakav zaključak. Nesklad tamo obično znači da je linija loga došla iz drugog procesa.

Provjera treća: da li imenski prostor bira tu vezu

Rezolver može držati ispravan server i opet ne biti konsultovan. Domen po vezi odlučuje koji upiti idu na koju vezu, a bez rutirajućeg domena privatni imenski prostor pada natrag na ono što kaže zadana veza. Zato resolvectl query za interno ime može uspjeti dok aplikacija i dalje ne radi. Aplikacija može koristiti sasvim drugu putanju rezolvera.

Provjerite dodjelu domena, ne samo adresu servera. Domen napisan kao ~corp.example je rutirajući domen, a tilda mijenja način podudaranja imena.

Ako aplikacija ima vlastiti rezolver, testirajte istim mehanizmom koji ona koristi, a ne sistemskim alatom. Alat za upite koji zaobilazi sistemski rezolver uspjet će bez obzira na stanje veze.

Provjera četvrta: jedan vlasnik, a ne dva

Ako NetworkManager već upravlja VPN-om i stanjem rezolvera, dodavanje nepovezane hook skripte stvara suparničke pisce. Hook koji paket pruža za systemd-resolved je podržana integracija i očekuje određen životni ciklus: script-security 2, up putanju, up-restart, down putanju i down-pre. Te opcije čine da se registracija i uklanjanje dogode u pravim trenucima, a ne samo pri prvoj konekciji.

Koristite instaliranu putanju iz paketa, a ne ilustrativnu kopiranu iz vodiča. Dozvole su također važne, jer se hook izvršava nakon spuštanja privilegija.

Uređivanje skripte rezolvera distribucije da bi se promijenila njena izlazna meta bilježi zaobilazno rješenje jednog hosta. To nije opća popravka.

Provjera peta: isti rezultat nakon ponovnog spajanja

Ponovo se spojite i ponovo pročitajte vezu. Registracija koja se pojavi jednom i nestane pri sljedećem prijelazu je kvar zbog kojeg i postoji cijela ova kontrolna lista. Testirajte nakon suspenzije, nakon prisilnog ponovnog spajanja i nakon restarta usluge rezolvera. Svaki prijelaz provjerava drugu pretpostavku o redoslijedu.

Tek kada svih pet provjera prođe pri ponovnom spajanju, možete reći da se poslane postavke koriste. Sve prije toga je snimak sretnog trenutka.