Menyetel DNS pada adaptor VPN Windows dengan PowerShell, lalu memverifikasinya

Koneksi VPN Windows tidak menyimpan server DNS di profil yang Anda edit di Pengaturan. Saat terowongan menyala, klien menegosiasikan konfigurasi IP dengan gateway, gateway mengirimkan daftar resolver, dan Windows menerapkannya ke adaptor terowongan. Adaptor itu adalah antarmuka terpisah dari Wi-Fi atau Ethernet Anda, dan daftar tersebut milik antarmuka, bukan milik profil. Setelah Anda tahu objek mana yang memiliki nilai itu, menimpanya di PowerShell hanya satu perintah; membuat penimpaan bertahan melewati sambungan ulang adalah bagian yang butuh keputusan.

Objek mana yang memiliki alamat itu

RAS membuat adaptor terowongan saat koneksi berhasil dan menghapusnya saat koneksi terputus. Server DNS yang Anda lihat di ipconfig /all datang selama pertukaran konfigurasi itu, bersamaan dengan alamat IPv4 dan IPv6 serta rute. Karena nilainya menempel pada antarmuka, Set-DnsClientServerAddress menulis ke sesuatu yang hanya ada selama koneksi ada.

Satu fakta itu menjelaskan sebagian besar kebingungan seputar DNS VPN. Profil dapat diperiksa saat terputus, tetapi tidak ada antarmuka yang bisa ditunjuk, sehingga skrip logon yang memanggil cmdlet terhadap alias VPN gagal sebelum siapa pun tersambung. Ini juga menjelaskan perubahan yang tampak kembali seperti semula: tidak ada yang kembali, antarmukanya dihancurkan lalu dibangun ulang dengan nilai yang dikirim gateway.

Temukan alias sebelum menyentuh DNS

Nama profil dan alias antarmuka biasanya string yang sama, tetapi keduanya bukan objek yang sama. Get-VpnConnection mendaftar profil; Get-NetAdapter mendaftar antarmuka yang benar-benar dimiliki Windows. Cmdlet DNS menginginkan yang kedua, dan keduanya lebih sering berbeda daripada yang diduga orang, terutama ketika klien menambahkan deskriptor seperti "(RAS)" ke nama adaptor.

Jika profil belum ada, PowerShell dapat membuat entri native. Jenis terowongan dan autentikasi harus cocok dengan yang ditawarkan gateway, karena ketidakcocokan muncul saat menyambung, bukan saat membuat:

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

Sambungkan sekali, lalu baca alias sebenarnya sebelum menulis perintah DNS apa pun:

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

Terapkan penimpaan dalam urutan yang benar

Urutan lebih penting daripada sintaksis. Adaptor harus menyala, alias harus bisa diresolusi, dan akun harus diizinkan mengubah pengaturan antarmuka. Koneksi per pengguna biasanya menerima perubahan dari pengguna yang sedang masuk; koneksi untuk semua pengguna yang dibuat dengan -AllUserConnection umumnya memerlukan shell dengan hak tinggi.

Cmdlet itu sendiri hanya satu baris, didokumentasikan dalam referensi Set-DnsClientServerAddress milik Microsoft:

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

Ada dua mode kegagalan yang layak dikenali secara visual. Alias yang salah menghasilkan galat dari cmdlet, dan itu hasil yang baik, karena diam akan lebih buruk. Cmdlet yang benar tanpa efek terlihat biasanya berarti Anda melihat adaptor yang salah: adaptor terowongan sisa dari klien lain, kartu jaringan fisik dengan deskripsi serupa, atau adaptor virtual kedua yang dibuat oleh alat jaringan sandbox.

Mengapa sambungan ulang dapat membatalkan perubahan

Penimpaan itu milik satu instans antarmuka. Ketika klien membongkar adaptor dan membangunnya kembali pada sambungan berikutnya, nilai yang dikirim diterapkan lagi dan daftar Anda hilang. Sebagian klien membuat ulang antarmuka pada setiap sambungan; yang lain memakainya sepanjang umur sesi. Bandingkan indeks antarmuka di Get-NetAdapter pada dua koneksi dan Anda akan tahu perilaku mana yang Anda miliki.

Ada tiga jawaban tahan lama, dan menumpuknya menciptakan bug tersendiri. Sufiks DNS khusus koneksi ditambah aturan NRPT hanya mengirim namespace internal ke resolver internal dan membiarkan nama publik. Pengaturan Group Policy atau MDM yang diterapkan pada koneksi VPN menyetel DNS saat menyambung tanpa skrip apa pun. Tugas terjadwal yang bereaksi terhadap peristiwa koneksi dan menjalankan ulang cmdlet adalah opsi kasar, tetapi berhasil dan meninggalkan log. Pilih satu pemilik untuk DNS dan tuliskan yang mana.

Nama internal berlabel tunggal juga memerlukan daftar pencarian sufiks. Set-DnsClientGlobalSetting -SuffixSearchList berlaku untuk seluruh mesin, jadi ia mengubah resolusi untuk setiap adaptor di komputer, termasuk Ethernet. Uji di mesin lab sebelum masuk ke sebuah image.

Verifikasi resolusi, bukan hanya pengaturannya

Resolver yang tercantum pada adaptor hanya membuktikan bahwa sebuah nilai telah ditulis. Tanyakan langsung ke server yang dituju, lalu tanyakan melalui jalur normal:

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

Pemisahan itu memberi tahu Anda di mana letak kesalahannya. Kueri langsung menjawab dan kueri biasa gagal: pengaturan adaptor atau daftar sufiks tidak berlaku. Keduanya gagal: resolver tidak dapat dijangkau melalui terowongan, jadi periksa rute dan aturan firewall sebelum menyentuh DNS lagi. Kueri langsung gagal sementara kueri biasa menjawab dari tempat lain: DNS terpisah salah dikonfigurasi dan nama internal dijawab oleh resolver publik, yang merupakan masalah kebijakan sebelum menjadi masalah konektivitas.

Jalankan pengujian dua kali, sekali tepat setelah menyambung dan sekali setelah memutus lalu menyambung ulang, dan bandingkan keluaran Get-DnsClientServerAddress dari kedua proses. Jika nilai yang dikirim kembali pada koneksi kedua, penimpaan hidup dan mati bersama adaptor, dan hanya rute NRPT atau kebijakan dari bagian sebelumnya yang akan bertahan. Simpan kedua transkrip dan stempel waktu koneksi; keduanya menyelesaikan pertanyaan apakah pengaturan bertahan lebih cepat daripada putaran pengeditan berikutnya.