Nasaan ang mga log ng Azure Point-to-Site VPN? Tingnan sa Monitor

Hindi makakonekta ang isang user sa gateway ng Point-to-Site, bubuksan mo ang blade ng gateway, at walang kasaysayan ng koneksyon kahit saan sa pahina. Konfigurasyon, mga sertipiko, status: naroon lahat, walang talaan. Umiiral ang mga log, ngunit hindi talaga sila ginagawa ng mga pahina ng network. Nagmumula sila sa isang diagnostic setting na nakakabit sa resource ng gateway, at ang setting na iyon ay nasa ilalim ng Monitor; kaya't ang unang paghahanap sa halatang lugar ay walang ibinabalik, at napagpasyahan ng mga tao na ang serbisyo ay walang itinataguyod na audit trail.

Bakit nabibigo ang halatang paghahanap

Sinasabi ng mga lumang gabay na walang auditing ang Azure Point-to-Site VPN, at totoo iyon noong hindi naglalantad ang serbisyo ng talaan sa bawat koneksyon. Naglalathala ang mga kasalukuyang gateway ng mga diagnostic record ng tunnel, kaya nagbago ang kapaki-pakinabang na tanong: hindi kung may mga log, kundi aling resource ang naglalabas ng mga ito at aling kategorya ang inilagay mo. Ang blade ng gateway ay isang ibabaw ng konfigurasyon, at bihirang magsilbing log viewer ang mga ibabaw ng konfigurasyon. Ang diagnostic setting ay isang object sa bawat resource, kaya ang resource na pipiliin mo ang magtatakda ng lahat ng susunod.

Ang kabilang kalahati ng pagkalito ay ang authentication. Ang mga koneksyong Point-to-Site na nakabatay sa sertipiko ay hindi gumagawa ng event ng pag-sign in sa bawat user tulad ng ginagawa ng identity provider, kaya walang talaan ng isang pinangalanang tao na nagta-type ng password.

Ikabit ang diagnostic setting sa resource ng gateway

Buksan ang Monitor, pagkatapos ang Diagnostic settings, at magdagdag ng bagong setting na ang target ay ang virtual network gateway mismo at hindi ang virtual network na naglalaman nito. Piliin ang diagnostic category ng Point-to-Site, ang tinatawag na P2SDiagnosticLog, dahil ito ang nagdadala ng mga talaan ng koneksyon sa bawat kliyente; idagdag ang mga kategoryang tunnel, ruta o IKE para lamang sa mga error na site-to-site na sakop nila. Pagkatapos ay ipadala ang data sa isang Log Analytics workspace na kontrolado mo, na may retention period na sinadya mong piliin. Karamihan ng nabigong paghahanap ay setting na nakakabit sa maling resource, hindi kulang na feature.

Nag-iiba ang mga listahan ng kategorya ayon sa uri at henerasyon ng gateway. Kung wala ang kategoryang Point-to-Site, maaaring mas luma ang gateway kaysa sa feature o gumagamit ito ng SKU na hindi kailanman naglalabas nito, kaya suriin ang mga sinusuportahang kategorya bago maghanap ng problema sa pahintulot. Ang gateway na walang kategoryang Point-to-Site ay hindi sira; hindi lamang ito maaaring maging pinagmulan ng talaang iyon, at ang pinakamalapit na kapalit ay ang kategoryang tunnel o IKE, na nagtatala ng address ng kliyente kahit hindi nito inilalarawan ang isang sesyon ng Point-to-Site. Kumpirmahin ang listahan ng kategorya bago magbukas ng support case tungkol sa nawawalang log.

Basahin ang mga talaan sa talahanayang ginagamit ng iyong mode

Sa lumang collection mode, napupunta ang mga entry sa talahanayang AzureDiagnostics at lumilitaw ang kategorya bilang halaga ng column; sa mga talahanayang partikular sa resource, may sariling talahanayan ang gateway. Sa anumang kaso, mag-query ayon sa resource ng gateway at sa isang window sa paligid ng nabigong pagtatangka, pagkatapos ay basahin ang correlation sa halip na ang mga indibidwal na row:

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

Ang set ng column ay sumusunod sa iyong collection mode, kaya ituring ang query bilang isang hugis at hindi bilang script. Ang hinahanap mo ay isang address ng kliyente na lumilitaw at pagkatapos ay nawawala, na may uri ng resulta na hindi tagumpay.

Itugma ang talaan ng gateway sa pananaw ng kliyente

Inilalarawan ng mga log ng gateway ang tunnel, hindi kung bakit nabigo ang isang laptop na bumuo nito. Kolektahin ang panig ng kliyente sa parehong timestamp: ang log ng mga event ng Windows para sa kliyenteng RAS, ang log ng koneksyon ng macOS, o ang teksto ng error na ipinakita ng app ng kliyente. Ang talaan ng gateway na walang katumbas na pagtatangka ng kliyente ay tumutukoy sa kliyente; ang kliyenteng nag-uulat ng tagumpay habang walang itinatala ang gateway ay karaniwang nangangahulugan na ang profile ay nakaturo sa ibang gateway.

Panatilihin ang parehong kalahati sa iisang ticket. Ang log ng gateway lamang ay nag-aanyaya ng maling konklusyon, at ang log ng kliyente lamang ay hindi maipapakita kung nakarating ba ang packet.

Kung walang lumilitaw sa alinman sa dalawang lugar, suriin ang orasan sa kliyente bago pagdudahan ang platform. Ang mga skewed timestamp ay nagpapabigo sa correlation sa paraang mukhang eksaktong nawawalang data.

Retention, saklaw at ang entry sa runbook

Ang mga talaan ng tunnel ay nagdadala ng mga address ng kliyente at timestamp ng koneksyon, kaya ituring ang mga ito bilang personal na data na may deletion schedule sa halip na iwanan ang default ng platform. Suriin din na hindi ini-ingest ng workspace ang bawat kategorya mula sa bawat resource sa subscription, dahil ang maingay na workspace ay nagpapabagal sa correlation kaysa sa direktang pagbasa ng log ng kliyente.

Sa wakas, isulat ang pangalan ng setting, ang workspace at ang mga napiling kategorya sa runbook ng gateway. Ang susunod na taong magde-debug ng kliyente ay titingin muna sa blade ng gateway, walang makikita, at maghihinuha na wala ang mga log.