On són els registres d’Azure Point-to-Site VPN? Mireu a Monitor

Un usuari no es pot connectar al gateway de punt a lloc, obriu la fulla del gateway i no hi ha cap historial de connexions enlloc de la pàgina. Configuració, certificats, estat: tot present, cap registre. Els registres existeixen, però les pàgines de xarxa no els produeixen de cap manera. Venen d’una configuració de diagnòstic adjunta al recurs del gateway, i aquesta configuració viu a Monitor; per això la primera cerca al lloc obvi no retorna res i la gent conclou que el servei no guarda cap rastre d’auditoria.

Per què falla la cerca òbvia

Les guies antigues afirmen que Azure Point-to-Site VPN no té auditoria, i això era cert quan el servei no exposava cap registre per connexió. Els gateways actuals publiquen registres de diagnòstic del túnel, així que la pregunta útil ha canviat: no si existeixen registres, sinó quin recurs els emet i quina categoria heu activat. La fulla del gateway és una superfície de configuració, i les superfícies de configuració poques vegades fan també de visors de registres. Una configuració de diagnòstic és un objecte per recurs, així que el recurs que trieu determina tot el que segueix.

L’altra meitat de la confusió és l’autenticació. Les connexions de punt a lloc basades en certificats no generen un esdeveniment d’inici de sessió per usuari com fa un proveïdor d’identitat, així que no hi ha cap registre d’una persona concreta que escrigui una contrasenya.

Adjunteu la configuració de diagnòstic al recurs del gateway

Obriu Monitor, després Diagnostic settings, i afegiu una configuració nova l’objectiu de la qual sigui el mateix gateway de xarxa virtual i no la xarxa virtual que el conté. Seleccioneu la categoria de diagnòstic de punt a lloc, la que es diu P2SDiagnosticLog, perquè és la que porta els registres de connexió per client; afegiu les categories de túnel, ruta o IKE només per als errors de lloc a lloc que cobreixen. Després envieu les dades a un espai de treball de Log Analytics que controleu, amb un període de retenció que hàgiu triat expressament. La majoria de cerques fallides són una configuració adjunta al recurs equivocat, no una funció que falti.

Les llistes de categories varien segons el tipus i la generació del gateway. Si la categoria de punt a lloc no hi és, potser el gateway és anterior a la funció o executa una SKU que no l’emet mai, així que comproveu les categories admeses abans de buscar un problema de permisos. Un gateway sense categoria de punt a lloc no està trencat; simplement no pot ser la font d’aquell registre, i el substitut més proper és la categoria de túnel o IKE, que enregistra l’adreça del client encara que no descrigui una sessió de punt a lloc. Confirmeu la llista de categories abans d’obrir un cas de suport sobre registres que falten.

Llegiu els registres a la taula que utilitzi el vostre mode

Amb el mode de recollida antic, les entrades van a la taula AzureDiagnostics i la categoria apareix com a valor de columna; amb taules específiques del recurs, el gateway té una taula pròpia. En qualsevol cas, consulteu pel recurs del gateway i per una finestra al voltant de l’intent fallit, i després llegiu la correlació en lloc de les files individuals:

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

El conjunt de columnes segueix el vostre mode de recollida, així que tracteu la consulta com una forma i no com un script. El que busqueu és una adreça de client que apareix i després desapareix, amb un tipus de resultat que no és èxit.

Aparelleu el registre del gateway amb la visió del client

Els registres del gateway descriuen el túnel, no per què un portàtil no n’ha pogut construir un. Recolliu el costat del client a la mateixa marca de temps: el registre d’esdeveniments de Windows per al client RAS, el registre de connexions de macOS o el text d’error que va mostrar l’aplicació client. Un registre del gateway sense cap intent de client corresponent apunta al client; un client que informa d’èxit mentre el gateway no enregistra res normalment vol dir que el perfil apunta a un altre gateway.

Manteniu les dues meitats al mateix tiquet. Un registre del gateway sol convida a la conclusió equivocada, i un registre del client sol no pot mostrar si el paquet va arribar mai.

Si no apareix res enlloc, comproveu el rellotge del client abans de dubtar de la plataforma. Les marques de temps esbiaixades fan fallar la correlació d’una manera que sembla exactament dades que falten.

Retenció, abast i l’entrada del runbook

Els registres del túnel porten adreces de client i marques de temps de connexió, així que tracteu-los com a dades personals amb un calendari de supressió en lloc de deixar el valor per defecte de la plataforma. Comproveu també que l’espai de treball no estigui ingerint totes les categories de tots els recursos de la subscripció, perquè un espai de treball sorollós fa la correlació més lenta que llegir directament el registre del client.

Finalment, escriviu el nom de la configuració, l’espai de treball i les categories triades al runbook del gateway. La propera persona que depuri un client mirarà primer la fulla del gateway, no hi trobarà res i conclourà que els registres no existeixen.