Azure P2S VPN კერძო ბოლო წერტილის სახელს ვერ ხსნის

უერთდებით point-to-site გვირაბს, პინგავთ კერძო მისამართს, ხსნით აპს და სამაგიეროდ იღებთ 403-ს ან სერტიფიკატის შეცდომას. ორივე სიმპტომი DNS-ზე მიუთითებს, მაგრამ ეს სხვადასხვა ხარვეზია: ერთი ნიშნავს, რომ კლიენტმა საჯარო მისამართი გახსნა, მეორე — რომ კერძო მისამართი გახსნა და შემდეგ შესთავაზა სახელი, რომელსაც სერტიფიკატი არ ფარავს. გაიარეთ ქვემოთ მოცემული შემოწმებები თანმიმდევრობით და შეჩერდით პირველ წარუმატებლობაზე, რადგან hosts ჩანაწერმა ან ქეშირებულმა პასუხმა შეიძლება ყოველი შემდგომი შემოწმება არასწორი მიზეზით გაატაროს. ამ თანმიმდევრობას ტექსტურ ფაილში ვინახავ ჩემი VPN პროფილების გვერდით, რადგან შესწორება გვირაბში არაფერს ცვლის და ყველაფერს ცვლის იმაში, რაც კლიენტმა იცის.

დაიწყეთ იმ მისამართით, რომელსაც კლიენტი რეალურად იღებს

ჰკითხეთ გამხსნელს პირდაპირ, აპლიკაციის ნდობის ნაცვლად. Windows-ზე nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net გვიჩვენებს, რომელი ხედი მიიღო კლიენტმა. საჯარო პასუხი ნიშნავს, რომ ქვემოთ ვერაფერი მიაღწევს ბოლო წერტილს; ბოლო წერტილის კერძო მისამართი ნიშნავს, რომ DNS დასრულდა და შემდეგი შემოწმება თავად კავშირია.

კერძო ბოლო წერტილი არ ცვლის სერვისის სახელს. ანგარიში ან აპი ინარჩუნებს ჩვეულ სრულად კვალიფიცირებულ სახელს, ხოლო ბოლო წერტილი მხოლოდ იმ მისამართს ცვლის, რომელზეც ეს სახელი ვირტუალური ქსელის შიგნით მყოფი კლიენტებისთვის იხსნება. ამიტომ ერთი და იგივე ჰოსტის სახელი კერძოდ იხსნება ქსელში არსებული VM-იდან და საჯაროდ — ლეპტოპიდან, რომელსაც კერძო ხედი არასდროს მიუღია.

შეამოწმეთ ზონა, მისი ბმული და ჩანაწერი გვირაბამდე

სამი პირობა ერთდროულად უნდა სრულდებოდეს: კერძო ზონა არსებობს, დაკავშირებულია ვირტუალურ ქსელთან, სადაც VPN კარიბჭე და კლიენტები Azure-ში შედიან, და შეიცავს A ჩანაწერს ბოლო წერტილისთვის, რომელიც კერძო მისამართზე მიუთითებს. დაუკავშირეთ ზონა ურთიერთობის გარეშე ქსელს და კარიბჭე გააგრძელებს საჯარო ჩანაწერის გარჩევას, სანამ გვირაბზე ყველაფერი ჯანმრთელად გამოიყურება.

ზონების სახელები სერვისებს ეკუთვნის და არა ზოგადად კერძო ბმულებს. App Service ჩვეულებრივ იყენებს privatelink.azurewebsites.net-ს, საცავსა და SQL-ს საკუთარი სახელების სივრცეები აქვთ, ხოლო სხვა სერვისის ზონის სესხება ქმნის ზონას, რომელიც არსებობს და სასარგებლო პასუხს არ იძლევა.

მიეცით კლიენტს გამხსნელი, რომელსაც ის ნამდვილად მიაღწევს

