Azure P2S VPN Tidak Dapat Menyelesaikan Nama Titik Akhir Peribadi

Anda menyambung terowong point-to-site, ping alamat peribadi, membuka aplikasi dan mendapat 403 atau ralat sijil. Kedua-dua gejala menunjuk kepada DNS, tetapi ia adalah kerosakan berbeza: satu bermaksud klien menyelesaikan alamat awam, satu lagi bermaksud ia menyelesaikan alamat peribadi dan kemudian menawarkan nama yang tidak dilindungi sijil. Lakukan semakan di bawah mengikut urutan dan berhenti pada kegagalan pertama, kerana entri hosts atau jawapan dalam cache boleh membuatkan setiap semakan kemudian lulus atas sebab yang salah. Saya menyimpan urutan ini dalam fail teks di sebelah profil VPN saya, kerana pembaikan tidak mengubah apa-apa pada terowong dan mengubah segala-galanya pada apa yang diketahui klien.

Mulakan dengan alamat yang benar-benar diterima klien

Tanya penyelesai secara langsung dan jangan percaya aplikasi. Pada Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net menunjukkan paparan mana yang diterima klien. Jawapan awam bermaksud tiada apa-apa di hilir akan sampai ke titik akhir; alamat peribadi titik akhir bermaksud DNS sudah selesai dan semakan seterusnya ialah sambungan itu sendiri.

Titik akhir peribadi tidak menukar nama perkhidmatan. Akaun atau aplikasi mengekalkan nama penuhnya yang biasa, dan titik akhir hanya menukar alamat yang nama itu diselesaikan untuk klien di dalam rangkaian maya. Itulah sebabnya nama hos yang sama diselesaikan secara peribadi dari VM dalam rangkaian dan secara awam dari komputer riba yang tidak pernah diberi paparan peribadi.

Semak zon, pautannya dan rekod sebelum terowong

Tiga syarat mesti dipenuhi serentak: zon peribadi wujud, ia dipautkan ke rangkaian maya tempat gerbang VPN dan klien memasuki Azure, dan ia mengandungi rekod A untuk titik akhir yang menunjuk ke alamat peribadi. Pautkan zon ke rangkaian tidak berkaitan dan gerbang akan terus menyelesaikan rekod awam sementara segala-galanya pada terowong kelihatan sihat.

Nama zon milik perkhidmatan, bukan pautan peribadi secara umum. App Service biasanya menggunakan privatelink.azurewebsites.net, storan dan SQL mempunyai ruang nama sendiri, dan meminjam zon perkhidmatan lain menghasilkan zon yang wujud tetapi tidak menjawab apa-apa yang berguna.

Beri klien penyelesai yang benar-benar boleh dicapainya

168.63.129.16 menjawab dari mesin maya Azure dan bukan pelayan DNS untuk komputer riba di seberang terowong point-to-site. Klien memerlukan penyelesai yang boleh dicapai melalui terowong: titik akhir masuk Azure DNS Private Resolver, pemaju dalam rangkaian maya, atau entri pelayan DNS yang dibawa dalam profil klien VPN supaya klien bertanya terus kepada rangkaian maya.

Penyelesai yang dikonfigurasikan tetapi tidak boleh dicapai berkelakuan sama seperti tiada penyelesai, dan gejalanya ialah tamat masa bukan jawapan salah, sebab itulah ia disalah baca sebagai masalah tembok api. Ujinya dengan pertanyaan yang sepatutnya dibawa terowong, bukan dengan nama awam yang akan berjaya melalui pautan tempatan juga.

Jika anda memajukan dan bukan menolak tetapan, majukan ruang nama yang dimiliki zon peribadi, privatelink.azurewebsites.net bukan seluruh azurewebsites.net. Pemaju bersyarat yang menelan seluruh akhiran induk menghantar setiap carian perkhidmatan ke Azure, termasuk yang sepatutnya kekal setempat.

Gunakan nama yang sijil dikeluarkan untuknya

