Käyttäjä ei saa yhteyttä Point-to-Site-yhdyskäytävään, avaat yhdyskäytävän sivun, eikä sivulla ole missään yhteyshistoriaa. Kokoonpano, varmenteet, tila: kaikki paikalla, ei merkintöjä. Lokit ovat olemassa, mutta verkkosivut eivät tuota niitä lainkaan. Ne tulevat yhdyskäytävän resurssiin liitetystä diagnostiikka-asetuksesta, ja se asetus elää Monitorissa; siksi ensimmäinen haku ilmeisestä paikasta ei palauta mitään, ja ihmiset päättelevät, ettei palvelu pidä mitään auditointijälkeä.

Miksi ilmeinen haku epäonnistuu

Vanhemmat ohjeet sanovat, ettei Azure Point-to-Site VPN:ssä ole auditointia, ja se oli totta, kun palvelu ei tarjonnut merkintää yhteyttä kohden. Nykyiset yhdyskäytävät julkaisevat tunnelin diagnostiikkamerkintöjä, joten hyödyllinen kysymys muuttui: ei se, ovatko lokit olemassa, vaan mikä resurssi ne lähettää ja minkä luokan otit käyttöön. Yhdyskäytävän sivu on kokoonpanopinta, ja kokoonpanopinnat toimivat harvoin myös lokikatselmina. Diagnostiikka-asetus on kohde resurssia kohden, joten valitsemasi resurssi määrää kaiken seuraavan.

Toinen puoli hämmennystä on todennus. Varmenteisiin perustuvat Point-to-Site-yhteydet eivät tuota käyttäjäkohtaista kirjautumistapahtumaa kuten identiteettipalveluntarjoaja, joten ei ole merkintää nimetyistä henkilöstä, joka kirjoittaa salasanan.

Liitä diagnostiikka-asetus yhdyskäytävän resurssiin

Avaa Monitor, sitten Diagnostic settings, ja lisää uusi asetus, jonka kohteena on itse virtuaaliverkon yhdyskäytävä eikä sitä sisältävä virtuaaliverkko. Valitse Point-to-Site-diagnostiikkaluokka, se jonka nimi on P2SDiagnosticLog, koska se kuljettaa asiakaskohtaiset yhteysmerkinnät; lisää tunnelin, reitin tai IKE:n luokat vain niille site-to-site-virheille, jotka ne kattavat. Lähetä sitten tiedot hallitsemaasi Log Analytics -työtilaan säilytysjaksolla, jonka valitsit tarkoituksella. Useimmat epäonnistuneet haut ovat väärään resurssiin liitetty asetus, eivät puuttuva ominaisuus.

Luokkaluettelot vaihtelevat yhdyskäytävän tyypin ja sukupolven mukaan. Jos Point-to-Site-luokka puuttuu, yhdyskäytävä voi olla ominaisuutta vanhempi tai käyttää SKU:ta, joka ei koskaan lähetä sitä, joten tarkista tuetut luokat ennen kuin etsit käyttöoikeusongelmaa. Yhdyskäytävä ilman Point-to-Site-luokkaa ei ole rikki; se ei yksinkertaisesti voi olla kyseisen merkinnän lähde, ja lähin korvaava on tunnelin tai IKE:n luokka, joka tallentaa asiakkaan osoitteen, vaikka ei kuvaakaan Point-to-Site-istuntoa. Vahvista luokkaluettelo ennen kuin avaat tukipyynnön puuttuvista lokeista.

Lue merkinnät taulusta, jota tilasi käyttää

Vanhemmassa keräystilassa merkinnät päätyvät AzureDiagnostics-tauluun ja luokka näkyy sarakkeen arvona; resurssikohtaisissa tauluissa yhdyskäytävällä on oma taulunsa. Kummassakin tapauksessa kysy yhdyskäytävän resurssin ja epäonnistuneen yrityksen ympärillä olevan aikaikkunan mukaan ja lue sitten korrelaatio yksittäisten rivien sijaan:

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

Sarakkeiden joukko seuraa keräystilaasi, joten kohtele kyselyä muotona äläkä skriptinä. Etsit asiakkaan osoitetta, joka ilmestyy ja katoaa sitten, ja tulostyyppiä, joka ei ole onnistuminen.

Yhdistä yhdyskäytävän merkintä asiakkaan omaan näkymään

Yhdyskäytävän lokit kuvaavat tunnelia, eivät sitä, miksi kannettava tietokone ei onnistunut rakentamaan sitä. Kerää asiakkaan puoli samalla aikaleimalla: Windowsin tapahtumaloki RAS-asiakkaalle, macOS:n yhteysloki tai virheteksti, jonka asiakassovellus näytti. Yhdyskäytävän merkintä ilman vastaavaa asiakasyritystä osoittaa asiakkaaseen; jos asiakas raportoi onnistumisesta, kun yhdyskäytävä ei tallenna mitään, se tarkoittaa yleensä, että profiili on suunnattu toiseen yhdyskäytävään.

Pidä molemmat puolet samassa tiketissä. Pelkkä yhdyskäytävän loki houkuttaa väärään johtopäätökseen, eikä pelkkä asiakkaan loki voi näyttää, saapuiko paketti koskaan.

Jos kummassakaan paikassa ei näy mitään, tarkista asiakkaan kello ennen kuin epäilet alustaa. Vinoutuneet aikaleimat saavat korrelaation epäonnistumaan tavalla, joka näyttää täsmälleen puuttuvilta tiedoilta.

Säilytys, laajuus ja runbook-merkintä

Tunnelimerkinnät sisältävät asiakkaiden osoitteita ja yhteyksien aikaleimoja, joten kohtele niitä henkilötietoina ja poistamisaikataulun kanssa sen sijaan, että jättäisit alustan oletuksen voimaan. Tarkista myös, ettei työtila ota vastaan jokaista luokkaa jokaisesta tilauksen resurssista, sillä meluisa työtila tekee korrelaatiosta hitaampaa kuin asiakkaan lokin lukeminen suoraan.

Kirjoita lopuksi asetuksen nimi, työtila ja valitut luokat yhdyskäytävän runbookiin. Seuraava henkilö, joka selvittää asiakkaan ongelmaa, katsoo ensin yhdyskäytävän sivua, ei löydä mitään ja päättelee, ettei lokeja ole olemassa.

Aiheeseen liittyvät artikkelit