Unde sunt jurnalele Azure Point-to-Site VPN? Priviți în Monitor

Un utilizator nu se poate conecta la gateway-ul point-to-site, deschideți panoul gateway-ului și nu există niciun istoric al conexiunilor nicăieri pe pagină. Configurație, certificate, stare: toate prezente, nicio înregistrare. Jurnalele există, dar nu sunt deloc produse de paginile de rețea. Ele provin dintr-o setare de diagnostic atașată resursei gateway-ului, iar acea setare trăiește sub Monitor; de aceea prima căutare în locul evident nu returnează nimic, iar oamenii concluzionează că serviciul nu păstrează nicio urmă de audit.

De ce eșuează căutarea evidentă

Ghidurile mai vechi afirmă că Azure Point-to-Site VPN nu are audit, iar acest lucru era adevărat când serviciul nu expunea nicio înregistrare per conexiune. Gateway-urile actuale publică înregistrări de diagnostic ale tunelului, așa că întrebarea utilă s-a schimbat: nu dacă există jurnale, ci ce resursă le emite și ce categorie ați activat. Panoul gateway-ului este o suprafață de configurare, iar suprafețele de configurare rareori servesc și ca vizualizatoare de jurnale. O setare de diagnostic este un obiect per resursă, deci resursa pe care o alegeți determină tot ce urmează.

Cealaltă jumătate a confuziei este autentificarea. Conexiunile point-to-site bazate pe certificate nu generează un eveniment de conectare per utilizator precum un furnizor de identitate, deci nu există nicio înregistrare a unei persoane numite care tastează o parolă.

Atașați setarea de diagnostic la resursa gateway-ului

Deschideți Monitor, apoi Diagnostic settings, și adăugați o setare nouă a cărei țintă este gateway-ul de rețea virtuală însuși, nu rețeaua virtuală care îl conține. Selectați categoria de diagnostic point-to-site, cea numită P2SDiagnosticLog, pentru că ea transportă înregistrările conexiunilor per client; adăugați categoriile tunel, rută sau IKE doar pentru erorile site-to-site pe care le acoperă. Apoi trimiteți datele către un spațiu de lucru Log Analytics pe care îl controlați, cu o perioadă de păstrare pe care ați ales-o intenționat. Majoritatea căutărilor eșuate sunt o setare atașată resursei greșite, nu o funcție lipsă.

Listele de categorii diferă în funcție de tipul și generația gateway-ului. Dacă categoria point-to-site lipsește, gateway-ul poate fi mai vechi decât funcția sau poate rula un SKU care nu o emite niciodată, așa că verificați categoriile acceptate înainte de a căuta o problemă de permisiuni. Un gateway fără categorie point-to-site nu este stricat; pur și simplu nu poate fi sursa acelei înregistrări, iar cel mai apropiat substitut este categoria tunel sau IKE, care înregistrează adresa clientului deși nu descrie o sesiune point-to-site. Confirmați lista de categorii înainte de a deschide un caz de asistență despre jurnale lipsă.

Citiți înregistrările în tabelul pe care îl folosește modul dumneavoastră

În modul de colectare vechi, intrările ajung în tabelul AzureDiagnostics și categoria apare ca valoare de coloană; la tabelele specifice resursei, gateway-ul are propriul tabel. În orice caz, interogați după resursa gateway-ului și o fereastră din jurul încercării eșuate, apoi citiți corelația în locul rândurilor individuale:

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

Setul de coloane urmează modul dumneavoastră de colectare, așa că tratați interogarea ca o formă, nu ca un script. Ceea ce căutați este o adresă de client care apare și apoi dispare, cu un tip de rezultat care nu este succes.

Asociați înregistrarea gateway-ului cu viziunea clientului

Jurnalele gateway-ului descriu tunelul, nu de ce un laptop nu a reușit să construiască unul. Colectați partea clientului la aceeași marcă de timp: jurnalul de evenimente Windows pentru clientul RAS, jurnalul de conexiuni macOS sau textul erorii afișat de aplicația client. O înregistrare a gateway-ului fără o încercare corespunzătoare a clientului indică clientul; un client care raportează succes în timp ce gateway-ul nu înregistrează nimic înseamnă de obicei că profilul vizează alt gateway.

Păstrați ambele jumătăți în același tichet. Doar jurnalul gateway-ului invită la concluzia greșită, iar doar jurnalul clientului nu poate arăta dacă pachetul a ajuns vreodată.

Dacă nu apare nimic în niciunul dintre locuri, verificați ceasul clientului înainte de a vă îndoi de platformă. Mărcile de timp denaturate fac corelația să eșueze într-un mod care arată exact ca datele lipsă.

Păstrare, domeniu și intrarea din runbook

Înregistrările tunelului conțin adrese de client și mărci de timp ale conexiunilor, așa că tratați-le ca date personale cu un calendar de ștergere în loc să lăsați valoarea implicită a platformei. Verificați și că spațiul de lucru nu ingeră fiecare categorie din fiecare resursă din abonament, pentru că un spațiu de lucru zgomotos face corelația mai lentă decât citirea directă a jurnalului clientului.

În final, scrieți numele setării, spațiul de lucru și categoriile alese în runbook-ul gateway-ului. Următoarea persoană care depanează un client se va uita mai întâi în panoul gateway-ului, nu va găsi nimic și va concluziona că jurnalele nu există.