Apabila alamat betul, kerosakan kedua muncul. Storan dan App Service menerbitkan alias privatelink, dan alias itu belum tentu nama dalam sijil. Muat naik AzCopy yang dialamatkan ke privatelink.blob.core.windows.net gagal pengesahan; muat naik yang sama ke <account>.blob.core.windows.net/<container> diselesaikan ke alamat peribadi dan lulus, jadi ia kekal di laluan peribadi tanpa sebarang pemintasan.

Peraturan ini terpakai dalam pelayar dan juga untuk App Service: sambung dengan nama hos yang dilindungi sijil dan biarkan DNS membekalkan alamat peribadi. Jangan cuba memintas pengesahan, kerana itu menukar kesilapan penamaan menjadi kemunduran keselamatan. Ping yang berjaya membuktikan laluan dan tidak berkata apa-apa tentang nama di dalam jabat tangan, sebab itulah ini kekal sebagai semakan berasingan.

Urutan empat langkah yang mengasingkan setiap lapisan

1. Sahkan klien VPN mempunyai alamat dari kumpulan point-to-site dan laluan ke alamat peribadi titik akhir.
2. Selesaikan nama tepat yang digunakan aplikasi dan bandingkan jawapan dengan alamat titik akhir.
3. Buka sambungan TCP ke titik akhir pada port perkhidmatan, kemudian baca nama sijil yang dibentangkan pada sambungan itu.
4. Baru sekarang uji kebenaran, kerana laluan yang berfungsi dan sijil yang sah masih tidak memberi akses kepada sumber.

Sambungan yang ditolak semasa alamat betul menunjuk kepada kumpulan keselamatan rangkaian atau keadaan sambungan titik akhir peribadi, bukan DNS, jadi semak itu sebelum mengedit tetapan penyelesai lagi. Ketidakpadanan nama TLS menghantar anda kembali ke nama hos dalam URL dan subject sijil. Simpan keluaran penyelesaian, nama sijil dan URL tepat bersama-sama; ketiga-tiga nilai itu menerangkan kebanyakan kes ini tanpa menyentuh gerbang.

Gunakan VM di dalam rangkaian maya sebagai kawalan. Jika nama diselesaikan secara peribadi di sana dan secara awam dari terowong, zon dan rekod betul dan satu-satunya perbezaan ialah laluan penyelesai klien, yang lebih cepat disahkan daripada satu lagi pusingan pada konfigurasi titik akhir.

Klien juga menyimpan cache. Rekod yang menjawab secara awam sepuluh minit lalu terus menjawab selepas anda membetulkan zon, jadi kosongkan cache sebelum menguji semula. Pada Windows, ipconfig /flushdns membersihkan cache klien; peraturan dasar penyelesaian nama kekal, menentukan akhiran mana pergi ke pelayan mana, dan boleh terus menghantar ruang nama ke penyelesai yang baru anda ganti.

Di mana entri hosts sepatutnya

Menambah alamat titik akhir ke fail hosts ialah diagnostik yang baik dan reka bentuk yang buruk. Ia membuktikan pemetaan nama-ke-alamat ialah bahagian yang hilang dan membolehkan anda menguji segala-galanya selepas langkah itu, tetapi ia tidak kelihatan kepada pengguna anda, rosak apabila alamat titik akhir berubah dan menyembunyikan zon yang sepatutnya menjawab.

Entri ujian yang tertinggal lebih buruk daripada cache lapuk, kerana ia boleh membuat laluan yang dibaiki kelihatan rosak atau laluan yang rosak kelihatan dibaiki bergantung pada arah ralat. Buangnya sebelum pusingan akhir dan selesaikan hanya dengan penyelesai pengeluaran.

Nama pendek memerlukan akhiran carian dan nama penuh tidak, jadi uji nama penuh dahulu, kemudian putuskan sama ada aliran kerja memerlukan akhiran yang ditolak melalui profil klien. Microsoft mendokumenkan nama zon dan bentuk rekod bagi setiap perkhidmatan dalam panduan DNS titik akhir peribadi mereka; baca entri untuk perkhidmatan anda dan jangan salin zon daripada perkhidmatan lain.