OpenVPN gura DNS, ali ga resolver možda nikada neće vidjeti
DNS vrijednost u klijentskom logu nije dokaz da je koristi resolver operativnog sistema. Provjerite vlasnika, pa testirajte interno ime.
Klijentski log prikazuje gurnuti DNS server, tunel je povezan, a interno ime se i dalje ne razrješava. Ništa nije pokvareno u samom guranju. Opcija je stigla, ali je resolver operativnog sistema nikada nije iskoristio, jer na većini Unix klijenata OpenVPN predaje vrijednost i prepušta aplikaciju platformi.
Simptom: log prikazuje DNS, a imena i dalje ne rade
OpenVPN dhcp-option nosi DNS i informacije o domeni, a klijent bilježi šta je primio. U nekim implementacijama klijent te postavke primjenjuje interno; u drugima ih izvozi za integracijsku skriptu ili mrežnu uslugu. Linija loga opisuje samo prvu polovinu priče. Druga polovina se dešava negdje što klijent ne kontroliše. Tu obično živi kvar.
Zato se povezan tunel i neuspješno interno ime tako često javljaju zajedno. Vrijednost postoji, potrošač nedostaje ili je pogrešno konfigurisan, a resolver tiho nastavlja koristiti javni server koji je koristio prije veze.
Primljeno nije primijenjeno
Klijent može zabilježiti gurnutu DNS vrijednost dok sistemski resolver ostaje u vlasništvu druge usluge. Preglednik može imati i vlastitu politiku šifrovanog DNS-a koja potpuno zaobilazi sistemski resolver, što stvara pamtljivu situaciju u kojoj jedna aplikacija razrješava interna imena, a druga ne.
Provjerite podržanu integraciju implementacije umjesto da pretpostavite da svaki Unix klijent prepisuje isti fajl. Ta pretpostavka je razlog zašto ljudi uređuju resolver konfiguraciju koju ništa ne čita.
Pronađite vlasnika resolvera po platformi
Na Windowsu tabela politike razrješavanja imena može usmjeravati određene sufikse na određene servere, a VPN klijent tamo može instalirati pravila. Provjerite politiku, ne samo DNS listu adaptera. Na Linuxu konfiguracijom može upravljati NetworkManager ili systemd-resolved, a koji od njih upravlja njome određuje šta će ponovno povezivanje sačuvati.
Pročitajte stvarno stanje alatom koji zaista odgovara na upite: resolvectl query internal.example.net na systemd-resolved hostu, ili ekvivalentom platforme. Zatim uporedite taj odgovor s DNS serverom za koji klijentski log tvrdi da ga je gurnuo.
Izbjegavajte pokretanje nekoliko usluga koje prepisuju resolver postavke bez koordinacije. Dva vlasnika daju rezultat koji izgleda isprekidano, a svako ponovno povezivanje izgleda kao da ga nasumično popravlja ili kvari.
Skripte i foreign_option
OpenVPN izvozi gurnute opcije u skripte kroz varijable nazvane foreign_option_N, a skripta ih može prevesti u resolver komande. Taj raspored je podržana integracija, ne automatsko ponašanje, i mora se instalirati i pozvati na klijentu.
Ako se oslanjate na skriptu, bilježite njeno izvršavanje i izlazni status. Skripta koja radi ali tiho ne uspije ostavlja isti simptom kao da skripte nema, i teže se primjećuje jer konfiguracija izgleda kompletna. Provjerite izlaz skripte, ne fajl skripte. Fajl koji postoji nije skripta koja je radila.
Testirajte ime, ne log
Nakon povezivanja upitajte klijenta za hostname dostupan samo interno, zatim upitajte javno ime, pa provjerite koji server je odgovorio. U ispravnoj postavci dva odgovora dolaze s različitih mjesta i oba treba da se poklope s dizajnom.
Ako se ime razrješava ali usluga ne radi, pređite na usmjeravanje i pristup aplikacijama umjesto da ponovo mijenjate DNS. OpenVPN priručnik dokumentuje dhcp-option i skriptno okruženje; koristite ga da potvrdite šta se od vašeg klijenta očekuje prije nego uredite još jedan resolver fajl.