DNS koji gura OpenVPN se ignoriše: koja komponenta ga primjenjuje

Dnevnik pokazuje opciju koju je server gurnuo, tunel je podignut, a interna imena i dalje ne prolaze. Upit direktno na rezolver odgovara, dakle server je ispravan, ali svaka aplikacija nastavlja pitati lokalni ruter. Ono što je stiglo do klijenta je ponuda, a ne promjena u rezolveru, i komponenta koja posjeduje razrješavanje imena razlikuje se na Linuxu, Windowsu i macOS-u. Kad odvojite opciju od njenog vlasnika, četiri kvara pokrivaju skoro svaki izvještaj: nema hooka, dva hooka se takmiče, podijeljeni DNS radi kako je projektovan, ili kratko ime traži sufiks, a ne server.

Gurana opcija je ponuda, a ne instalacija

Na serveru dvije direktive opisuju namjeru, a ne efekat:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Klijent ne dobija konfigurisan rezolver. Dobija varijable okruženja, foreign_option_1 i dalje, jednu po guranom redu, i nešto lokalno ih mora pročitati i prepisati stanje rezolvera operativnog sistema. Na Linuxu to po defaultu ne radi ništa, zato ispravan server i povezan klijent i dalje mogu razrješavati kroz LAN.

Između dva kraja stoje tri faze: push mora stići, klijent ga mora izložiti, a hook ga mora primijeniti. Čitajte srednju fazu u dnevniku klijenta, a posljednju u stanju rezolvera, nikad obrnuto, jer linija u dnevniku dokazuje samo prve dvije.

Potvrdite da je push stigao i pronađite vlasnika

Počnite imenovanjem pokretača: gola openvpn komanda, systemd instanca, NetworkManager ili klijent proizvođača. To odlučuje gdje hook može živjeti. Na hostu sa systemd-resolved, resolvectl status ispisuje svaku vezu sa DNS serverima i domenima pretrage koje stvarno koristi, a veza tunela se ne zove uvijek tun0.

Ako se gurana adresa pojavi u dnevniku ali ne na nijednoj vezi, integracija nedostaje. Ako se pojavi na vezi a upiti i dalje izlaze negdje drugo, problem je koji upiti biraju tu vezu. NetworkManager dns=dnsmasq u fajlu /etc/NetworkManager/NetworkManager.conf pokreće lokalni prosljeđivač koji namjerno primjenjuje podijeljeni DNS: imena unutar VPN domena idu ka VPN rezolveru, a sve ostalo zadržava prethodnu putanju. Takvo ponašanje izgleda kao kvar kad ste očekivali da se sav saobraćaj preseli; provjerite postavke po konekciji pomoću nmcli connection show "My VPN", gdje ipv4.dns i ipv4.dns-search drže vrijednosti iza onoga što uređaj prijavljuje, prije nego to nazovete pokvarenim. Ako svaki upit zaista treba da stigne do VPN rezolvera, uklonite dns=dnsmasq iz NetworkManager.conf i restartujte NetworkManager, što vraća razrješavanje na postavke konekcije; u suprotnom zadržite podijeljeni DNS i ispravite guranu listu domena.

Linux: predajte opcije rezolveru

Distribucijski paketi donose hook za to, a klijentu mora biti dozvoljeno da ga pokrene. Tipičan raspored na hostu bez systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Sa systemd-resolved, starija skripta resolv.conf možda ne mijenja ništa važno, jer stub rezolver drži stanje po vezi. update-systemd-resolved pomoćnik dokumentuje oblik hooka koji koristi up-restart i down-pre, što je važno kad interfejs nadživi jedan pokušaj konekcije. Šta god odabrali, jedna komponenta mora posjedovati stanje. Dodavanje nepovezanog hooka pored NetworkManagera daje dva pisca istoj vezi, a rezultat tada zavisi od redoslijeda, a ne od vaše konfiguracije.

Postoji i slučaj u kojem je NetworkManager potpuno ignorisao guranu opciju dok adresa servera nije unesena u IPv4 postavke konekcije, nakon čega je stanje rezolvera pokazalo da se koristi. Vrijedi to probati prije nego što prepišete skripte, jer premješta problem sa shell hooka na profil konekcije koji već nosi tunel.

Windows i macOS primjenjuju različite dijelove

