Problemen oplossen met Azure VPN Gateway met behulp van diagnostische logboeken
In dit artikel vindt u meer informatie over de verschillende logboeken die beschikbaar zijn voor diagnostische gegevens van VPN Gateway en hoe u deze kunt gebruiken om problemen met vpn-gateways effectief op te lossen.
Als uw Azure-probleem niet wordt opgelost in dit artikel, gaat u naar de Azure-forums op Microsoft Q & A en Stack Overflow. U kunt uw probleem posten in deze forums of posten op @AzureSupport op Twitter. U kunt ook een Azure-ondersteuningsaanvraag indienen. Als u een ondersteuningsaanvraag wilt indienen, selecteert u op de pagina Azure-ondersteuning Ondersteuning krijgen.
De volgende logboeken zijn beschikbaar in Azure:
- GatewayDiagnosticLog
- TunnelDiagnosticLog
- RouteDiagnosticLog
- IKEDiagnosticLog
- P2SDiagnosticLog
Voor op beleid gebaseerde gateways zijn alleen GatewayDiagnosticLog en RouteDiagnosticLog beschikbaar.
Zie de naslaginformatie over bewakingsgegevens van Azure VPN Gateway voor alle VPN Gateway-logboeken
Zie Diagnostische instellingen maken in Azure Monitor voor het instellen van diagnostische logboeken vanuit Azure VPN Gateway met behulp van Azure Log Analytics.
GatewayDiagnosticLog
Configuratiewijzigingen worden gecontroleerd in de tabel GatewayDiagnosticLog . Het kan enkele minuten duren voordat wijzigingen die u uitvoert, worden doorgevoerd in de logboeken.
Hier hebt u een voorbeeldquery als referentie.
AzureDiagnostics
| where Category == "GatewayDiagnosticLog"
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup
| sort by TimeGenerated asc
Deze query op GatewayDiagnosticLog toont u meerdere kolommen.
Naam | Beschrijving |
---|---|
TimeGenerated | de tijdstempel van elke gebeurtenis, in UTC-tijdzone. |
OperationName | de gebeurtenis die is gebeurd. Dit kan een van de opties SetGatewayConfiguration, SetConnectionConfiguration, HostMaintenanceEvent, GatewayTenantPrimaryChanged, MigrateCustomerSubscription, GatewayResourceMove, ValidateGatewayConfiguration zijn. |
Bericht | de details van de bewerking en een lijst met geslaagde/mislukte resultaten. |
In het volgende voorbeeld ziet u de activiteit die is geregistreerd wanneer een nieuwe configuratie is toegepast:
U ziet dat een SetGatewayConfiguration wordt geregistreerd telkens wanneer een configuratie wordt gewijzigd op een VPN-gateway of een lokale netwerkgateway.
Als u de resultaten van de tabel GatewayDiagnosticLog vergelijkt met de resultaten van de tabel TunnelDiagnosticLog , kunt u bepalen of er een verbindingsfout is opgetreden tijdens een configuratiewijziging of onderhoudsactiviteit. Zo ja, dan geeft het een significante indicatie naar de mogelijke hoofdoorzaak.
TunnelDiagnosticLog
De tabel TunnelDiagnosticLog is handig om de historische connectiviteitsstatussen van de tunnel te inspecteren.
Hier hebt u een voorbeeldquery als referentie.
AzureDiagnostics
| where Category == "TunnelDiagnosticLog"
//| where remoteIP_s == "<REMOTE IP OF TUNNEL>"
| project TimeGenerated, OperationName, remoteIP_s, instance_s, Resource, ResourceGroup
| sort by TimeGenerated asc
In deze query op TunnelDiagnosticLog ziet u meerdere kolommen.
Naam | Beschrijving |
---|---|
TimeGenerated | de tijdstempel van elke gebeurtenis, in UTC-tijdzone. |
OperationName | de gebeurtenis die is gebeurd. Dit kan TunnelConnected of TunnelDisconnected zijn. |
remoteIP_s | het IP-adres van het on-premises VPN-apparaat. In praktijkscenario's is het handig om te filteren op het IP-adres van het relevante on-premises apparaat, moet er meer dan één zijn. |
Instance_s | het exemplaar van de gatewayrol dat de gebeurtenis heeft geactiveerd. Dit kan GatewayTenantWorker_IN_0 of GatewayTenantWorker_IN_1 zijn. Dit zijn de namen van de twee exemplaren van de gateway. |
Resource | geeft de naam van de VPN-gateway aan. |
ResourceGroup | geeft de resourcegroep aan waar de gateway zich bevindt. |
Voorbeelduitvoer:
TunnelDiagnosticLog is handig om eerdere gebeurtenissen over onverwachte VPN-verbindingen op te lossen. De lichtgewicht aard biedt de mogelijkheid om grote tijdsbereiken over meerdere dagen te analyseren met weinig inspanning. Pas nadat u de tijdstempel van een verbroken verbinding hebt geïdentificeerd, kunt u overschakelen naar de gedetailleerdere analyse van de tabel IKEdiagnosticLog om dieper in te gaan op de redenering van de verbroken verbindingen. Deze zijn gerelateerd aan IPsec.
Enkele tips voor probleemoplossing:
- Als u een gebeurtenis voor het verbreken van de verbinding op één gatewayexemplaren ziet, gevolgd door een verbindings gebeurtenis op een ander gatewayexemplaren binnen een paar seconden, wordt een gatewayfailover aangegeven. Een dergelijke gebeurtenis ontstaat doorgaans vanwege onderhoud op een gateway-exemplaar. Zie Over redundantie van Azure VPN-gateways voor meer informatie over dit gedrag.
- Hetzelfde gedrag wordt waargenomen als u opzettelijk een gatewayherstel uitvoert aan de Azure-zijde, waardoor het actieve gatewayexemplaren opnieuw worden opgestart. Zie Een VPN Gateway opnieuw instellen voor meer informatie over dit gedrag.
- Als u een gebeurtenis voor de verbroken verbinding ziet op één gateway-exemplaar, gevolgd door een verbindingsgebeurtenis op hetzelfde gatewayexemplaren in een paar seconden, kijkt u mogelijk naar een netwerkfout die een DPD-time-out veroorzaakt of een verbroken verbinding die per ongeluk wordt verzonden door het on-premises apparaat.
RouteDiagnosticLog
De tabel RouteDiagnosticLog traceert de activiteit voor statisch gewijzigde routes of routes die via BGP worden ontvangen.
Hier hebt u een voorbeeldquery als referentie.
AzureDiagnostics
| where Category == "RouteDiagnosticLog"
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup
Deze query op RouteDiagnosticLog toont u meerdere kolommen.
Naam | Beschrijving |
---|---|
TimeGenerated | de tijdstempel van elke gebeurtenis, in UTC-tijdzone. |
OperationName | de gebeurtenis die is gebeurd. Kan een van de staticRouteUpdates, BgpRouteUpdate, BgpConnectedEvent, BgpDisconnectedEvent zijn. |
Bericht | de details van de bewerking. |
De uitvoer toont nuttige informatie over BGP-peers die zijn verbonden/verbroken en routes die zijn uitgewisseld.
Voorbeeld:
IKEDiagnosticLog
De tabel IKEDiagnosticLog biedt uitgebreide logboekregistratie voor foutopsporing voor IKE/IPsec. Dit is handig om te controleren bij het oplossen van problemen met verbroken verbindingen of het niet verbinden van VPN-scenario's.
Hier hebt u een voorbeeldquery als referentie.
AzureDiagnostics
| where Category == "IKEDiagnosticLog"
| extend Message1=Message
| parse Message with * "Remote " RemoteIP ":" * "500: Local " LocalIP ":" * "500: " Message2
| extend Event = iif(Message has "SESSION_ID",Message2,Message1)
| project TimeGenerated, RemoteIP, LocalIP, Event, Level
| sort by TimeGenerated asc
Deze query op IKEDiagnosticLog toont u meerdere kolommen.
Naam | Beschrijving |
---|---|
TimeGenerated | de tijdstempel van elke gebeurtenis, in UTC-tijdzone. |
RemoteIP | het IP-adres van het on-premises VPN-apparaat. In praktijkscenario's is het handig om te filteren op het IP-adres van het relevante on-premises apparaat, moet er meer dan één zijn. |
LocalIP | het IP-adres van de VPN-gateway die we oplossen. In praktijkscenario's is het handig om te filteren op het IP-adres van de relevante VPN-gateway, is er meer dan één in uw abonnement. |
Gebeurtenis | bevat een diagnostisch bericht dat nuttig is voor het oplossen van problemen. Ze beginnen meestal met een trefwoord en verwijzen naar de acties die door de Azure Gateway worden uitgevoerd: [SEND] geeft een gebeurtenis aan die wordt veroorzaakt door een IPSec-pakket dat door de Azure Gateway wordt verzonden. [ONTVANGEN] geeft een gebeurtenis aan als gevolg van een pakket dat is ontvangen van een on-premises apparaat. [LOKAAL] geeft een lokaal uitgevoerde actie aan door de Azure Gateway. |
U ziet dat de kolommen RemoteIP, LocalIP en Gebeurtenis niet aanwezig zijn in de oorspronkelijke kolomlijst in de AzureDiagnostics-database, maar worden toegevoegd aan de query door de uitvoer van de kolom Bericht te parseren om de analyse te vereenvoudigen.
Tips voor probleemoplossing:
Als u het begin van een IPSec-onderhandeling wilt identificeren, moet u het eerste SA_INIT bericht vinden. Een dergelijk bericht kan aan beide zijden van de tunnel worden verzonden. Degene die het eerste pakket verzendt, wordt 'initiator' genoemd in IPsec-terminologie, terwijl de andere kant de 'responder' wordt. Het eerste SA_INIT bericht is altijd het bericht waarbij rCookie = 0.
Als de IPsec-tunnel niet tot stand kan worden gebracht, blijft Azure elke paar seconden opnieuw proberen. Om deze reden is het oplossen van problemen met 'VPN down' handig in IKEdiagnosticLog, omdat u niet hoeft te wachten op een specifiek tijdstip om het probleem te reproduceren. Bovendien zal de fout in theorie altijd hetzelfde zijn telkens wanneer we proberen, zodat u op elk gewenst moment kunt inzoomen op één 'voorbeeld'-mislukte onderhandeling.
De SA_INIT bevat de IPSec-parameters die de peer wil gebruiken voor deze IPsec-onderhandeling. Het officiële document
Met standaard-IPsec-/IKE-parameters worden de IPsec-parameters vermeld die door de Azure Gateway worden ondersteund met standaardinstellingen.
P2SDiagnosticLog
De laatst beschikbare tabel voor diagnostische gegevens van VPN is P2SDiagnosticLog. Deze tabel traceert de activiteit voor punt-naar-site (alleen IKEv2- en OpenVPN-protocollen).
Hier hebt u een voorbeeldquery als referentie.
AzureDiagnostics
| where Category == "P2SDiagnosticLog"
| project TimeGenerated, OperationName, Message, Resource, ResourceGroup
Deze query op P2SDiagnosticLog toont u meerdere kolommen.
Naam | Beschrijving |
---|---|
TimeGenerated | de tijdstempel van elke gebeurtenis, in UTC-tijdzone. |
OperationName | de gebeurtenis die is gebeurd. Is P2SLogEvent. |
Bericht | de details van de bewerking. |
In de uitvoer ziet u alle punt-naar-site-instellingen die door de gateway zijn toegepast en het IPsec-beleid.
Wanneer een client een verbinding tot stand brengt met behulp van OpenVPN en Microsoft Entra ID-verificatie voor punt-naar-site, registreert de tabel pakketactiviteit als volgt:
[MSG] [default] [OVPN_XXXXXXXXXXXXXXXXXXXXXXXXXXX] Connect request received. IP=0.X.X.X:XXX
[MSG] [default] [OVPN_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] AAD authentication succeeded. Username=***tosouser@contoso.com
[MSG] [default] [OVPN_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] Connection successful. Username=***tosouser@contoso.com IP=10.0.0.1
Notitie
In het punt-naar-site-logboek is de gebruikersnaam gedeeltelijk verborgen. De eerste octet van het IP-adres van de clientgebruiker wordt vervangen door een 0
.
Volgende stappen
Zie Waarschuwingen instellen voor VPN Gateway-resourcelogboeken om waarschuwingen voor tunnelresourcelogboeken te configureren.