168.63.129.16 პასუხობს Azure-ის ვირტუალური მანქანებიდან და არ არის DNS სერვერი point-to-site გვირაბის მეორე მხარეს მყოფი ლეპტოპისთვის. კლიენტს სჭირდება გვირაბით მისადგომი გამხსნელი: Azure DNS Private Resolver-ის შემომავალი ბოლო წერტილი, გამტარი ვირტუალური ქსელის შიგნით, ან VPN კლიენტის პროფილში გადატანილი DNS სერვერის ჩანაწერები, რომ კლიენტმა ვირტუალურ ქსელს პირდაპირ ჰკითხოს.

კონფიგურირებული, მაგრამ მიუწვდომელი გამხსნელი ზუსტად ისე იქცევა, როგორც გამხსნელის არარსებობა, და სიმპტომი დროის ამოწურვაა და არა არასწორი პასუხი, ამიტომ მას შეცდომით firewall-ის პრობლემად კითხულობენ. შეამოწმეთ ის მოთხოვნით, რომელიც გვირაბმა უნდა გადაიტანოს, და არა საჯარო სახელით, რომელიც ადგილობრივ ბმულზე მაინც გაივლიდა.

თუ გადაამისამართებთ და არა აყენებთ პარამეტრებს, გადაამისამართეთ სახელების სივრცე, რომელიც კერძო ზონას ეკუთვნის — privatelink.azurewebsites.net და არა მთელი azurewebsites.net. პირობითი გამტარი, რომელიც მთელ მშობელ სუფიქსს ყლაპავს, სერვისის ყოველ ძიებას Azure-ში აგზავნის, მათ შორის იმასაც, რომელიც ადგილობრივი უნდა დარჩეს.

გამოიყენეთ სახელი, რომლისთვისაც სერტიფიკატი გაიცა

როცა მისამართი სწორია, მეორე ხარვეზი ჩნდება. საცავი და App Service აქვეყნებენ privatelink ფსევდონიმს და ეს ფსევდონიმი სულაც არ არის სერტიფიკატში მოცემული სახელი. privatelink.blob.core.windows.net-ზე მიმართული AzCopy ატვირთვა ვერ გაიარა ვალიდაცია; იგივე ატვირთვა <account>.blob.core.windows.net/<container>-ზე კერძო მისამართზე გაიხსნა და გაიარა, ამიტომ ის კერძო გზაზე დარჩა რაიმე გვერდის ავლის გარეშე.

წესი მოქმედებს ბრაუზერშიც და App Service-ისთვისაც: დაუკავშირდით ჰოსტის სახელს, რომელსაც სერტიფიკატი ფარავს, და მიეცით DNS-ს კერძო მისამართის მოწოდების საშუალება. ნუ მიმართავთ ვალიდაციის გვერდის ავლას, რადგან ის სახელის შეცდომას უსაფრთხოების რეგრესად აქცევს. წარმატებული ping ადასტურებს მარშრუტს და არაფერს ამბობს ხელის ჩამორთმევის შიგნით არსებულ სახელზე, ამიტომ ეს ცალკე შემოწმებებად რჩება.

ოთხსაფეხურიანი რიგი, რომელიც ყოველ ფენას იზოლირებს

1. დაადასტურეთ, რომ VPN კლიენტს აქვს მისამართი point-to-site აუზიდან და მარშრუტი ბოლო წერტილის კერძო მისამართამდე.
2. გახსენით ზუსტად ის სახელი, რომელსაც აპი იყენებს, და შეადარეთ პასუხი ბოლო წერტილის მისამართს.
3. გახსენით TCP კავშირი ბოლო წერტილთან სერვისის პორტზე, შემდეგ წაიკითხეთ ამ კავშირზე წარმოდგენილი სერტიფიკატის სახელი.
4. მხოლოდ ახლა შეამოწმეთ ავტორიზაცია, რადგან მომუშავე გზა და მოქმედი სერტიფიკატი ჯერ არ იძლევა რესურსზე წვდომას.

