Azure P2S VPN Tidak Dapat Menyelesaikan Nama Endpoint Privat

Anda menyambungkan tunnel point-to-site, melakukan ping ke alamat privat, membuka aplikasi, lalu mendapat 403 atau kesalahan sertifikat. Kedua gejala menunjuk ke DNS, tetapi keduanya kesalahan yang berbeda: yang satu berarti klien menyelesaikan alamat publik, yang lain berarti klien menyelesaikan alamat privat lalu menawarkan nama yang tidak dicakup sertifikat. Jalankan pemeriksaan di bawah secara berurutan dan berhenti pada kegagalan pertama, karena entri hosts atau jawaban yang tersimpan di cache dapat membuat setiap pemeriksaan berikutnya lolos karena alasan yang salah. Saya menyimpan urutan ini di berkas teks di samping profil VPN saya, karena perbaikannya tidak mengubah apa pun pada tunnel dan mengubah segalanya pada apa yang diketahui klien.

Mulailah dari alamat yang benar-benar diterima klien

Tanyakan langsung ke resolver alih-alih memercayai aplikasi. Di Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net menunjukkan tampilan mana yang diterima klien. Jawaban publik berarti tidak ada apa pun di hilir yang akan mencapai endpoint; alamat privat endpoint berarti DNS sudah selesai dan pemeriksaan berikutnya adalah koneksinya sendiri.

Endpoint privat tidak mengganti nama layanan. Akun atau aplikasi tetap memakai nama lengkapnya yang biasa, dan endpoint hanya mengubah alamat tempat nama itu diselesaikan bagi klien di dalam jaringan virtual. Itulah sebabnya nama host yang sama diselesaikan secara privat dari VM di jaringan dan secara publik dari laptop yang tidak pernah diberi tampilan privat.

Periksa zona, tautannya, dan record sebelum tunnel

Tiga syarat harus terpenuhi bersama: zona privat ada, zona itu tertaut ke jaringan virtual tempat gateway VPN dan klien masuk ke Azure, dan zona itu memuat record A untuk endpoint yang menunjuk ke alamat privat. Tautkan zona ke jaringan yang tidak terkait dan gateway akan terus menyelesaikan record publik sementara segala hal tentang tunnel masih terlihat sehat.

Nama zona milik layanan, bukan milik tautan privat secara umum. App Service biasanya memakai privatelink.azurewebsites.net, penyimpanan dan SQL punya ruang nama sendiri, dan meminjam zona layanan lain menghasilkan zona yang ada tetapi tidak menjawab apa pun yang berguna.

Beri klien resolver yang benar-benar dapat dijangkau

168.63.129.16 menjawab dari mesin virtual Azure dan bukan server DNS untuk laptop di seberang tunnel point-to-site. Klien memerlukan resolver yang dapat dijangkau melalui tunnel: endpoint masuk Azure DNS Private Resolver, penerus di dalam jaringan virtual, atau entri server DNS yang dibawa dalam profil klien VPN agar klien bertanya langsung ke jaringan virtual.

Resolver yang dikonfigurasi tetapi tidak dapat dijangkau berperilaku persis seperti tidak ada resolver, dan gejalanya adalah timeout bukan jawaban salah, itulah sebabnya ini salah dibaca sebagai masalah firewall. Ujilah dengan kueri yang seharusnya dibawa tunnel, bukan dengan nama publik yang toh akan berhasil melalui tautan lokal.

Jika Anda meneruskan alih-alih mendorong pengaturan, teruskan ruang nama yang dimiliki zona privat, privatelink.azurewebsites.net bukan seluruh azurewebsites.net. Penerus bersyarat yang menelan seluruh sufiks induk mengirim setiap pencarian layanan ke Azure, termasuk yang seharusnya tetap lokal.

Gunakan nama yang menjadi tujuan penerbitan sertifikat

