Hol vannak az Azure Point-to-Site VPN naplói? Nézze meg a Monitorban

Egy felhasználó nem tud csatlakozni a Point-to-Site gatewayhez, megnyitja a gateway panelt, és sehol nincs kapcsolati előzmény az oldalon. Konfiguráció, tanúsítványok, állapot: minden megvan, rekordok nincsenek. A naplók léteznek, de a hálózati oldalak egyáltalán nem állítják elő őket. Egy diagnosztikai beállításból származnak, amely a gateway erőforráshoz van csatolva, és ez a beállítás a Monitor alatt él; ezért az első keresés a nyilvánvaló helyen semmit sem ad vissza, és az emberek arra jutnak, hogy a szolgáltatás nem vezet auditnyomot.

Miért vall kudarcot a nyilvánvaló keresés

A régebbi útmutatók szerint az Azure Point-to-Site VPN-nek nincs auditja, és ez akkor volt igaz, amikor a szolgáltatás nem tett közzé kapcsolatonkénti rekordot. A jelenlegi gatewayek közzéteszik az alagút diagnosztikai rekordjait, ezért a hasznos kérdés megváltozott: nem az, hogy vannak-e naplók, hanem hogy melyik erőforrás bocsátja ki őket, és melyik kategóriát kapcsolta be. A gateway panel konfigurációs felület, és a konfigurációs felületek ritkán szolgálnak egyben naplómegjelenítőként is. A diagnosztikai beállítás erőforrásonkénti objektum, ezért a választott erőforrás határozza meg mindazt, ami következik.

A zavar másik fele a hitelesítés. A tanúsítványalapú Point-to-Site kapcsolatok nem generálnak felhasználónkénti bejelentkezési eseményt, mint egy identitásszolgáltató, ezért nincs rekord egy megnevezett személyről, aki jelszót gépel.

Csatolja a diagnosztikai beállítást a gateway erőforráshoz

Nyissa meg a Monitort, majd a Diagnostic settings oldalt, és adjon hozzá új beállítást, amelynek célja maga a virtuális hálózati gateway, nem pedig az őt tartalmazó virtuális hálózat. Válassza a Point-to-Site diagnosztikai kategóriát, a P2SDiagnosticLog nevűt, mert az hordozza az ügyfelenkénti kapcsolati rekordokat; az alagút, az útvonal vagy az IKE kategóriákat csak az általuk lefedett site-to-site hibákhoz adja hozzá. Ezután küldje az adatokat egy Ön által irányított Log Analytics-munkaterületre, szándékosan választott megőrzési idővel. A sikertelen keresések többsége rossz erőforráshoz csatolt beállítás, nem hiányzó funkció.

A kategórialisták a gateway típusa és generációja szerint eltérnek. Ha a Point-to-Site kategória hiányzik, a gateway lehet régebbi a funkciónál, vagy olyan SKU-n fut, amely soha nem bocsátja ki, ezért ellenőrizze a támogatott kategóriákat, mielőtt engedélyproblémát keresne. A Point-to-Site kategória nélküli gateway nem hibás; egyszerűen nem lehet az adott rekord forrása, és a legközelebbi helyettesítő az alagút vagy az IKE kategória, amely rögzíti az ügyfél címét, bár nem ír le Point-to-Site munkamenetet. Erősítse meg a kategórialistát, mielőtt támogatási esetet nyit a hiányzó naplók miatt.

Olvassa a rekordokat abban a táblában, amelyet a módja használ

A régi gyűjtési módban a bejegyzések az AzureDiagnostics táblába kerülnek, és a kategória oszlopértékként jelenik meg; az erőforrás-specifikus táblákban a gatewaynek saját táblája van. Mindkét esetben a gateway erőforrásra és a sikertelen kísérlet körüli időablakra kérdezzen, majd a korrelációt olvassa az egyes sorok helyett:

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

Az oszlopkészlet a gyűjtési módját követi, ezért a lekérdezést formaként kezelje, ne szkriptként. Amit keres, az egy ügyfélcím, amely megjelenik, majd eltűnik, olyan eredménytípussal, amely nem siker.

Párosítsa a gateway rekordját az ügyfél saját nézetével

A gateway naplói az alagutat írják le, nem azt, hogy egy laptop miért nem tudott építeni egyet. Gyűjtse össze az ügyfél oldalát ugyanazon időbélyeg mellett: a Windows eseménynaplóját a RAS-ügyfélhez, a macOS kapcsolati naplóját vagy a hiba szövegét, amelyet az ügyfélalkalmazás megjelenített. Az ügyfél kísérlete nélküli gateway rekord az ügyfélre mutat; ha az ügyfél sikerről számol be, miközben a gateway semmit sem rögzít, az általában azt jelenti, hogy a profil egy másik gatewayre irányul.

Tartsa mindkét felet ugyanabban a jegyben. Egyedül a gateway naplója rossz következtetésre csábít, és egyedül az ügyfél naplója nem mutatja meg, hogy a csomag valaha megérkezett-e.

Ha egyik helyen sem jelenik meg semmi, ellenőrizze az ügyfél óráját, mielőtt a platformot kérdőjelezné meg. A ferde időbélyegek miatt a korreláció úgy vall kudarcot, hogy pontosan hiányzó adatoknak tűnik.

Megőrzés, hatókör és a runbook-bejegyzés

Az alagútrekordok ügyfélcímeket és kapcsolati időbélyegeket hordoznak, ezért személyes adatként kezelje őket törlési ütemtervvel, ahelyett hogy a platform alapértelmezését hagyná meg. Azt is ellenőrizze, hogy a munkaterület nem szívja be az előfizetés minden erőforrásának minden kategóriáját, mert a zajos munkaterület lassabbá teszi a korrelációt, mint az ügyfélnapló közvetlen olvasása.

Végül írja be a beállítás nevét, a munkaterületet és a kiválasztott kategóriákat a gateway runbookjába. A következő ember, aki egy ügyfelet hibakeres, először a gateway panelre néz, nem talál semmit, és arra jut, hogy a naplók nem léteznek.