Terowong terpisah anda sampai ke aplikasi tetapi bukan pelayan DNS-nya

Menghalakan subnet aplikasi ialah bahagian jelas dalam terowong terpisah, dan ia bukan keseluruhan kerja. Penyelesai sering berada pada alamat berbeza daripada aplikasi yang dilayaninya, jadi terowong yang berfungsi masih boleh meninggalkan carian di luarnya. Profil yang membawa 10.80.0.0/16 dan tiada apa-apa lagi menghantar pertanyaan untuk 10.90.0.53 melalui antara muka tempatan, di mana tiada zon peribadi wujud. Tambah laluan penyelesai, kemudian lihat separuh kedua masalah itu: pelayan mana yang sebenarnya dipilih klien.

Mitos: satu laluan meliputi seluruh perkhidmatan

Terowong terpisah ialah senarai destinasi yang melalui sambungan, bukan penerangan tentang perkhidmatan. Subnet aplikasi dan alamat penyelesai ialah dua destinasi, dan profil boleh membawa satu tanpa yang lain. Apabila itu berlaku, aplikasi boleh dicapai melalui alamat manakala namanya gagal, yang kelihatan seperti kerosakan DNS dan bukannya jurang penghalakan.

Subnet di sekeliling penyelesai juga tidak diliputi secara automatik. Laluan hos ke satu alamat cukup untuk penyelesai itu dan tidak membuka jirannya. Itulah maksud laluan hos: sempit mengikut reka bentuk, dan mudah dilupakan apabila perkhidmatan seterusnya muncul pada subnet yang sama.

Tiga perkara mesti berlaku supaya carian berfungsi: klien menghalakan alamat penyelesai melalui terowong, gerbang menerima dan memajukan permintaan itu, dan penyelesai menerima sumber yang diterimanya. Balasan juga mesti kembali melalui laluan yang dipersetujui. Jika mana-mana satu tiada, gejalanya sama, sebab itu jadual alamat wajar ditulis sebelum menyentuh konfigurasi.

Tentukan alamat mana yang mesti dibawa oleh profil

Senaraikan destinasi mengikut urutan: rangkaian aplikasi, alamat penyelesai dan titik akhir awam yang menamatkan terowong itu sendiri. Yang ketiga tidak boleh sekali-kali dihalakan ke dalam terowong, kerana sambungan luar memerlukan laluan yang wujud sebelum terowong.

Sertakan UDP dan TCP untuk DNS, kerana pelaksanaan dijangka menyokong TCP bersama UDP, dan laluan TCP yang disekat menghasilkan kegagalan perlahan dan separa dan bukannya bersih. Jika zon peribadi juga dilayan melalui IPv6, pengecualian hos yang setara menggunakan alamat dan awalan IPv6 dan merupakan entri berasingan.

Catat apa yang sudah diliputi oleh profil sebelum menambah apa-apa. Laluan pendua tidak berbahaya, tetapi laluan sedia ada yang tidak dijangka memberitahu anda bahawa profil itu direka untuk pelan alamat yang berbeza daripada yang anda terima.

Tambah laluan hos melalui pemilik sambungan

Untuk profil Windows asli yang diurus secara setempat, laluan itu milik sambungan dan bukan jadual penghalakan global mesin. Pratonton penambahan terlebih dahulu, kemudian gunakannya dengan skop yang sama seperti yang digunakan oleh profil.

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

Perintah pertama mempratonton perubahan tanpa memasang apa-apa, dan yang kedua menyenaraikan laluan yang sedang dibawa oleh profil. Rujukan Add-VpnConnectionRoute daripada Microsoft mendokumenkan skop setiap pengguna dan semua pengguna; profil semua pengguna memerlukan parameter skopnya sendiri, dan perintah setiap pengguna terhadap profil semua pengguna gagal atau mendarat di tempat yang salah.

Apabila profil diurus atau datang daripada klien vendor, perubahan itu milik pemilik tersebut. Menimbun laluan sistem kekal di atas dasar sambungan berfungsi sehingga dasar itu digunakan semula dan laluan itu hilang, yang biasanya berlaku semasa panggilan sokongan dan bukan semasa ujian. Kegagalan itu senyap: laluan hilang, nama berhenti diselesaikan, dan tiada siapa menghubungkan kedua-dua peristiwa. Letakkan perubahan itu dalam rekod pemilik itu sendiri supaya penggunaan semula seterusnya membawanya dan bukannya memadamkannya.

Selepas menggunakan, sambung semula profil dan bukannya menganggap laluan itu telah berkuat kuasa. Perubahan laluan pada sambungan hidup tidak selalu diambil kira, dan menyambung semula juga menghasilkan semula keadaan yang sebenarnya akan dialami oleh pengguna anda.

Periksa penyelesai mana yang sebenarnya digunakan oleh klien

Laluan mengawal paket yang dialamatkan kepada penyelesai. Ia tidak menentukan nama mana yang harus dihantar ke sana, dan pemilihan itu ialah mekanisme berasingan. Dalam Windows, peraturan ruang nama yang berkesan boleh memilih penyelesai bagi setiap domain, manakala tetapan DNS profil memberikan nilai lalai. Kedua-dua lapisan ini boleh bercanggah tanpa menghasilkan sebarang ralat, sebab itu pertanyaan langsung hanyalah separuh bukti.

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

Perintah pertama mencetak dasar ruang nama yang berkuat kuasa, dan yang kedua bertanya kepada penyelesai peribadi secara langsung tentang nama aplikasi. Jawapan langsung membuktikan laluan dan penyelesai berfungsi; ia tidak membuktikan bahawa carian aplikasi itu sendiri memilih pelayan tersebut. Bandingkannya dengan carian biasa bagi nama yang sama dan dengan jawapan yang diterima oleh aplikasi.

Ambil kira cache dan DNS selamat peringkat pelayar, yang boleh memintas penyelesai sistem sepenuhnya untuk nama yang ditaip oleh pengguna. Akhiran carian ialah petunjuk palsu yang lain: ia mengembangkan nama pendek kepada nama yang layak sepenuhnya dan tiada kaitan dengan pelayan mana yang menjawab.

Akhiri dengan menyambung semula dan mengulangi carian biasa, kemudian sahkan pelayaran biasa masih mengikut dasarnya yang diluluskan. Menggantikan penyelesai peribadi dengan yang awam supaya nama yang tidak berkaitan dapat diselesaikan bukanlah pembetulan, dan ia memindahkan pertanyaan peribadi secara senyap ke tempat yang tidak pernah dimaksudkan.