Kde jsou protokoly Azure Point-to-Site VPN? Podívejte se do Monitoru

Uživatel se nemůže připojit k bráně Point-to-Site, otevřete okno brány a na stránce nikde není historie připojení. Konfigurace, certifikáty, stav: vše přítomno, žádné záznamy. Protokoly existují, ale síťové stránky je vůbec nevytvářejí. Pocházejí z diagnostického nastavení připojeného k prostředku brány a toto nastavení žije v Monitoru; proto první hledání na očividném místě nic nevrátí a lidé usoudí, že služba nevede žádnou auditní stopu.

Proč očividné hledání selhává

Starší návody tvrdí, že Azure Point-to-Site VPN nemá audit, a to platilo, když služba neposkytovala žádný záznam pro jednotlivé připojení. Současné brány publikují diagnostické záznamy tunelu, takže užitečná otázka se změnila: ne zda protokoly existují, ale který prostředek je vydává a kterou kategorii jste zapnuli. Okno brány je konfigurační plocha a konfigurační plochy jen zřídka slouží zároveň jako prohlížeče protokolů. Diagnostické nastavení je objekt pro každý prostředek, takže zvolený prostředek určuje vše, co následuje.

Druhá polovina zmatku je autentizace. Připojení Point-to-Site založená na certifikátech negenerují událost přihlášení pro jednotlivého uživatele jako poskytovatel identity, takže neexistuje záznam o jmenované osobě, která by zadávala heslo.

Připojte diagnostické nastavení k prostředku brány

Otevřete Monitor, potom Diagnostic settings a přidejte nové nastavení, jehož cílem je samotná brána virtuální sítě, nikoli virtuální síť, která ji obsahuje. Vyberte diagnostickou kategorii Point-to-Site, tu s názvem P2SDiagnosticLog, protože ta nese záznamy o připojení pro jednotlivé klienty; kategorie tunelu, trasy nebo IKE přidávejte jen pro chyby site-to-site, které pokrývají. Poté odešlete data do pracovního prostoru Log Analytics, který ovládáte, s dobou uchování, kterou jste zvolili záměrně. Většina neúspěšných hledání je nastavení připojené ke špatnému prostředku, nikoli chybějící funkce.

Seznamy kategorií se liší podle typu a generace brány. Pokud kategorie Point-to-Site chybí, brána může být starší než funkce nebo běží na SKU, který ji nikdy nevydává, takže před hledáním problému s oprávněními zkontrolujte podporované kategorie. Brána bez kategorie Point-to-Site není rozbitá; prostě nemůže být zdrojem tohoto záznamu a nejbližší náhradou je kategorie tunelu nebo IKE, která zaznamenává adresu klienta, i když nepopisuje relaci Point-to-Site. Potvrďte seznam kategorií, než otevřete případ podpory ohledně chybějících protokolů.

Čtěte záznamy v tabulce, kterou používá váš režim

Ve starším režimu shromažďování položky končí v tabulce AzureDiagnostics a kategorie se objeví jako hodnota sloupce; u tabulek specifických pro prostředek má brána vlastní tabulku. V obou případech dotazujte podle prostředku brány a časového okna kolem neúspěšného pokusu a poté čtěte korelaci místo jednotlivých řádků:

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

Sada sloupců se řídí vaším režimem shromažďování, takže dotaz berte jako tvar, nikoli jako skript. Hledáte adresu klienta, která se objeví a poté zmizí, s typem výsledku, který není úspěch.

Spojte záznam brány s vlastním pohledem klienta

Protokoly brány popisují tunel, ne proč notebook nedokázal nějaký vytvořit. Shromážděte stranu klienta ve stejném časovém razítku: protokol událostí Windows pro klienta RAS, protokol připojení macOS nebo text chyby, který zobrazila klientská aplikace. Záznam brány bez odpovídajícího pokusu klienta ukazuje na klienta; klient hlásící úspěch, zatímco brána nic nezaznamenává, obvykle znamená, že profil míří na jinou bránu.

Udržujte obě poloviny ve stejném tiketu. Samotný protokol brány svádí k nesprávnému závěru a samotný protokol klienta nemůže ukázat, zda paket vůbec dorazil.

Pokud se nic neobjeví na žádném místě, zkontrolujte hodiny klienta, než začnete pochybovat o platformě. Zkreslená časová razítka způsobí, že korelace selže způsobem, který vypadá přesně jako chybějící data.

Uchovávání, rozsah a zápis do runbooku

Záznamy tunelu nesou adresy klientů a časová razítka připojení, takže k nim přistupujte jako k osobním údajům s plánem výmazu, místo abyste ponechali výchozí nastavení platformy. Zkontrolujte také, že pracovní prostor nepřijímá všechny kategorie ze všech prostředků v předplatném, protože hlučný pracovní prostor dělá korelaci pomalejší než přímé čtení klientského protokolu.

Nakonec zapište název nastavení, pracovní prostor a zvolené kategorie do runbooku brány. Další člověk, který bude ladit klienta, se nejprve podívá do okna brány, nic nenajde a usoudí, že protokoly neexistují.