Begitu alamatnya benar, kesalahan kedua muncul. Penyimpanan dan App Service menerbitkan alias privatelink, dan alias itu belum tentu nama di dalam sertifikat. Unggahan AzCopy yang dialamatkan ke privatelink.blob.core.windows.net gagal validasi; unggahan yang sama ke <account>.blob.core.windows.net/<container> diselesaikan ke alamat privat dan lolos, sehingga tetap di jalur privat tanpa penimpaan.

Aturan ini berlaku di peramban dan juga untuk App Service: sambungkan dengan nama host yang dicakup sertifikat dan biarkan DNS menyediakan alamat privat. Jangan menempuh jalan memintas validasi, karena itu mengubah kesalahan penamaan menjadi kemunduran keamanan. Ping yang berhasil membuktikan rute dan tidak mengatakan apa pun tentang nama di dalam jabat tangan, itulah sebabnya ini tetap pemeriksaan terpisah.

Urutan empat langkah yang mengisolasi setiap lapisan

1. Pastikan klien VPN memiliki alamat dari kumpulan point-to-site dan rute ke alamat privat endpoint.
2. Selesaikan nama persis yang dipakai aplikasi dan bandingkan jawabannya dengan alamat endpoint.
3. Buka koneksi TCP ke endpoint pada port layanan, lalu baca nama sertifikat yang disajikan pada koneksi itu.
4. Baru sekarang uji otorisasi, karena jalur yang berfungsi dan sertifikat yang valid tetap tidak memberi akses ke sumber daya.

Koneksi yang ditolak saat alamatnya benar menunjuk ke grup keamanan jaringan atau status koneksi endpoint privat, bukan ke DNS, jadi periksa keduanya sebelum menyunting pengaturan resolver lagi. Ketidakcocokan nama TLS mengembalikan Anda ke nama host di URL dan ke subject sertifikat. Simpan keluaran penyelesaian, nama sertifikat, dan URL persisnya bersama-sama; ketiga nilai itu menjelaskan sebagian besar kasus ini tanpa menyentuh gateway.

Gunakan VM di dalam jaringan virtual sebagai kontrol. Jika nama diselesaikan secara privat di sana dan secara publik dari tunnel, zona dan record-nya benar dan satu-satunya perbedaan adalah jalur resolver klien, yang lebih cepat dipastikan daripada sekali lagi menelusuri konfigurasi endpoint.

Klien juga menyimpan cache. Record yang menjawab secara publik sepuluh menit lalu tetap menjawab setelah Anda memperbaiki zona, jadi bersihkan cache sebelum menguji ulang. Di Windows, ipconfig /flushdns membersihkan cache klien; aturan kebijakan penyelesaian nama tetap ada, menentukan sufiks mana menuju server mana, dan dapat terus mengirim ruang nama ke resolver yang baru saja Anda ganti.

Di mana entri hosts seharusnya berada

Menambahkan alamat endpoint ke berkas hosts adalah diagnostik yang baik dan desain yang buruk. Itu membuktikan pemetaan nama ke alamat adalah bagian yang hilang dan memungkinkan Anda menguji segala hal setelah langkah itu, tetapi tidak terlihat oleh pengguna Anda, rusak saat alamat endpoint berubah, dan menyembunyikan zona yang seharusnya menjawab.

Entri uji yang tertinggal lebih buruk daripada cache basi, karena dapat membuat jalur yang sudah diperbaiki tampak rusak atau jalur yang rusak tampak diperbaiki bergantung pada arah kesalahannya. Hapus entri itu sebelum putaran terakhir dan selesaikan hanya dengan resolver produksi.

Nama pendek memerlukan sufiks pencarian dan nama lengkap tidak, jadi uji dulu nama lengkapnya, lalu putuskan apakah alur kerja memerlukan sufiks yang didorong melalui profil klien. Microsoft mendokumentasikan nama zona dan bentuk record per layanan di panduan DNS endpoint privat mereka; bacalah entri untuk layanan Anda alih-alih menyalin zona dari layanan lain.