Di manakah log Azure Point-to-Site VPN? Lihat dalam Monitor

Pengguna tidak dapat menyambung ke gateway Point-to-Site, anda membuka bilah gateway, dan tiada sejarah sambungan di mana-mana pada halaman. Konfigurasi, sijil, status: semuanya ada, tiada rekod. Log itu wujud, tetapi halaman rangkaian tidak menghasilkannya sama sekali. Ia datang daripada tetapan diagnostik yang dilampirkan pada sumber gateway, dan tetapan itu tinggal di bawah Monitor; sebab itu carian pertama di tempat yang jelas tidak mengembalikan apa-apa, dan orang membuat kesimpulan bahawa perkhidmatan itu tidak menyimpan sebarang jejak audit.

Mengapa carian yang jelas gagal

Panduan lama menyatakan bahawa Azure Point-to-Site VPN tidak mempunyai audit, dan itu benar apabila perkhidmatan tidak mendedahkan sebarang rekod bagi setiap sambungan. Gateway semasa menerbitkan rekod diagnostik terowong, jadi soalan yang berguna berubah: bukan sama ada log wujud, tetapi sumber mana yang mengeluarkannya dan kategori mana yang anda hidupkan. Bilah gateway ialah permukaan konfigurasi, dan permukaan konfigurasi jarang berfungsi juga sebagai pemapar log. Tetapan diagnostik ialah objek bagi setiap sumber, jadi sumber yang anda pilih menentukan semua yang berikutnya.

Separuh lagi kekeliruan ialah pengesahan. Sambungan Point-to-Site berasaskan sijil tidak menjana peristiwa log masuk bagi setiap pengguna seperti yang dilakukan penyedia identiti, jadi tiada rekod tentang orang bernama yang menaip kata laluan.

Lampirkan tetapan diagnostik pada sumber gateway

Buka Monitor, kemudian Diagnostic settings, dan tambah tetapan baharu yang sasarannya ialah gateway rangkaian maya itu sendiri dan bukan rangkaian maya yang mengandunginya. Pilih kategori diagnostik Point-to-Site, yang bernama P2SDiagnosticLog, kerana itulah yang membawa rekod sambungan bagi setiap klien; tambah kategori terowong, laluan atau IKE hanya untuk ralat site-to-site yang diliputinya. Kemudian hantar data ke ruang kerja Log Analytics yang anda kawal, dengan tempoh pengekalan yang anda pilih dengan sengaja. Kebanyakan carian yang gagal ialah tetapan yang dilampirkan pada sumber yang salah, bukan ciri yang hilang.

Senarai kategori berbeza mengikut jenis dan generasi gateway. Jika kategori Point-to-Site tiada, gateway mungkin lebih lama daripada ciri itu atau menjalankan SKU yang tidak pernah mengeluarkannya, jadi semak kategori yang disokong sebelum mencari masalah kebenaran. Gateway tanpa kategori Point-to-Site tidak rosak; ia semata-mata tidak boleh menjadi sumber rekod itu, dan pengganti terdekat ialah kategori terowong atau IKE, yang merekodkan alamat klien walaupun ia tidak menerangkan sesi Point-to-Site. Sahkan senarai kategori sebelum anda membuka kes sokongan tentang log yang hilang.

Baca rekod dalam jadual yang digunakan oleh mod anda

Dalam mod pengumpulan lama, entri masuk ke jadual AzureDiagnostics dan kategori muncul sebagai nilai lajur; dengan jadual khusus sumber, gateway mempunyai jadualnya sendiri. Dalam apa jua keadaan, buat pertanyaan mengikut sumber gateway dan tetingkap masa sekitar percubaan yang gagal, kemudian baca korelasi dan bukan baris individu:

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc

Set lajur mengikut mod pengumpulan anda, jadi anggap pertanyaan itu sebagai bentuk dan bukan skrip. Apa yang anda cari ialah alamat klien yang muncul dan kemudian hilang, dengan jenis hasil yang bukan kejayaan.

Pasangkan rekod gateway dengan pandangan klien sendiri

Log gateway menerangkan terowong, bukan mengapa komputer riba gagal membinanya. Kumpulkan bahagian klien pada cap masa yang sama: log peristiwa Windows untuk klien RAS, log sambungan macOS, atau teks ralat yang dipaparkan oleh aplikasi klien. Rekod gateway tanpa percubaan klien yang sepadan menunjukkan klien; klien yang melaporkan kejayaan sementara gateway tidak merekodkan apa-apa biasanya bermaksud profil ditujukan kepada gateway lain.

Simpan kedua-dua bahagian dalam tiket yang sama. Log gateway sahaja mengundang kesimpulan yang salah, dan log klien sahaja tidak dapat menunjukkan sama ada paket itu pernah tiba.

Jika tiada apa-apa muncul di kedua-dua tempat, semak jam pada klien sebelum meragui platform. Cap masa yang condong membuat korelasi gagal dengan cara yang kelihatan sama seperti data yang hilang.

Pengekalan, skop dan entri runbook

Rekod terowong membawa alamat klien dan cap masa sambungan, jadi perlakukan ia sebagai data peribadi dengan jadual pemadaman dan bukannya membiarkan nilai lalai platform. Semak juga bahawa ruang kerja tidak mengambil setiap kategori daripada setiap sumber dalam langganan, kerana ruang kerja yang bising menjadikan korelasi lebih perlahan daripada membaca log klien secara langsung.

Akhir sekali, tulis nama tetapan, ruang kerja dan kategori yang dipilih ke dalam runbook gateway. Orang seterusnya yang menyahpepijat klien akan melihat bilah gateway dahulu, tidak menemui apa-apa, dan membuat kesimpulan bahawa log itu tidak wujud.