Merutekan subnet aplikasi adalah bagian yang jelas dari tunnel terpisah, dan itu bukan seluruh pekerjaan. Resolver sering berada di alamat yang berbeda dari aplikasi yang dilayaninya, sehingga tunnel yang berfungsi masih bisa meninggalkan pencarian di luarnya. Profil yang membawa 10.80.0.0/16 dan tidak ada yang lain mengirim kueri untuk 10.90.0.53 melalui antarmuka lokal, tempat tidak ada zona privat. Tambahkan jalur resolver, lalu lihat separuh kedua masalah: server mana yang sebenarnya dipilih klien.

Mitos: satu rute mencakup seluruh layanan

Tunnel terpisah adalah daftar tujuan yang melewati koneksi, bukan deskripsi layanan. Subnet aplikasi dan alamat resolver adalah dua tujuan, dan profil dapat membawa salah satunya tanpa yang lain. Saat itu terjadi, aplikasi dapat dijangkau lewat alamat sementara namanya gagal, yang tampak seperti kesalahan DNS bukan celah perutean.

Subnet di sekitar resolver juga tidak tercakup otomatis. Rute host ke satu alamat cukup untuk resolver itu dan tidak membuka tetangganya. Itulah inti rute host: sempit secara rancangan, dan mudah dilupakan saat layanan berikutnya muncul di subnet yang sama.

Tiga hal harus terpenuhi agar pencarian berhasil: klien merutekan alamat resolver melalui tunnel, gateway menerima dan meneruskan permintaan itu, dan resolver menerima sumber yang diterimanya. Balasan juga harus kembali melalui jalur yang disepakati. Jika salah satu hilang, gejalanya sama, karena itu ada baiknya menulis tabel alamat sebelum menyentuh konfigurasi.

Tentukan alamat mana yang harus dibawa profil

Daftarkan tujuan secara berurutan: jaringan aplikasi, alamat resolver, dan titik akhir publik yang mengakhiri tunnel itu sendiri. Yang ketiga tidak boleh pernah dirutekan ke dalam tunnel, karena koneksi luar membutuhkan jalur yang ada sebelum tunnel.

DestinationCoverage this example needs
Application network10.80.0.0/16 through the VPN
Private resolver10.90.0.53/32 through the VPN
Public VPN endpointNormal internet path, outside the tunnel

Sertakan UDP dan TCP untuk DNS, karena implementasi diharapkan mendukung TCP selain UDP, dan jalur TCP yang diblokir menghasilkan kegagalan lambat dan sebagian alih-alih bersih. Jika zona privat juga dilayani melalui IPv6, pengecualian host yang setara memakai alamat dan prefiks IPv6 dan merupakan entri terpisah.

Catat apa yang sudah dicakup profil sebelum menambahkan apa pun. Rute duplikat tidak berbahaya, tetapi rute yang ada dan tidak terduga memberi tahu Anda bahwa profil dirancang untuk rencana alamat yang berbeda dari yang Anda terima.

Tambahkan rute host melalui pemilik koneksi

Untuk profil Windows asli yang dikelola secara lokal, rute milik koneksi, bukan tabel perutean global mesin. Pratinjau penambahan terlebih dahulu, lalu terapkan dengan cakupan yang sama seperti yang dipakai profil.

Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf
Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes

Perintah pertama mempratinjau perubahan tanpa memasang apa pun, dan yang kedua mendaftar rute yang saat ini dibawa profil. Referensi Add-VpnConnectionRoute dari Microsoft mendokumentasikan cakupan per pengguna dan semua pengguna; profil semua pengguna membutuhkan parameter cakupannya sendiri, dan perintah per pengguna terhadap profil semua pengguna gagal atau mendarat di tempat yang salah.

Saat profil dikelola atau berasal dari klien vendor, perubahan menjadi milik pemilik itu. Menumpuk rute sistem permanen di atas kebijakan koneksi berfungsi sampai kebijakan diterapkan ulang dan rute hilang, yang biasanya terjadi saat panggilan dukungan, bukan saat pengujian. Kegagalan itu sunyi: rute hilang, nama berhenti diselesaikan, dan tidak ada yang menghubungkan kedua peristiwa. Letakkan perubahan di catatan pemilik itu sendiri agar penerapan ulang berikutnya membawanya alih-alih menghapusnya.

Setelah menerapkan, sambungkan ulang profil alih-alih mengasumsikan rute sudah berlaku. Perubahan rute pada koneksi aktif tidak selalu tertangkap, dan menyambung ulang juga mereproduksi keadaan yang sebenarnya akan dialami pengguna Anda.

Periksa resolver mana yang sebenarnya dipakai klien

Rute mengendalikan paket yang dialamatkan ke resolver. Rute tidak memutuskan nama mana yang harus dikirim ke sana, dan pemilihan itu adalah mekanisme terpisah. Di Windows, aturan ruang nama yang berlaku dapat memilih resolver per domain, sementara pengaturan DNS profil menyediakan nilai bawaan. Kedua lapisan itu dapat berbeda tanpa menghasilkan kesalahan apa pun, karena itu kueri langsung hanya separuh bukti.

Get-DnsClientNrptPolicy
Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A

Perintah pertama mencetak kebijakan ruang nama yang berlaku, dan yang kedua menanyakan langsung ke resolver privat nama aplikasi. Jawaban langsung membuktikan jalur dan resolver berfungsi; itu tidak membuktikan bahwa pencarian aplikasi sendiri memilih server itu. Bandingkan dengan pencarian normal dari nama yang sama dan dengan jawaban yang diterima aplikasi.

Pertimbangkan cache dan DNS aman tingkat peramban, yang dapat melewati resolver sistem sepenuhnya untuk nama yang diketik pengguna. Sufiks pencarian adalah petunjuk palsu lain: ia memperluas nama pendek menjadi nama yang sepenuhnya memenuhi syarat dan tidak ada hubungannya dengan server mana yang menjawab.

Akhiri dengan menyambung ulang dan mengulangi pencarian normal, lalu pastikan penjelajahan biasa masih mengikuti kebijakan yang disetujui. Mengganti resolver privat dengan yang publik agar nama yang tidak terkait dapat diselesaikan bukanlah perbaikan, dan diam-diam memindahkan kueri privat ke tempat yang tidak pernah dimaksudkan.

Artikel terkait