VPN otti DNS:n haltuunsa ja rikkoi paikalliset nimet: korjaa lista

Tunneli nousee, intranet latautuu ja tulostimen nimi lakkaa ratkeamasta. Tai päinvastoin: paikalliset nimet toimivat yhä, kun kaikki yritysverkon sisällä aikakatkeaa. Molemmat oireet tulevat samasta paikasta, ratkaisijoiden listasta, jonka VPN-asiakasohjelma kirjoitti uudelleen yhdistäessään.

Korjaa lista tarkoituksella ja käsittele sen jälkeen push-mekanismi erikseen. Reitit ovat kolmas aihe eikä se, mitä tässä korjataan.

Mitä listaa sovellukset todella käyttävät

Windows ratkaisee liitäntätason asetuksilla eikä sillä, mitä jokin valintaikkuna näyttää, joten aloita kunkin liitännän voimassa olevista listoista. Alias on tärkeämpi kuin näytetty nimi, koska jokainen alla oleva komento osoittaa liitäntää. Jos alias menee väärin, korjaus laskeutuu väärälle sovittimelle. Se näyttää toimivan seuraavaan uudelleenyhdistämiseen asti, jolloin tunnelin oma merkintä palaa.

Kysymys on, mitkä palvelimet päätyivät eteen ja tulivatko ne staattisina merkintöinä vai DHCP-vuokrauksena. Molemmat seikat ratkaisevat, mikä korjaus on käytettävissäsi.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Lue tuloste tunnelisovittimelle ja fyysiselle sovittimelle ja kirjaa jokainen osoite kummastakin. Staattinen merkintä voidaan poistaa käytännöllä tai skriptillä; DHCP:n antama merkintä on sidottu vuokraukseen ja palaa, mikä muuttaa valittavaa korjausta. Etäverkon nimet ratkaisee ilmoitettu ratkaisija, paikallisen LANin nimet fyysinen sovitin, ja kysely menee listalle, jota kysytään ensin.

Poista työnnetyt palvelimet tai sijoita ne alemmas

Poista työnnetyt palvelimet, kun mikään tunnelin sisällä ei tarvitse niitä, koska fyysisen sovittimen omat ratkaisijat ottavat taas vastuun. Pidä ne vain, jos etäverkolla on vyöhykkeitä, joihin vain sen omat palvelimet osaavat vastata, ja siinä tapauksessa laita paikallinen ratkaisija niiden eteen. Kaksi alla olevaa komentoa kattaa molemmat vaihtoehdot, joten valitse tilanteeseen sopiva sen sijaan että ajaisit molemmat.

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

Indeksiä 1 kysytään ensin, joten työnnetyt osoitteet pysyvät saatavilla mutta lakkaavat olemasta jokaisen kyselyn oletusvastaus. Lippu validate=no ohittaa tavoitettavuustestin, joka usein epäonnistuu, kun tunneli vielä asettuu, joten vahvista tulos show-komennolla sen sijaan että luottaisit paluukoodiin.

Kaksi rajaa kannattaa tuntea ennen kuin tähän luottaa. Windows ei poista palvelimia, jotka tulivat DHCP:n kautta netsh-komennon kautta, ja ne arvot säilyvät DhcpNameServer-merkintänä liitännän rekisteriavaimen alla, joten rekisterin muokkaus on viimeinen keino, joka on tarkistettava uudelleen seuraavan vuokrauksen jälkeen. Sovittimien sidontajärjestys ei sekään ole luotettava järjestysmekanismi, koska VPN-asiakasohjelma voi lisätä oman merkintänsä listan kärkeen.

Missä push voidaan suodattaa

Parempi korjaus poistaa vaihtoehdon ennen kuin se otetaan käyttöön. Community OpenVPN -asiakasohjelma voi suodattaa työnnetyn direktiivin nimen perusteella, mikä jättää palvelimen kokoonpanon koskemattomaksi.

pull-filter ignore "dhcp-option DNS "

Loppuvälilyönti kuuluu osumaan ja suodatin nimeää vaihtoehdon eikä palvelinosoitetta. Jos profiili sisältää myös block-outside-dns-direktiivin, sen poistaminen muuttaa vuotosuojausta eikä nimenratkaisua, joten päätä se erikseen sen sijaan että niputtaisit kaksi muutosta.

Yhden itsepäisen isäntänimen kohdalla yksi rivi Windowsin hosts-tiedostossa on vakaampi kuin ratkaisijoiden uudelleenjärjestäminen koko koneelle. Se on myös näkymätön seuraavalle henkilölle, joten kirjaa se sinne, missä koneen kokoonpano dokumentoidaan.

Tee korjauksesta uudelleenyhdistämisen kestävä

Nimenratkaisu on testattava kahdesti, kerran valittua palvelinta vasten ja kerran siinä muodossa, jota sovellus käyttää. Tämä pari erottaa ratkaisijajärjestyksen ongelman palvelimesta, joka ei vastaa lainkaan. Ensimmäisen testin väliin jättäminen jättää kaksi syytä sotkeutuneiksi.

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

Yhdistä tunneli uudelleen ja toista molemmat komennot. Käsin tekemäsi muutokset kestävät vain seuraavaan yhteyteen, koska asiakasohjelma rakentaa ratkaisijatilansa uudelleen nostaessaan sovitinta. Laita netsh-rivit asiakasohjelmasi tuettuun yhdistämiskriptiin, anna skriptin päättyä onnistuneesti ja lisää lyhyt odotus ennen sen suorittamista. Asiakasohjelma, joka soveltaa DNS:n skriptin jälkeen, kirjoittaa tuloksen joka tapauksessa yli.

Jos julkiset nimet ratkeavat ja sisäiset epäonnistuvat yhä korjauksen jälkeen, ratkaisijalista ei ole enää epäilty. Kysely ei todennäköisesti saavuta palvelinta lainkaan, mikä viittaa reititykseen tai palomuurisääntöön eikä toiseen DNS-asetukseen. Kirjaa liitännän alias ja osoitteet, joihin päädyit, koska molemmat vaihtelevat koneiden välillä eikä kumpikaan selviä uudelleenrakennuksesta yksin.