DNS ynstelle op in Windows-VPN-adapter mei PowerShell, en it dêrnei kontrolearje
Windows keppelt de DNS fan de tunnel oan de adapter, net oan it VPN-profyl. Stel it nei it ferbinen yn PowerShell yn en test dan oft in nije ferbining it hâldt.
In Windows-VPN-ferbining bewarret gjin DNS-tsjinners yn it profyl datst yn Ynstellings bewurkest. As de tunnel opkomt, ûnderhannelet de klant de IP-konfiguraasje mei de gateway, de gateway stjoert in list mei resolvers, en Windows past dy ta op de tunneladapter. Dy adapter is in aparte ynterface fan dyn Wi-Fi of Ethernet, en de list heart by de ynterface, net by it profyl. Asst ienris witst hokker objekt de wearde besit, is it oerskriuwen derfan yn PowerShell ien opdracht; it oerskriuwen in nije ferbining oerlibje litte is it part dat in beslissing freget.
Hokker objekt besit it adres
RAS makket de tunneladapter oan as de ferbining slagget en ferwideret him as de ferbining útfalt. De DNS-tsjinners dy'tst yn ipconfig /all sjochst, komme by dy konfiguraasje-útwikseling binnen, njonken de IPv4- en IPv6-adressen en de rûtes. Om't de wearde oan de ynterface hinget, skriuwt Set-DnsClientServerAddress nei eat dat allinnich bestiet salang't de ferbining bestiet.
Dat iene feit ferklearret it measte fan 'e betizing oer VPN-DNS. In profyl kin ynspektearre wurde wylstst net ferbûn bist, mar der is gjin ynterface om nei te wizen, dus in oanmeldskript dat de cmdlet tsjin it VPN-alias oanropt, mislearret foardat immen ferbûn is. It ferklearret ek in feroaring dy't werom te draaien liket: neat is weromdraaid, de ynterface is ferneatige en op 'e nij boud mei de wearden dy't de gateway stjoerd hat.
Fyn it alias foardatst DNS oanrekket
Profylnamme en ynterface-alias binne meastentiids deselde string, mar it binne net deselde objekten. Get-VpnConnection listet profylen op; Get-NetAdapter listet de ynterfaces op dy't Windows echt hat. De DNS-cmdlets wolle de twadde, en dy twa rinne faker útinoar as minsken ferwachtsje, benammen as de klant in oantsjutting lykas "(RAS)" efter de adapternamme set.
As it profyl net bestiet, kin PowerShell in native ynskriuwing meitsje. It tunneltype en de autentikaasje moatte oerienkomme mei wat de gateway biedt, want in mismatch komt by it ferbinen oan it ljocht en net by it meitsjen:
Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
-TunnelType Ikev2 -EncryptionLevel Required `
-AuthenticationMethod Eap -AllUserConnection
Ferbyn ien kear en lês dan it echte alias foardatst in DNS-opdracht skriuwst:
rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"
Pas it oerskriuwen yn 'e juste folchoarder ta
Folchoarder is wichtiger as syntaksis. De adapter moat omheech wêze, it alias moat oplosse, en it akkount moat tastien wurde om ynterface-ynstellingen te feroarjen. In per-brûker-ferbining akseptearret de feroaring meastentiids fan 'e oanmelde brûker; in ferbining foar alle brûkers dy't mei -AllUserConnection makke is, freget oer it algemien in ferhege shell.
De cmdlet sels is ien rigel, dokumintearre yn 'e Set-DnsClientServerAddress-referinsje fan Microsoft:
Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4
Twa flaters binne it werken om te sjen. In ferkeard alias jout in flater fan 'e cmdlet, en dat is de goede útkomst, want stilte soe slimmer wêze. In kode cmdlet sûnder sichtber effekt betsjut meastentiids datst nei de ferkearde adapter sjochst: in oerbliuwende tunneladapter fan in oare klant, in fysike NIC mei in ferlykbere beskriuwing, of in twadde firtuele adapter makke troch in sandbox-netwurktool.
Wêrom't in nije ferbining de feroaring ûngedien meitsje kin
It oerskriuwen heart by ien eksimplaar fan 'e ynterface. As de klant de adapter ôfbrekt en by de folgjende ferbining wer opbouwt, wurde de stjoerde wearden op 'e nij tapast en is dyn list fuort. Guon klanten meitsje de ynterface by elke ferbining op 'e nij; oaren brûke him foar de hiele sesje. Ferlykje de ynterface-yndeks yn Get-NetAdapter tusken twa ferbiningen en dan witst hokker gedrachst hat.
Der binne trije duorsume antwurden, en it stapeljen derfan makket syn eigen flaters. In DNS-suffiks spesifyk foar de ferbining plus in NRPT-regel stjoert allinnich de ynterne nammeromte nei de ynterne resolver en lit publike nammen gewurde. In Group Policy- of MDM-ynstelling tapast op 'e VPN-ferbining set DNS by it ferbinen, sûnder skript. In plande taak dy't op 'e ferbiningbarren reagearret en de cmdlet wer útfiert is de botte opsje, mar hy wurket en lit in log nei. Kies ien eigner foar DNS en skriuw op hokker dat is.
Nammen fan ien label yntern hawwe ek in suffiks-syklabel nedich. Set-DnsClientGlobalSetting -SuffixSearchList jildt foar de hiele masine, dus it feroaret de resolúsje foar elke adapter op 'e kompjûter, ek Ethernet. Test it op in laboratoariummasine foardat it yn in image giet.
Kontrolearje de resolúsje, net allinnich de ynstelling
In resolver dy't op in adapter neamd stiet, bewist allinnich dat der in wearde skreaun is. Freegje de bedoelde tsjinner direkt, freegje dan fia it normale paad:
Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example
De splitsing fertelt wêr't de flater sit. Direkte query antwurdet en de gewoane query mislearret: de adapterynstelling of de suffikslist is net aktyf. Beide mislearje: de resolver is net berikber fia de tunnel, dus sjoch nei rûtes en firewallregels foardatst DNS wer oanrekest. Direkte query mislearret wylst de gewoane query earne oars wei antwurdet: split-DNS is ferkeard konfigurearre en in ynterne namme wurdt beantwurde troch in publike resolver, wat in beliedsprobleem is foardat it in ferbiningsprobleem is.
Draai de test twa kear, ien kear fuort nei it ferbinen en ien kear nei in ferbrekking en nije ferbining, en ferlykje de Get-DnsClientServerAddress-útfier fan beide runs. As de stjoerde wearde by de twadde ferbining werom is, hat it oerskriuwen libbe en stoarn mei de adapter, en allinnich de NRPT- of beliedsrûte fan 'e foarige paragraaf sil hâlde. Bewarje beide transkripten en de tiidstimpels fan it ferbinen; se beklinke de fraach oft it bliuwt flugger as in nije ronde bewurkings.