Windows klijent zaista postavlja DNS servere VPN adaptera, ali Windows i dalje bira interfejs po metrici i i dalje mu treba sufiks da proširi kratko ime. Potvrdite stanje adaptera, a ne profila:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Ako adresa nedostaje, postavite je pomoću Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, zatim dodajte sufiks u IPv4 svojstva adaptera da fileserver postane fileserver.corp.example. Vrijednost SearchList na nivou mašine pod Tcpip\Parameters radi isto. Gdje se dugo ime razrješava a golo ne, rezolver je već ispravan i kriva je lista pretrage. Ispravke, redom: gurnite DOMAIN da klijent nauči sufiks, dodajte taj sufiks na listu pretrage adaptera ili konekcije, i kao privremenu mjeru prikujte ime u hosts, ili LMHOSTS na Windowsu; NetBIOS pretraživanje ne prelazi ruter, pa emitovanje koje nalazi kratko ime na kancelarijskom LAN-u nikad ne stiže do klijenta tunela.

block-outside-dns block-outside-dns je ponašanje Windows klijenta, a ne prenosiva linija profila, i kopiranje u Linux ili macOS profil ne reprodukuje ga tamo. Ako javna imena rade a interna ne na Windowsu, uporedite redoslijed adaptera u Advanced settings sa ipconfig /all. Na macOS-u redoslijed rezolvera po servisu pripada sistemu, pa koristite scutil --dns da vidite koji rezolver se pita za koji domen, i tretirajte svaku pojedinačnu prijavljenu ispravku profila kao zavisnu od klijenta, a ne opštu.

Virtuelna mašina na istom laptopu ne nasljeđuje ništa od ovoga. Dajte gostu vlastiti unos rezolvera za interni domen, ili pustite NAT hipervizora da prosljeđuje njegove upite kroz host, što je ispravno samo dok je tunel hosta podignut.

Historija je treći uzrok. DNS serveri ili postavke sufiksa iz ranijeg profila mogu preživjeti ponovna povezivanja, pa kad adapter izgleda ispravno a pretrage i dalje ne prolaze, uporedite živi adapter sa Get-VpnConnection i obrišite ili prepišite zastarjeli unos prije nego što dirnete server.

Dokažite gdje je upit otišao

Snimak tokom jedne pretrage rješava raspravu: tcpdump -ni eth0 port 53 pokazuje upite na fizičkom interfejsu, što znači da izlaze izvan tunela i da rezolver nije nikad prebačen. dig @10.8.0.1 name.corp.example zatim razdvaja dva preostala slučaja. Ako direktni upit odgovara, rezolver radi i klijent ga ne koristi; ako istekne, rezolver je nedostupan kroz tunel i nikakva lokalna promjena neće pomoći.

Ako je rezolver koji se još koristi onaj koji je provajder podijelio, tunel šifruje saobraćaj dok imena ostaju vidljiva tom provajderu. To je pitanje curenja, a ne funkcionalnosti, i isti snimak odgovara na njega: upit na fizičkom interfejsu ide nekome izvan tunela.

Dostupnost uključuje firewall na VPN hostu, koji mora dozvoliti UDP i TCP 53 iz poola. Zatvoren port izgleda tačno kao pokvaren push, a isto i rezolver koji odgovara samo iz unutrašnjosti tunelske mreže. Ponovite snimak nakon jednog prekida i ponovnog povezivanja, jer postavke koje se pojave pri prvom povezivanju a nestanu pri drugom su kvar životnog ciklusa u hooku, a ne opcija koja nedostaje.

Zadržite jednog vlasnika i provjeravajte po redu

Skripta koja prepisuje DNS adaptera na osnovu pretpostavljenog stanja tunela duplira konfiguraciju koju profil već nosi, i tiho pada prvi put kad je pretpostavka pogrešna. Preferirajte vlastite DNS postavke konekcije ili jedan dokumentovani hook, i zabilježite koji ste odabrali da sljedeća osoba ne doda drugi.

Zatvorite petlju s četiri provjere: gurana adresa prisutna na vezi tunela, interno ime se razrješava kao potpuno kvalifikovano ime, isto ime se razrješava bez sufiksa, i oboje još vrijedi nakon jednog ponovnog povezivanja. Jedan snimak vam kaže koja od četiri nije prošla. Priručnik za OpenVPN 2.6 navodi dhcp-option i skriptne direktive s njihovim napomenama za platforme.