სწორი მისამართის დროს უარყოფილი კავშირი მიუთითებს ქსელის უსაფრთხოების ჯგუფზე ან კერძო ბოლო წერტილის კავშირის მდგომარეობაზე და არა DNS-ზე, ამიტომ შეამოწმეთ ისინი, სანამ გამხსნელის პარამეტრებს ხელახლა შეასწორებთ. TLS სახელის შეუთავსებლობა გაბრუნებთ URL-ის ჰოსტის სახელსა და სერტიფიკატის subject-ზე. შეინახეთ ერთად გარჩევის გამომავალი, სერტიფიკატის სახელი და ზუსტი URL; ეს სამი მნიშვნელობა ხსნის ამ შემთხვევების უმეტესობას კარიბჭეზე ხელის შეხების გარეშე.

როგორც კონტროლი გამოიყენეთ VM ვირტუალური ქსელის შიგნით. თუ სახელი იქ კერძოდ იხსნება, ხოლო გვირაბიდან — საჯაროდ, ზონა და ჩანაწერი სწორია და ერთადერთი განსხვავება კლიენტის გამხსნელის გზაა, რაც უფრო სწრაფად დასტურდება, ვიდრე ბოლო წერტილის კონფიგურაციაზე კიდევ ერთი გავლა.

კლიენტები ქეშსაც ინახავენ. ჩანაწერი, რომელმაც ათი წუთის წინ საჯაროდ უპასუხა, განაგრძობს პასუხს ზონის გასწორების შემდეგაც, ამიტომ ხელახლა ტესტამდე გაასუფთავეთ ქეში. Windows-ზე ipconfig /flushdns წმენდს კლიენტის ქეშს; სახელების გარჩევის პოლიტიკის წესები რჩება, განსაზღვრავს, რომელი სუფიქსი რომელ სერვერზე მიდის და შეიძლება სახელების სივრცე კვლავ იმ გამხსნელს გაუგზავნოს, რომელიც ახლახან შეცვალეთ.

სად უნდა იყოს hosts ჩანაწერი

ბოლო წერტილის მისამართის hosts ფაილში დამატება კარგი დიაგნოსტიკაა და ცუდი დიზაინი. ის ადასტურებს, რომ სახელის მისამართთან შესაბამისობაა დაკარგული ნაწილი, და საშუალებას გაძლევთ შეამოწმოთ ყველაფერი ამ ნაბიჯის შემდეგ, მაგრამ თქვენი მომხმარებლებისთვის უხილავია, ფუჭდება, როცა ბოლო წერტილის მისამართი იცვლება, და მალავს იმ ზონას, რომელმაც უნდა უპასუხოს.

დარჩენილი საცდელი ჩანაწერი უარესია ვიდრე მოძველებული ქეში, რადგან შეცდომის მიმართულებიდან გამომდინარე შეიძლება გასწორებული გზა დაზიანებულად ან დაზიანებული გზა გასწორებულად აჩვენოს. წაშალეთ ის საბოლოო გაშვებამდე და გახსენით მხოლოდ წარმოების გამხსნელით.

მოკლე სახელებს საძიებო სუფიქსი სჭირდება, სრულად კვალიფიცირებულს — არა, ამიტომ ჯერ სრულად კვალიფიცირებული სახელი შეამოწმეთ, შემდეგ გადაწყვიტეთ, სჭირდება თუ არა სამუშაო პროცესს კლიენტის პროფილით გადაცემული სუფიქსი. Microsoft თითოეული სერვისისთვის ზონების სახელებსა და ჩანაწერების ფორმებს აღწერს თავის კერძო ბოლო წერტილების DNS სახელმძღვანელოში; წაიკითხეთ თქვენი სერვისის ჩანაწერი და ნუ დააკოპირებთ ზონას სხვა სერვისიდან.