Azure Point-to-Site VPN günlükleri nerede? Monitor'a bakın

Bir kullanıcı Point-to-Site ağ geçidine bağlanamıyor, ağ geçidi dikey penceresini açıyorsunuz ve sayfanın hiçbir yerinde bağlantı geçmişi yok. Yapılandırma, sertifikalar, durum: hepsi var, kayıt yok. Günlükler var, ancak ağ sayfaları tarafından hiç üretilmiyor. Ağ geçidi kaynağına bağlı bir tanılama ayarından geliyorlar ve bu ayar Monitor altında yaşıyor; bu yüzden bariz yerdeki ilk arama hiçbir şey döndürmez ve insanlar hizmetin hiçbir denetim izi tutmadığı sonucuna varır.

Bariz arama neden başarısız olur

Eski kılavuzlar Azure Point-to-Site VPN'de denetim olmadığını söyler ve bu, hizmet bağlantı başına kayıt sunmadığında doğruydu. Günümüz ağ geçitleri tünel tanılama kayıtlarını yayımlar, bu nedenle yararlı soru değişti: günlükler var mı değil, hangi kaynak bunları yayımlıyor ve hangi kategoriyi açtınız. Ağ geçidi dikey penceresi bir yapılandırma yüzeyidir ve yapılandırma yüzeyleri nadiren günlük görüntüleyici olarak da hizmet eder. Tanılama ayarı kaynak başına bir nesnedir, bu yüzden seçtiğiniz kaynak sonraki her şeyi belirler.

Karışıklığın diğer yarısı kimlik doğrulamadır. Sertifika tabanlı Point-to-Site bağlantıları, bir kimlik sağlayıcısının yaptığı gibi kullanıcı başına oturum açma olayı üretmez, bu nedenle parola yazan adlı bir kişinin kaydı bulunmaz.

Tanılama ayarını ağ geçidi kaynağına bağlayın

Monitor'u, ardından Diagnostic settings'i açın ve hedefi onu içeren sanal ağ değil, sanal ağ geçidinin kendisi olan yeni bir ayar ekleyin. P2SDiagnosticLog adlı Point-to-Site tanılama kategorisini seçin, çünkü istemci başına bağlantı kayıtlarını o taşır; tünel, rota veya IKE kategorilerini yalnızca kapsadıkları site-to-site hataları için ekleyin. Ardından verileri kontrol ettiğiniz bir Log Analytics çalışma alanına, bilerek seçtiğiniz saklama süresiyle gönderin. Başarısız aramaların çoğu yanlış kaynağa bağlanmış bir ayardır, eksik bir özellik değil.

Kategori listeleri ağ geçidi türüne ve nesline göre değişir. Point-to-Site kategorisi yoksa ağ geçidi bu özellikten daha eski olabilir veya onu hiç yayımlamayan bir SKU çalıştırıyor olabilir, bu nedenle izin sorunu aramadan önce desteklenen kategorileri kontrol edin. Point-to-Site kategorisi olmayan bir ağ geçidi bozuk değildir; yalnızca o kaydın kaynağı olamaz ve en yakın yedek tünel veya IKE kategorisidir, o da Point-to-Site oturumunu açıklamasa da istemci adresini kaydeder. Eksik günlükler hakkında bir destek vakası açmadan önce kategori listesini doğrulayın.

Kayıtları modunuzun kullandığı tabloda okuyun

Eski toplama modunda girişler AzureDiagnostics tablosuna düşer ve kategori sütun değeri olarak görünür; kaynağa özgü tablolarda ağ geçidinin kendi tablosu vardır. Her durumda, ağ geçidi kaynağına ve başarısız denemenin etrafındaki zaman penceresine göre sorgulayın, ardından tek tek satırlar yerine bağıntıyı okuyun:

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

Sütun kümesi toplama modunuzu izler, bu nedenle sorguyu komut dosyası değil bir şekil olarak ele alın. Aradığınız şey, görünüp sonra kaybolan bir istemci adresi ve başarı olmayan bir sonuç türüdür.

Ağ geçidi kaydını istemcinin kendi görünümüyle eşleştirin

Ağ geçidi günlükleri tüneli tanımlar, bir dizüstü bilgisayarın neden bir tünel kuramadığını değil. İstemci tarafını aynı zaman damgasında toplayın: RAS istemcisi için Windows olay günlüğü, macOS bağlantı günlüğü veya istemci uygulamasının gösterdiği hata metni. Eşleşen istemci denemesi olmayan bir ağ geçidi kaydı istemciye işaret eder; istemci başarı bildirirken ağ geçidi hiçbir şey kaydetmiyorsa bu genellikle profilin başka bir ağ geçidine yöneldiği anlamına gelir.

Her iki yarıyı aynı bilette tutun. Yalnızca ağ geçidi günlüğü yanlış sonuca davet eder ve yalnızca istemci günlüğü paketin hiç ulaşıp ulaşmadığını gösteremez.

İki yerde de hiçbir şey görünmüyorsa, platformdan şüphe etmeden önce istemcinin saatini kontrol edin. Çarpık zaman damgaları bağıntıyı tam olarak eksik veri gibi görünen bir şekilde başarısız kılar.

Saklama, kapsam ve runbook girdisi

Tünel kayıtları istemci adreslerini ve bağlantı zaman damgalarını taşır, bu nedenle bunları platformun varsayılanını bırakmak yerine silme takvimi olan kişisel veri olarak ele alın. Çalışma alanının abonelikteki her kaynaktan her kategoriyi almadığını da kontrol edin, çünkü gürültülü bir çalışma alanı bağıntıyı istemci günlüğünü doğrudan okumaktan daha yavaş yapar.

Son olarak, ayarın adını, çalışma alanını ve seçilen kategorileri ağ geçidinin runbook'una yazın. Bir istemcide hata ayıklayacak sonraki kişi önce ağ geçidi dikey penceresine bakar, hiçbir şey bulamaz ve günlüklerin var olmadığı sonucuna varır.