მომხმარებელი ვერ უკავშირდება 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-ში. შემდეგი ადამიანი, ვინც კლიენტს გამართავს, პირველად გეითვეის დაფას შეხედავს, ვერაფერს იპოვის და დაასკვნის, რომ ჟურნალები არ არსებობს.

დაკავშირებული სტატიები