VPN je preuzeo DNS i pokvario lokalna imena: popravite listu

Tunel se podiže, intranet se učitava, a ime štampača prestaje da se razrješava. Ili obrnuto: lokalna imena još rade dok sve unutar korporativne mreže istječe. Oba simptoma dolaze s istog mjesta, liste razrješivača koju je VPN klijent prepisao pri spajanju.

Popravite listu namjerno, a zatim se posebno pozabavite mehanizmom push. Rute su treća tema i nisu ona koja se ovdje popravlja.

Koju listu aplikacije zapravo koriste

Windows razrješava kroz postavke na nivou interfejsa, a ne kroz ono što prikazuje neki dijalog, zato počnite s efektivnim listama po interfejsu. Alias je važniji od prikazanog imena, jer svaka komanda ispod obraća se interfejsu. Pogriješite li alias, popravka će pasti na pogrešan adapter. Izgledat će da radi do sljedećeg ponovnog spajanja, kada se vrati vlastiti unos tunela.

Pitanje je koji su serveri završili naprijed i jesu li došli kao statični unosi ili kao DHCP zakup. Obje činjenice odlučuju koja vam je popravka dostupna.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Pročitajte izlaz za adapter tunela i za fizički adapter i zabilježite svaku adresu na svakom. Statični unos može se ukloniti politikom ili skriptom; unos dobijen putem DHCP-a vezan je za zakup i vratit će se, što mijenja popravku koju trebate odabrati. Imena u udaljenoj mreži razrješava oglašeni razrješivač, imena na lokalnom LAN-u fizički adapter, a upit ide listi koja se prva konsultuje.

Uklonite gurnute servere ili ih rangirajte niže

Izbrišite gurnute servere kada ništa unutar tunela ne treba njih, jer vlastiti razrješivači fizičkog adaptera ponovo preuzimaju. Zadržite ih samo ako udaljena mreža posjeduje zone na koje mogu odgovoriti samo njeni serveri, i u tom slučaju stavite lokalni razrješivač ispred njih. Dvije komande ispod pokrivaju oba izbora, zato odaberite onu koja odgovara situaciji umjesto da pokrećete obje.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Indeks 1 se konsultuje prvi, pa gurnute adrese ostaju dostupne, ali prestaju biti zadani odgovor za svaki upit. Zastavica validate=no preskače provjeru dostupnosti koja često pada dok se tunel još stabilizuje, zato potvrdite rezultat komandom show umjesto da vjerujete izlaznom kodu.

Dvije granice vrijedi znati prije nego se oslonite na ovo. Windows neće izbrisati servere koji su došli putem DHCP-a kroz netsh, a te vrijednosti ostaju kao DhcpNameServer ispod registarskog ključa interfejsa, pa je izmjena registra posljednje sredstvo koje treba ponovo provjeriti nakon sljedećeg zakupa. Redoslijed povezivanja adaptera također nije pouzdan mehanizam rangiranja, jer VPN klijent može ubaciti vlastiti unos na vrh liste.

Gdje se push može filtrirati

Bolja popravka uklanja opciju prije nego se primijeni. Community OpenVPN klijent može filtrirati gurnutu direktivu po imenu, što ostavlja konfiguraciju servera netaknutom.

pull-filter ignore "dhcp-option DNS "

Prazno mjesto na kraju pripada poklapanju, a filter imenuje opciju, a ne adresu servera. Ako profil sadrži i direktivu block-outside-dns, njeno uklanjanje mijenja zaštitu od curenja, a ne razrješavanje imena, zato to odlučite odvojeno umjesto da objedinite dvije izmjene.

Za jedno tvrdoglavo ime hosta, jedan red u Windows hosts datoteci stabilniji je od preslagivanja razrješivača za cijelu mašinu. On je i nevidljiv sljedećoj osobi, zato ga zabilježite gdje god se dokumentuje konfiguracija mašine.

Neka popravka preživi ponovno spajanje

Razrješavanje se mora testirati dvaput, jednom protiv odabranog servera i jednom u obliku koji aplikacija koristi. Taj par razdvaja problem redoslijeda razrješivača od servera koji uopće ne odgovara. Preskakanje prvog testa ostavlja dva uzroka isprepletena.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Ponovo spojite tunel i ponovite obje komande. Sve što ste ručno promijenili traje samo do sljedeće veze, jer klijent obnavlja stanje razrješivača dok podiže adapter. Stavite linije netsh u podržanu skriptu za spajanje svog klijenta, pustite tu skriptu da se uspješno završi i dodajte kratko čekanje prije nego se pokrene. Klijent koji primijeni DNS nakon skripte ionako će prepisati rezultat.

Ako se javna imena razrješavaju, a interna i dalje ne uspijevaju nakon popravke, lista razrješivača prestala je biti sumnjivac. Upit vjerojatno uopće ne stiže do servera, što upućuje na rutiranje ili pravilo firewall-a, a ne na još jednu DNS postavku. Zabilježite alias interfejsa i adrese na kojima ste se zaustavili, jer se oba razlikuju među mašinama i nijedno ne preživljava ponovnu izgradnju samo po sebi.