Di mana log Azure Point-to-Site VPN? Lihat di Monitor

Pengguna tidak dapat terhubung ke gateway Point-to-Site, Anda membuka bilah gateway, dan tidak ada riwayat koneksi di mana pun pada halaman. Konfigurasi, sertifikat, status: semuanya ada, tidak ada catatan. Log itu ada, tetapi halaman jaringan sama sekali tidak menghasilkannya. Log berasal dari pengaturan diagnostik yang terlampir pada sumber daya gateway, dan pengaturan itu berada di bawah Monitor; itulah sebabnya pencarian pertama di tempat yang jelas tidak mengembalikan apa pun, dan orang menyimpulkan bahwa layanan tidak menyimpan jejak audit.

Mengapa pencarian yang jelas gagal

Panduan lama menyatakan bahwa Azure Point-to-Site VPN tidak memiliki audit, dan itu benar ketika layanan tidak mengekspos catatan per koneksi. Gateway saat ini menerbitkan catatan diagnostik terowongan, jadi pertanyaan yang berguna berubah: bukan apakah log ada, melainkan sumber daya mana yang memancarkannya dan kategori mana yang Anda aktifkan. Bilah gateway adalah permukaan konfigurasi, dan permukaan konfigurasi jarang juga berfungsi sebagai penampil log. Pengaturan diagnostik adalah objek per sumber daya, jadi sumber daya yang Anda pilih menentukan semua yang berikutnya.

Separuh kebingungan lainnya adalah autentikasi. Koneksi Point-to-Site berbasis sertifikat tidak menghasilkan peristiwa masuk per pengguna seperti yang dilakukan penyedia identitas, jadi tidak ada catatan tentang orang bernama yang mengetik kata sandi.

Lampirkan pengaturan diagnostik ke sumber daya gateway

Buka Monitor, lalu Diagnostic settings, dan tambahkan pengaturan baru yang targetnya adalah gateway jaringan virtual itu sendiri, bukan jaringan virtual yang memuatnya. Pilih kategori diagnostik Point-to-Site, yang bernama P2SDiagnosticLog, karena itulah yang membawa catatan koneksi per klien; tambahkan kategori terowongan, rute, atau IKE hanya untuk kesalahan site-to-site yang dicakupnya. Lalu kirim data ke ruang kerja Log Analytics yang Anda kendalikan, dengan periode retensi yang Anda pilih dengan sengaja. Sebagian besar pencarian yang gagal adalah pengaturan yang terlampir pada sumber daya yang salah, bukan fitur yang hilang.

Daftar kategori berbeda menurut jenis dan generasi gateway. Jika kategori Point-to-Site tidak ada, gateway mungkin lebih tua dari fitur tersebut atau menjalankan SKU yang tidak pernah memancarkannya, jadi periksa kategori yang didukung sebelum mencari masalah izin. Gateway tanpa kategori Point-to-Site tidak rusak; gateway itu tidak dapat menjadi sumber catatan tersebut, dan pengganti terdekat adalah kategori terowongan atau IKE, yang mencatat alamat klien meskipun tidak menjelaskan sesi Point-to-Site. Konfirmasi daftar kategori sebelum Anda membuka kasus dukungan tentang log yang hilang.

Baca catatan di tabel yang digunakan mode Anda

Dengan mode pengumpulan lama, entri masuk ke tabel AzureDiagnostics dan kategori muncul sebagai nilai kolom; dengan tabel khusus sumber daya, gateway memiliki tabelnya sendiri. Bagaimanapun, kueri berdasarkan sumber daya gateway dan jendela waktu di sekitar upaya yang gagal, lalu baca korelasinya, bukan baris individual:

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

Himpunan kolom mengikuti mode pengumpulan Anda, jadi perlakukan kueri sebagai bentuk, bukan skrip. Yang Anda cari adalah alamat klien yang muncul lalu menghilang, dengan jenis hasil yang bukan keberhasilan.

Pasangkan catatan gateway dengan pandangan klien sendiri

Log gateway menjelaskan terowongan, bukan mengapa laptop gagal membangunnya. Kumpulkan sisi klien pada stempel waktu yang sama: log peristiwa Windows untuk klien RAS, log koneksi macOS, atau teks kesalahan yang ditampilkan aplikasi klien. Catatan gateway tanpa upaya klien yang cocok menunjuk ke klien; klien yang melaporkan keberhasilan sementara gateway tidak mencatat apa pun biasanya berarti profil diarahkan ke gateway lain.

Simpan kedua bagian dalam tiket yang sama. Log gateway saja mengundang kesimpulan yang salah, dan log klien saja tidak dapat menunjukkan apakah paket itu pernah tiba.

Jika tidak ada yang muncul di kedua tempat, periksa jam pada klien sebelum meragukan platform. Stempel waktu yang miring membuat korelasi gagal dengan cara yang tampak persis seperti data yang hilang.

Retensi, cakupan, dan entri runbook

Catatan terowongan membawa alamat klien dan stempel waktu koneksi, jadi perlakukan sebagai data pribadi dengan jadwal penghapusan alih-alih membiarkan default platform. Periksa juga bahwa ruang kerja tidak menyerap setiap kategori dari setiap sumber daya dalam langganan, karena ruang kerja yang bising membuat korelasi lebih lambat daripada membaca log klien secara langsung.

Terakhir, tulis nama pengaturan, ruang kerja, dan kategori yang dipilih ke runbook gateway. Orang berikutnya yang men-debug klien akan melihat bilah gateway lebih dulu, tidak menemukan apa pun, dan menyimpulkan bahwa log tidak ada.