Каде се логовите на Azure Point-to-Site VPN? Погледнете во Monitor

Корисник не може да се поврзе со портата Point-to-Site, ја отворате панелот на портата, и никаде на страницата нема историја на врски. Конфигурација, сертификати, статус: сето е присутно, нема записи. Логовите постојат, но мрежните страници воопшто не ги создаваат. Тие доаѓаат од дијагностичко поставување прикачено на ресурсот на портата, и тоа поставување живее под Monitor; затоа првото пребарување на очигледното место не враќа ништо, и луѓето заклучуваат дека услугата не води никаква трага за ревизија.

Зошто очигледното пребарување не успева

Поновите упатства велат дека Azure Point-to-Site VPN нема ревизија, и тоа беше точно кога услугата не изложуваше запис по врска. Тековните порти објавуваат дијагностички записи за тунелот, па корисното прашање се промени: не дали постојат логови, туку кој ресурс ги емитува и која категорија ја вклучивте. Панелот на портата е површина за конфигурација, а конфигурациските површини ретко служат и како прегледувачи на логови. Дијагностичкото поставување е објект по ресурс, па избраниот ресурс одредува сето што следи.

Другата половина од збунувањето е автентикацијата. Врските Point-to-Site засновани на сертификати не создаваат настан за најава по корисник како што прави давател на идентитет, па нема запис за именувано лице што внесува лозинка.

Прикачете го дијагностичкото поставување на ресурсот на портата

Отворете Monitor, потоа Diagnostic settings, и додадете ново поставување чија цел е самата порта на виртуелната мрежа, а не виртуелната мрежа што ја содржи. Изберете ја дијагностичката категорија Point-to-Site, таа што се вика P2SDiagnosticLog, зашто токму таа ги носи записите за врски по клиент; додајте ги категориите тунел, рута или IKE само за site-to-site грешките што ги покриваат. Потоа испратете ги податоците до работен простор Log Analytics што го контролирате, со период на задржување што сте го избрале намерно. Повеќето неуспешни пребарувања се поставување прикачено на погрешен ресурс, а не функција што недостасува.

Списоците на категории се разликуваат според типот и генерацијата на портата. Ако категоријата Point-to-Site недостасува, портата може да е постара од функцијата или да работи на SKU што никогаш не ја емитува, па проверете ги поддржаните категории пред да барате проблем со дозволи. Порта без категорија Point-to-Site не е расипана; едноставно не може да биде изворот на тој запис, а најблиската замена е категоријата тунел или IKE, која ја запишува адресата на клиентот иако не опишува сесија Point-to-Site. Потврдете го списокот со категории пред да отворите случај за поддршка за логови што недостасуваат.

Читајте ги записите во табелата што ја користи вашиот режим

Во стариот режим на собирање, записите завршуваат во табелата AzureDiagnostics и категоријата се појавува како вредност на колона; кај табелите специфични за ресурсот, портата има своја табела. Во секој случај, прашајте по ресурсот на портата и временскиот прозорец околу неуспешниот обид, а потоа читајте ја корелацијата наместо поединечните редови:

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

Множеството колони го следи вашиот режим на собирање, па третирајте го прашањето како форма, а не како скрипта. Она што го барате е адреса на клиент што се појавува и потоа исчезнува, со тип на резултат што не е успех.

Спојте го записот на портата со сопствениот поглед на клиентот

Логовите на портата го опишуваат тунелот, а не зошто лаптоп не успеал да изгради еден. Соберете ја клиентската страна на истиот временски печат: дневникот на настани на Windows за клиентот RAS, дневникот за врски на macOS или текстот на грешката што ја прикажал клиентската апликација. Запис на портата без соодветен обид на клиентот укажува на клиентот; клиент што известува за успех додека портата не запишува ништо обично значи дека профилот е насочен кон друга порта.

Држете ги двете половини во ист тикет. Само логот на портата наведува на погрешен заклучок, а само логот на клиентот не може да покаже дали пакетот некогаш пристигнал.

Ако никаде не се појавува ништо, проверете го часовникот на клиентот пред да се сомневате во платформата. Искривените временски печати прават корелацијата да не успее на начин што изгледа точно како податоци што недостасуваат.

Задржување, опфат и записот во runbook

Записите за тунелот носат адреси на клиенти и временски печати на врски, па третирајте ги како лични податоци со распоред за бришење наместо да го оставите стандардното поставување на платформата. Проверете и дека работниот простор не прима секоја категорија од секој ресурс во претплатата, зашто бучен работен простор ја прави корелацијата побавна отколку директно читање на клиентскиот лог.

На крајот, запишете го името на поставувањето, работниот простор и избраните категории во runbook-от на портата. Следното лице што ќе отстранува грешки на клиент прво ќе погледне во панелот на портата, нема да најде ништо и ќе заклучи дека логовите не постојат.