ვინ უნდა გამოიყენოს სინამდვილეში OpenConnect-ის DNS პარამეტრები Windows-ზე?
Windows რეზოლვერის მდგომარეობას სამ ადგილას ინახავს. იპოვეთ ის დამხმარე, რომელსაც კავშირი ეკუთვნის, სანამ ადაპტერის DNS-ს ხელით შეასწორებთ ან სახელთა სივრცის წესს დაამატებთ.
გვირაბის ამოწევა იგივე არ არის, რაც მისი DNS მნიშვნელობების დაყენება. OpenConnect მოლაპარაკებას აწარმოებს, ხოლო Windows-ის მხარეს დამხმარე იყენებს. ამ ორ ნაბიჯს შორის სხვაობა ხსნის კერძო სახელების წარუმატებლობების უმეტესობას ამ კლიენტზე, და დამხმარე თითქმის არასდროს არის Windows-ის VPN პარამეტრების გვერდი.
გამოყავით ის, რაც კარიბჭემ შესთავაზა, იმისგან, რაც Windows-მა დააყენა
კლიენტი კავშირის მონაცემებს სკრიპტის ინტერფეისს გადასცემს, ხოლო Unix-ისა და Windows-ის ვარიანტები ცალკე პროგრამებია. Windows-ზე განხორციელება ჩვეულებრივ JavaScript დამხმარეა, რომელიც კითხულობს ცვლადებს, როგორიცაა შიდა DNS სერვერი და შიდა დომენი, სანამ რომელიმე ადაპტერს შეეხება. თავად გვირაბში არაფერი წერს რეზოლვერის მდგომარეობას.
ეს გაყოფა მნიშვნელოვანია, რადგან მნიშვნელობა შეიძლება არსებობდეს მოლაპარაკებაში და არასდროს მიაღწიოს ადაპტერს. დამხმარე, რომელიც აკლია, ნახევარ გზაზე ფუჭდება ან GUI-ის გარსში ჩასმული ძველი ასლია, Windows-ს ტოვებს ზუსტად ისე, როგორც იყო. სესია დაკავშირებულად გამოიყურება, კერძო სახელი კვლავ ადგილობრივი მომწოდებლის მეშვეობით წყდება, და კლიენტის ფანჯარაში არაფერი მიუთითებს განსხვავებაზე. დამხმარის საკუთარი გამოსავლის წაკითხვა ერთადერთი საიმედო გზაა იმის გასაგებად, რომელი ეტაპი გატყდა.
| Stage | What exists there | Where you see it |
|---|---|---|
| Negotiated | Internal DNS address and domain pushed by the gateway | Client log or helper input |
| Installed | Adapter DNS entry, connection suffix, or namespace rule | Adapter and policy queries |
| Selected | Resolver Windows uses for one specific query | The failing application |
GUI-ის გარსმა შეიძლება კლიენტისა და დამხმარის საკუთარი ასლი მოიტანოს, ამიტომ დისკზე სხვაგან მეორე openconnect.exe არაფერს ამტკიცებს. იპოვეთ ის შესრულებადი ფაილი, რომელმაც სესია დაიწყო, სანამ მის კონფიგურაციას შეაფასებთ.
წაიკითხეთ რეზოლვერის მდგომარეობა მისი შეცვლის გარეშე
სამი მხოლოდ-წაკითხვის მოთხოვნა ფარავს ჩვეულ გაუგებრობას, და თითოეული სხვა კითხვას პასუხობს:
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effectiveადაპტერის დონის სერვერი არის ის, რასაც ადამიანების უმეტესობა გულისხმობს VPN DNS-ში. კავშირზე სპეციფიკური სუფიქსი წყვეტს, საერთოდ გაფართოვდება თუ არა მოკლე სახელი. სახელთა სივრცის პოლიტიკის სია ეხება შესაბამის სახელებს ადაპტერების თანმიმდევრობის მიუხედავად, და იქ ცარიელი შედეგი არ არის ხარვეზი, როცა დამხმარეს არასდროს ჰქონია მისი შექმნის განზრახვა. სამივეს წაკითხვა რედაქტირებამდე სწორედ ის არის, რაც ხელს უშლის შეკეთებას, რომელიც მხოლოდ სიმპტომს გადაიტანს სხვაგან.
დაიწყეთ სრულად კვალიფიცირებული სახელით. თუ FQDN წყდება და მოკლე სახელი არა, ხარვეზი სუფიქსი ან ძებნის სიაა, და არა სერვერის მისამართი.
მეორე ნაბიჯად ჰკითხეთ განზრახ სერვერს პირდაპირ, უკვე დაყენებული ნებისმიერი რეზოლვერის ხელსაწყოთი. პირდაპირი პასუხი ამტკიცებს, რომ სერვერი მისაწვდომია და ზონისთვის უფლებამოსილია. ეს არაფერს ამტკიცებს იმის შესახებ, რომელ სერვერს ეკითხება აპლიკაცია ნაგულისხმევად.
დაასახელეთ კომპონენტი, რომელსაც კავშირი ეკუთვნის
ორი განლაგება გავრცელებულია. ტერმინალიდან გაშვებული კლიენტი თავისი სკრიპტის გზას აშკარად გადასცემს, ამიტომ მფლობელი ჩანს გაშვებულ ბრძანებაში. შეფუთული აპლიკაცია კლიენტს თქვენ ნაცვლად უშვებს და დამხმარეს საკუთარ დირექტორიაში ინახავს, რაც ნიშნავს, რომ მიმწოდებელი წყვეტს, როდის შეიცვლება ის.
შეადარეთ დამხმარის ვერსიები ინსტალაციებს შორის, სანამ რამეს შეცვლით. სარკიდან ჩამოტანილი დამხმარის გაზრდილი უფლებებით გაშვება მხოლოდ იმიტომ, რომ ფაილის სახელი ნაცნობად გამოიყურება, DNS-ის ხარვეზს უსაფრთხოების ინციდენტად აქცევს.
მას შემდეგ, რაც მფლობელი ცნობილია, შეკეთების სამიზნე აშკარა ხდება: მხარდაჭერილი სკრიპტის გზა გამშვებში, პაკეტის განახლება ან შესწორებული პროფილი კარიბჭეზე. არცერთი მათგანი არ მოითხოვს ადაპტერის თვისებების ხელით რედაქტირებას.
შეაკეთეთ მფლობელი და არა ადაპტერი
ადაპტერზე ხელით დაყენებული DNS ხშირად გადაურჩება გათიშვას, ამიტომ ჩანს, რომ მუშაობს, და შემდეგ შემდეგ ქსელში პრობლემას იწვევს. ყველა ინტერფეისზე მიჭანჭიკებული საჯარო რეზოლვერი მალავს კერძო სახელთა სივრცის პრობლემას მისი გადაჭრის ნაცვლად. როცა დამხმარეს არასდროს მიუღია DNS მნიშვნელობა, კარიბჭის პროფილია სანახავი ადგილი. როცა მიიღო და ადაპტერი კვლავ ძველ სერვერს აჩვენებს, დამხმარე დაკავშირების დროს ჩავარდა და კლიენტის ჟურნალი ჩვეულებრივ ამას გვირაბის კონფიგურაციის სტრიქონებთან აღრიცხავს.
თავიდან ააშენეთ მდგომარეობა მხარდაჭერილი გზით, შემდეგ გადაამოწმეთ მთელი ციკლი: დაუკავშირდით, ამოხსენით კერძო FQDN, გახსენით სერვისი, გათიშეთ და დაადასტურეთ, რომ ადაპტერი წინა სერვერებით დაბრუნდა.
შეამოწმეთ აპლიკაცია, რომელიც რეალურად ფუჭდება
ბრაუზერი საკუთარი დაშიფრული DNS პარამეტრით უგულებელყოფს ყველაფერს ზემოთ და აგრძელებს პასუხს საჯარო რეზოლვერიდან. აპლიკაცია, რომელიც ინახავს ქეშირებულ უარყოფით პასუხს გვირაბის ამოწევამდე, იგივენაირად იქცევა. შეადარეთ ის იმავე მანქანაზე ჩვეულებრივ სისტემურ მოთხოვნას, სანამ რეზოლვერის მისამართებს კვლავ შეცვლით.
თუ სისტემური მოთხოვნა სწორია და აპლიკაცია არა, დარჩენილი ხარვეზი იმ აპლიკაციის DNS კონფიგურაციაშია, და არა VPN-ის გზაზე.