Aseta DNS Windowsin VPN-sovittimelle PowerShellillä ja varmista se

Windowsin VPN-yhteys ei tallenna DNS-palvelimia profiiliin, jota muokkaat Asetuksissa. Kun tunneli nousee, asiakas neuvottelee IP-määrityksen yhdyskäytävän kanssa, yhdyskäytävä työntää resolveriluettelon ja Windows soveltaa sitä tunnelisovittimeen. Tämä sovitin on erillinen liitäntä Wi-Fi- tai Ethernet-liitännästäsi, ja luettelo kuuluu liitännälle, ei profiilille. Kun tiedät, mikä objekti omistaa arvon, sen ohittaminen PowerShellissä on yksi komento; tehdä ohituksesta uudelleenyhdistämisen kestävä on se osa, joka vaatii päätöksen.

Mikä objekti omistaa osoitteen

RAS luo tunnelisovittimen, kun yhteys onnistuu, ja poistaa sen, kun yhteys katkeaa. DNS-palvelimet, jotka näet komennossa ipconfig /all saapuvat tuon määritysvaihdon aikana IPv4- ja IPv6-osoitteiden sekä reittien vieressä. Koska arvo on kiinnitetty liitäntään, Set-DnsClientServerAddress kirjoittaa johonkin, joka on olemassa vain niin kauan kuin yhteys on.

Tämä yksi tosiasia selittää suurimman osan VPN:n DNS:ään liittyvästä sekaannuksesta. Profiilia voi tarkastella irrotettuna, mutta ei ole liitäntää, johon osoittaa, joten VPN-liitännimeä vasten komentoa kutsuva kirjautumisskripti epäonnistuu ennen kuin kukaan on yhdistänyt. Se selittää myös muutoksen, joka näyttää palautuvan: mikään ei palautunut, liitäntä tuhottiin ja rakennettiin uudelleen yhdyskäytävän työntämillä arvoilla.

Etsi liitännimi ennen kuin kosket DNS:ään

Profiilin nimi ja liitännän liitännimi ovat yleensä sama merkkijono, mutta ne eivät ole sama objekti. Get-VpnConnection luettelee profiilit; Get-NetAdapter luettelee liitännät, jotka Windowsilla todella on. DNS-komennot haluavat toisen, ja ne eroavat useammin kuin ihmiset odottavat, varsinkin kun asiakas liittää sovittimen nimeen kuvauksen, kuten "(RAS)".

Jos profiilia ei ole, PowerShell voi luoda natiivin merkinnän. Tunnelityypin ja todennuksen on vastattava sitä, mitä yhdyskäytävä tarjoaa, koska eroavuus ilmenee yhdistettäessä, ei luotaessa:

Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
  -TunnelType Ikev2 -EncryptionLevel Required `
  -AuthenticationMethod Eap -AllUserConnection

Yhdistä kerran ja lue sitten todellinen liitännimi ennen minkään DNS-komennon kirjoittamista:

rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"

Käytä ohitusta oikeassa järjestyksessä

Järjestys on tärkeämpi kuin syntaksi. Sovittimen on oltava ylhäällä, liitännimen on ratkettava ja tilille on sallittava liitännän asetusten muuttaminen. Käyttäjäkohtainen yhteys hyväksyy yleensä kirjautuneen käyttäjän muutoksen; kaikkien käyttäjien yhteys, joka on luotu parametrilla -AllUserConnection , tarvitsee yleensä korotetun komentotulkin.

Komento itsessään on yksi rivi, dokumentoitu Microsoftin Set-DnsClientServerAddress-viitteessä:

Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4

Kaksi epäonnistumistapaa kannattaa tunnistaa silmämääräisesti. Väärä liitännimi tuottaa komennosta virheen, ja se on hyvä tulos, koska hiljaisuus olisi pahempaa. Oikea komento ilman näkyvää vaikutusta tarkoittaa yleensä, että katsot väärää sovitinta: toiselta asiakkaalta jäänyt tunnelisovitin, fyysinen NIC, jolla on samankaltainen kuvaus, tai toinen virtuaalisovitin, jonka sandbox-verkkotyökalu on luonut.

Miksi uudelleenyhdistäminen voi kumota muutoksen

Ohitus kuuluu yhdelle liitäntäesiintymälle. Kun asiakas purkaa sovittimen ja rakentaa sen uudelleen seuraavassa yhteydessä, työnnetyt arvot otetaan uudelleen käyttöön ja luettelosi on poissa. Jotkut asiakkaat luovat liitännän uudelleen joka yhteydellä; toiset käyttävät sitä uudelleen koko istunnon ajan. Vertaa liitännän indeksiä komennossa Get-NetAdapter kahden yhteyden välillä ja tiedät, mikä käyttäytyminen sinulla on.

Pysyviä vastauksia on kolme, ja niiden pinoaminen luo omat buginsa. Yhteyskohtainen DNS-liite sekä NRPT-sääntö lähettää vain sisäisen nimiavaruuden sisäiselle resolverille ja jättää julkiset nimet rauhaan. VPN-yhteyteen sovellettu Group Policy- tai MDM-asetus asettaa DNS:n yhteyden aikana ilman mitään skriptiä. Yhteystapahtumaan reagoiva ja komennon uudelleen suorittava ajastettu tehtävä on karkea vaihtoehto, mutta se toimii ja jättää lokin. Valitse DNS:lle yksi omistaja ja kirjoita ylös, kuka se on.

Yhden tunnisteen sisäiset nimet tarvitsevat myös liitteen hakuluettelon. Set-DnsClientGlobalSetting -SuffixSearchList on koneenlaajuinen, joten se muuttaa ratkaisua jokaiselle koneen sovittimelle, myös Ethernetille. Testaa sitä laboratoriokoneella ennen kuin se menee levykuvaan.

Varmista ratkaisu, älä vain asetusta

Sovittimelle listattu resolveri todistaa vain, että arvo on kirjoitettu. Kysy aiottua palvelinta suoraan ja kysy sitten tavallista polkua pitkin:

Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example

Jako kertoo, missä vika on. Suora kysely vastaa ja tavallinen kysely epäonnistuu: sovittimen asetus tai liiteluettelo ei ole voimassa. Molemmat epäonnistuvat: resolveri ei ole tunnelin kautta tavoitettavissa, joten katso reitit ja palomuurisäännöt ennen kuin kosket DNS:ään uudelleen. Suora kysely epäonnistuu, kun taas tavallinen kysely vastaa jostain muualta: split DNS on väärin määritetty ja sisäiseen nimeen vastaa julkinen resolveri, mikä on käytäntöongelma ennen kuin se on yhteysongelma.

Suorita testi kahdesti, kerran heti yhteyden jälkeen ja kerran irrottamisen ja uudelleenyhdistämisen jälkeen, ja vertaa Get-DnsClientServerAddress molempien ajojen tulostetta. Jos työnnetty arvo on takaisin toisessa yhteydessä, ohitus eli ja kuoli sovittimen mukana, ja vain edellisen osan NRPT- tai käytäntöreitti pitää. Tallenna molemmat lokit ja yhteyden aikaleimat; ne ratkaisevat kysymyksen pysyvyydestä nopeammin kuin vielä yksi muokkauskierros.