WSL2-მ DNS დაკარგა VPN-ის დაკავშირების შემდეგ? ორი მიზეზი

მოძველებული resolver ფაილი და კონკურენტული მარშრუტის მეტრიკა ერთსა და იმავე სიმპტომს ქმნიან WSL2-ის შიგნით. ჩაწერეთ ორივე მხარე და შემდეგ შეაკეთეთ ის, რაც ნამდვილად გატეხილია.

Ping მისამართით მუშაობს დისტრიბუციის შიგნით, პაკეტების ინსტალაცია და git-ის ჩამოტანა არა, და ხარვეზი გამოჩნდა გვირაბის აწევისთანავე. მხოლოდ სახელებმა შეწყვიტეს გადაწყვეტა, რაც DNS-ზე მიუთითებს და არა კავშირზე. პაკეტების ხელახლა ინსტალაცია აქ ყველაზე პოპულარული არასწორი პირველი ნაბიჯია. WSL2-ს სწორედ ამ სიმპტომის შექმნის ორი დამოუკიდებელი გზა აქვს და ორივეს განსხვავებული შეკეთება სჭირდება.

რატომ ინახავს დისტრიბუცია საკუთარ resolver-ს

Windows-ის DNS კლიენტი დისტრიბუციის შიგნით არ გამოიყენება. WSL2 გაშვებისას თავის resolver ფაილს ქმნის, რომელიც stub მისამართზე მიუთითებს, რომელსაც Windows ვირტუალურ გადამრთველზე აქვეყნებს დამხმარე ვირტუალური მანქანისთვის.

ეს განლაგება ჩვეულებრივი ქსელური ცვლილებების დროს სტაბილურია, რადგან ერთხელ იწერება და ხელახლა გამოიყენება. განლაგება წყვეტს სწორობას, როცა გვირაბის კლიენტი ხელახლა წერს ჰოსტის ადაპტერების სიას მას შემდეგ, რაც დამხმარე ვირტუალური მანქანა უკვე გაშვებულია.

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

ჯერ ორივე მხრიდან შეაგროვეთ მტკიცებულებები

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

დისტრიბუციის შიგნით დაბეჭდეთ resolver ფაილი, მარშრუტიზაციის ცხრილი და ერთი შიდა და ერთი საჯარო ძებნა:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

Windows-ზე ჩამოთვალეთ DNS სერვერები ადაპტერების მიხედვით და IPv4 ცხრილი მეტრიკებით. VPN კლიენტი ჩვეულებრივ აყენებს მარშრუტს WSL2-ის ქვექსელისთვის და მისი მეტრიკა წყვეტს, ეს ტრაფიკი გვირაბიდან გავა თუ ლოკალური დარჩება.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

მარშრუტის მეტრიკა თუ მოძველებული ფაილი

პირველი ხარვეზი მოძველებული ფაილია. resolver დაიწერა გაშვების დროის ადაპტერის მდგომარეობისთვის და გვირაბმა ეს მდგომარეობა შეცვალა. მისი stub მისამართი ახლა შეიძლება მიუწვდომელი იყოს, ან დაასახელოს სერვერი, რომელმაც შიდა ზონაზე არაფერი იცის.

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

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

მარშრუტიზაციის შემთხვევისთვის მოხსენით ავტომატური მეტრიკა გვირაბის ადაპტერიდან და მიეცით WSL2-ის ბმულის მარშრუტზე მაღალი რიცხვი:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

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

აიღეთ ფაილი, განზრახ

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

დისტრიბუციის შიგნით შექმენით /etc/wsl.conf ქსელური სექციით, რომელიც გენერაციას გამორთავს, შემდეგ თავად დაწერეთ resolver ფაილი, ჯერ კორპორატიული სერვერი და შემდეგ საჯარო სარეზერვო:

[network]
generateResolvConf = false
search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

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

შეამოწმეთ სახელები, შემდეგ პაკეტები

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

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

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

მომუშავე შიდა ძებნა და მომუშავე საჯარო ძებნა, დისტრიბუციის შიგნიდან, არის შედეგი, რომლის ჩაწერაც ღირს. მწვანე VPN ხატულა ჰოსტზე არც ერთს არ ამტკიცებს.

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