Waar zijn de Azure Point-to-Site VPN-logboeken? Kijk in Monitor

Een gebruiker kan geen verbinding maken met de Point-to-Site-gateway, u opent de gatewayblade en er staat nergens op de pagina een verbindingsgeschiedenis. Configuratie, certificaten, status: alles aanwezig, geen records. De logboeken bestaan, maar ze worden helemaal niet door de netwerkpagina's geproduceerd. Ze komen uit een diagnostische instelling die aan de gatewayresource is gekoppeld, en die instelling leeft onder Monitor; daarom levert de eerste zoekopdracht op de voor de hand liggende plek niets op, en mensen concluderen dat de service geen audittrail bijhoudt.

Waarom de voor de hand liggende zoekopdracht mislukt

Oudere richtlijnen stellen dat Azure Point-to-Site VPN geen auditing heeft, en dat klopte toen de service geen record per verbinding beschikbaar stelde. Huidige gateways publiceren diagnostische tunnelrecords, dus de nuttige vraag veranderde: niet of er logboeken zijn, maar welke resource ze uitzendt en welke categorie u hebt ingeschakeld. De gatewayblade is een configuratieoppervlak, en configuratieoppervlakken fungeren zelden ook als logviewer. Een diagnostische instelling is een object per resource, dus de resource die u kiest bepaalt alles wat volgt.

De andere helft van de verwarring is authenticatie. Op certificaten gebaseerde Point-to-Site-verbindingen genereren geen aanmeldingsgebeurtenis per gebruiker zoals een identiteitsprovider dat doet, dus er is geen record van een met naam genoemde persoon die een wachtwoord typt.

Koppel de diagnostische instelling aan de gatewayresource

Open Monitor, dan Diagnostic settings, en voeg een nieuwe instelling toe waarvan het doel de gateway van het virtuele netwerk zelf is en niet het virtuele netwerk dat hem bevat. Selecteer de Point-to-Site-diagnostiekcategorie, degene met de naam P2SDiagnosticLog, want die draagt de verbindingsrecords per client; voeg de tunnel-, route- of IKE-categorieën alleen toe voor de site-to-site-fouten die ze dekken. Stuur de gegevens vervolgens naar een Log Analytics-werkruimte die u beheert, met een bewaartermijn die u bewust hebt gekozen. De meeste mislukte zoekopdrachten zijn een instelling die aan de verkeerde resource is gekoppeld, niet een ontbrekende functie.

Categorielijsten verschillen per gatewaytype en generatie. Als de Point-to-Site-categorie ontbreekt, kan de gateway ouder zijn dan de functie of een SKU draaien die hem nooit uitzendt, dus controleer de ondersteunde categorieën voordat u een rechtenprobleem gaat zoeken. Een gateway zonder Point-to-Site-categorie is niet kapot; hij kan simpelweg niet de bron van dat record zijn, en de dichtstbijzijnde vervanging is de tunnel- of IKE-categorie, die het clientadres registreert ook al beschrijft hij geen Point-to-Site-sessie. Bevestig de categorielijst voordat u een supportcase opent over ontbrekende logboeken.

Lees de records in de tabel die uw modus gebruikt

In de oudere verzamelmodus belanden vermeldingen in de tabel AzureDiagnostics en verschijnt de categorie als kolomwaarde; met resourcespecifieke tabellen heeft de gateway een eigen tabel. Hoe dan ook, vraag op de gatewayresource en een venster rond de mislukte poging, en lees dan de correlatie in plaats van de afzonderlijke rijen:

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

De kolomset volgt uw verzamelmodus, dus behandel de query als een vorm en niet als een script. Wat u zoekt is een clientadres dat verschijnt en vervolgens verdwijnt, met een resultaattype dat geen succes is.

Koppel het gatewayrecord aan de eigen kijk van de client

Gatewaylogboeken beschrijven de tunnel, niet waarom een laptop er geen kon bouwen. Verzamel de clientzijde op dezelfde tijdstempel: het Windows-gebeurtenislogboek voor de RAS-client, het macOS-verbindingslogboek of de fouttekst die de client-app toonde. Een gatewayrecord zonder bijbehorende clientpoging wijst op de client; een client die succes meldt terwijl de gateway niets registreert, betekent meestal dat het profiel op een andere gateway is gericht.

Houd beide helften in hetzelfde ticket. Een gatewaylogboek alleen nodigt uit tot de verkeerde conclusie, en een clientlogboek alleen kan niet laten zien of het pakket ooit aankwam.

Als er nergens iets verschijnt, controleer dan de klok op de client voordat u het platform wantrouwt. Scheve tijdstempels laten de correlatie mislukken op een manier die er precies uitziet als ontbrekende gegevens.

Bewaring, bereik en de runbook-regel

Tunnelrecords bevatten clientadressen en verbindingstijdstempels, dus behandel ze als persoonsgegevens met een verwijderschema in plaats van de standaardwaarde van het platform te laten staan. Controleer ook dat de werkruimte niet elke categorie van elke resource in het abonnement opneemt, want een rumoerige werkruimte maakt de correlatie trager dan het clientlogboek rechtstreeks lezen.

Schrijf ten slotte de naam van de instelling, de werkruimte en de gekozen categorieën in de runbook van de gateway. De volgende persoon die een client debugt, kijkt eerst in de gatewayblade, vindt niets en concludeert dat de logboeken niet bestaan.