Dove sono i log di Azure Point-to-Site VPN? Guardate in Monitor

Un utente non riesce a connettersi al gateway da punto a sito, aprite il pannello del gateway e non c’è alcuna cronologia delle connessioni nella pagina. Configurazione, certificati, stato: tutto presente, nessun record. I log esistono, ma non sono affatto prodotti dalle pagine di rete. Provengono da un’impostazione di diagnostica associata alla risorsa del gateway, e quell’impostazione vive in Monitor; per questo la prima ricerca nel punto ovvio non restituisce nulla e le persone concludono che il servizio non conservi alcuna traccia di controllo.

Perché la ricerca ovvia fallisce

Le guide più vecchie affermano che Azure Point-to-Site VPN non ha controllo, e ciò era vero quando il servizio non esponeva alcun record per connessione. I gateway attuali pubblicano record di diagnostica del tunnel, quindi la domanda utile è cambiata: non se esistono i log, ma quale risorsa li emette e quale categoria avete attivato. Il pannello del gateway è una superficie di configurazione, e le superfici di configurazione raramente fungono anche da visualizzatori di log. Un’impostazione di diagnostica è un oggetto per risorsa, quindi la risorsa che scegliete determina tutto ciò che segue.

L’altra metà della confusione è l’autenticazione. Le connessioni da punto a sito basate su certificato non generano un evento di accesso per utente come fa un provider di identità, quindi non esiste alcun record di una persona nominata che digita una password.

Collegate l’impostazione di diagnostica alla risorsa del gateway

Aprite Monitor, poi Diagnostic settings, e aggiungete una nuova impostazione la cui destinazione sia il gateway di rete virtuale stesso e non la rete virtuale che lo contiene. Selezionate la categoria di diagnostica da punto a sito, quella chiamata P2SDiagnosticLog, perché è quella che trasporta i record di connessione per client; aggiungete le categorie tunnel, route o IKE solo per gli errori da sito a sito che coprono. Poi inviate i dati a un’area di lavoro Log Analytics che controllate, con un periodo di conservazione che avete scelto di proposito. La maggior parte delle ricerche fallite è un’impostazione associata alla risorsa sbagliata, non una funzione mancante.

Gli elenchi delle categorie variano in base al tipo e alla generazione del gateway. Se la categoria da punto a sito è assente, il gateway potrebbe essere precedente alla funzione o eseguire uno SKU che non la emette mai, quindi controllate le categorie supportate prima di cercare un problema di autorizzazioni. Un gateway senza categoria da punto a sito non è rotto; semplicemente non può essere l’origine di quel record, e il sostituto più vicino è la categoria tunnel o IKE, che registra l’indirizzo del client anche se non descrive una sessione da punto a sito. Confermate l’elenco delle categorie prima di aprire un caso di supporto sui log mancanti.

Leggete i record nella tabella usata dalla vostra modalità

Con la modalità di raccolta precedente, le voci finiscono nella tabella AzureDiagnostics e la categoria appare come valore di colonna; con le tabelle specifiche della risorsa, il gateway ha una propria tabella. In ogni caso, interrogate per risorsa del gateway e per una finestra attorno al tentativo fallito, poi leggete la correlazione invece delle singole righe:

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

L’insieme delle colonne segue la vostra modalità di raccolta, quindi trattate la query come una forma e non come uno script. Ciò che cercate è un indirizzo client che appare e poi scompare, con un tipo di risultato che non è successo.

Abbinate il record del gateway alla visione del client

I log del gateway descrivono il tunnel, non perché un portatile non sia riuscito a costruirne uno. Raccogliete il lato client allo stesso timestamp: il registro eventi di Windows per il client RAS, il registro delle connessioni di macOS o il testo dell’errore mostrato dall’app client. Un record del gateway senza un tentativo client corrispondente indica il client; un client che segnala successo mentre il gateway non registra nulla di solito significa che il profilo punta a un altro gateway.

Tenete entrambe le metà nello stesso ticket. Un log del gateway da solo invita alla conclusione sbagliata, e un log del client da solo non può mostrare se il pacchetto sia mai arrivato.

Se non appare nulla in nessuno dei due punti, controllate l’orologio del client prima di dubitare della piattaforma. Timestamp sfalsati fanno fallire la correlazione in un modo che sembra esattamente dati mancanti.

Conservazione, ambito e la voce del runbook

I record del tunnel portano indirizzi client e timestamp di connessione, quindi trattateli come dati personali con un calendario di cancellazione invece di lasciare l’impostazione predefinita della piattaforma. Verificate anche che l’area di lavoro non stia acquisendo ogni categoria da ogni risorsa della sottoscrizione, perché un’area di lavoro rumorosa rende la correlazione più lenta della lettura diretta del log del client.

Infine, scrivete il nome dell’impostazione, l’area di lavoro e le categorie scelte nel runbook del gateway. La prossima persona che eseguirà il debug di un client guarderà prima il pannello del gateway, non troverà nulla e concluderà che i log non esistono.