Kie estas la protokoloj de Azure Point-to-Site VPN? Rigardu en Monitor

Uzanto ne povas konektiĝi al la Point-to-Site-pordego, vi malfermas la pordegan panelon, kaj nenie sur la paĝo estas konekta historio. Agordo, atestiloj, stato: ĉio ĉeestas, neniuj rikordoj. La protokoloj ekzistas, sed la retaj paĝoj tute ne produktas ilin. Ili venas de diagnoza agordo ligita al la pordega resurso, kaj tiu agordo vivas sub Monitor; tial la unua serĉo en la evidenta loko redonas nenion, kaj homoj konkludas, ke la servo tenas neniun revizian spuron.

Kial la evidenta serĉo malsukcesas

Pli malnovaj gvidlinioj asertas, ke Azure Point-to-Site VPN havas neniun revizion, kaj tio estis vera kiam la servo ne elmontris rikordon po konekto. Nunaj pordegoj publikigas diagnozajn tunelajn rikordojn, do la utila demando ŝanĝiĝis: ne ĉu protokoloj ekzistas, sed kiu resurso elsendas ilin kaj kiun kategorion vi ŝaltis. La pordega panelo estas agorda surfaco, kaj agordaj surfacoj malofte ankaŭ funkcias kiel protokolrigardiloj. Diagnoza agordo estas objekto po resurso, do la resurso, kiun vi elektas, determinas ĉion sekvan.

La alia duono de la konfuzo estas aŭtentikigo. Atestil-bazitaj Point-to-Site-konektoj ne generas ensalutan eventon po uzanto kiel identec-provizanto, do ne ekzistas rikordo pri nomita persono tajpanta pasvorton.

Ligu la diagnozan agordon al la pordega resurso

Malfermu Monitor, poste Diagnostic settings, kaj aldonu novan agordon, kies celo estas la virtuala reta pordego mem, ne la virtuala reto, kiu enhavas ĝin. Elektu la diagnozan kategorion Point-to-Site, tiun nomatan P2SDiagnosticLog, ĉar ĝi portas la konektajn rikordojn po kliento; aldonu la kategoriojn tunelo, vojo aŭ IKE nur por la site-to-site-eraroj, kiujn ili kovras. Poste sendu la datumojn al Log Analytics-laboratorio, kiun vi kontrolas, kun retenperiodo, kiun vi konscie elektis. Plej multaj malsukcesaj serĉoj estas agordo ligita al la malĝusta resurso, ne mankanta funkcio.

Kategorio-listoj varias laŭ pordega tipo kaj generacio. Se la kategorio Point-to-Site mankas, la pordego eble antaŭas la funkcion aŭ uzas SKU, kiu neniam elsendas ĝin, do kontrolu la subtenatajn kategoriojn antaŭ ol serĉi permesan problemon. Pordego sen kategorio Point-to-Site ne estas difektita; ĝi simple ne povas esti la fonto de tiu rikordo, kaj la plej proksima anstataŭo estas la kategorio tunelo aŭ IKE, kiu registras la klientan adreson eĉ se ĝi ne priskribas Point-to-Site-sesion. Konfirmu la kategorio-liston antaŭ ol malfermi subtenan kazon pri mankantaj protokoloj.

Legu la rikordojn en tiu tabelo, kiun uzas via reĝimo

En la malnova kolektada reĝimo, la enskriboj falas en la tabelon AzureDiagnostics kaj la kategorio aperas kiel kolumna valoro; ĉe resurso-specifaj tabeloj, la pordego havas sian propran tabelon. Ĉiukaze, mendu laŭ la pordega resurso kaj fenestro ĉirkaŭ la malsukcesa provo, kaj poste legu la korelacion anstataŭ la unuopajn vicojn:

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

La kolumna aro sekvas vian kolektadan reĝimon, do traktu la mendon kiel formon, ne kiel skripton. Tio, kion vi serĉas, estas klienta adreso, kiu aperas kaj poste malaperas, kun rezulta tipo, kiu ne estas sukceso.

Paru la pordegan rikordon kun la propra vidpunkto de la kliento

Pordegaj protokoloj priskribas la tunelon, ne kial tekkomputilo malsukcesis konstrui unu. Kolektu la klientan flankon je la sama tempstampo: la Windows-eventprotokolo por la RAS-kliento, la macOS-konekta protokolo, aŭ la erarteksto, kiun la klienta aplikaĵo montris. Pordega rikordo sen responda klienta provo indikas la klienton; kliento raportanta sukceson dum la pordego registras nenion kutime signifas, ke la profilo celas alian pordegon.

Tenu ambaŭ duonojn en la sama bileto. Nur pordega protokolo invitas la malĝustan konkludon, kaj nur klienta protokolo ne povas montri, ĉu la pako iam alvenis.

Se nenio aperas en iu ajn loko, kontrolu la horloĝon sur la kliento antaŭ ol dubi la platformon. Deformitaj tempstampoj igas la korelacion malsukcesi tiel, ke ĝi aspektas ĝuste kiel mankantaj datumoj.

Retenado, amplekso kaj la runbook-enskribo

Tunelaj rikordoj portas klientajn adresojn kaj konektajn tempstampojn, do traktu ilin kiel personajn datumojn kun foriga horaro anstataŭ lasi la platforman defaŭlton. Kontrolu ankaŭ, ke la laboratorio ne ensorbas ĉiun kategorion de ĉiu resurso en la abono, ĉar brua laboratorio igas la korelacion pli malrapida ol rekte legi la klientan protokolon.

Fine, skribu la nomon de la agordo, la laboratorion kaj la elektitajn kategoriojn en la runbook de la pordego. La sekva persono, kiu sencimigos klienton, unue rigardos en la pordegan panelon, trovos nenion, kaj konkludos, ke la protokoloj ne ekzistas.