რატომ კარგავს WSL სამუშაო ჰოსტის სახელს, როცა VPN უკავშირდება?
იგივე სახელი მუშაობს Windows-ში და ვერ მუშაობს WSL-ის შიგნით, როგორც კი გვირაბი ამოდის. გადაამოწმეთ პლატფორმის DNS რეჟიმი და მოძველებული გადაფარვები, სანამ გადამწყვეტს დაამატებთ.
Windows შიდა ჰოსტს უპრეტენზიოდ წყვეტს, ხოლო იგივე სახელი WSL-ის შიგნით იმ წამსვე ვარდება, როცა გვირაბი ამოდის. ჩვეულებრივი შესწორება დისტრიბუციაში საჯარო გადამწყვეტის ჩაწერაა, რაც ჩვეულებრივ დათვალიერებას აღადგენს და სამუშაო ჰოსტის სახელს ამოუცნობს ხდის. ეს ერთ ჩავარდნას მეორეთი ცვლის და მალავს იმ შრეს, რომელიც რეალურად გატყდა. სანამ გადამწყვეტის რომელიმე ხაზს დაამატებთ ან წაშლით, დაადგინეთ, სამი შრიდან რომელი ვარდება.
ჯერ გამორიცხეთ მარშრუტიზაციის ჩავარდნა
ორივე მხარეს იკითხეთ ზუსტად იგივე სრულად კვალიფიცირებული სახელი, და არა ორი მსგავსი სახელი. იგივე სტრიქონისთვის Windows-ში წარმატება და WSL-ში ჩავარდნა ორი ამოხსნის გზის ხელმოწერაა, და ცოტა რამ სხვა ქმნის ამ ნიმუშს ასე სუფთად. თუ WSL ვერ აღწევს სერვისს მის ცნობილ რიცხვით მისამართზეც, მაშინ მარშრუტიზაციის ან ფილტრაციის პრობლემაც არსებობს. ამ შემთხვევაში DNS-ის სამუშაო ამას არ გამოავლენს, და შუადღე არასწორ შრეზე წავა.
სამი სიმპტომი ფარავს ამ შემთხვევათა უმეტესობას, და თითოეული სხვა ადგილას მიუთითებს. კონფიგურაციის ფაილის გახსნამდე წაიკითხეთ შესაბამისი სტრიქონი:
| Symptom inside WSL | Likely layer | Where to look |
|---|---|---|
| Private name fails while public browsing works | Resolver path | Tunneling mode and the Windows build |
| A name that worked yesterday fails today | Stale override | Generated resolver file, immutable flag, shell profile |
| The name resolves but the service does not | Routing or filtering | The resolved address and the path to it |
შუა სტრიქონი ის არის, რომელსაც ხალხი არასწორად კითხულობს, რადგან ის ცვლილება, რომელმაც ის გატეხა, კვირების წინ გაკეთდა და მაშინ წარმატებულად ჩანდა. მესამე სტრიქონი ის არის, რომელსაც ხალხი არასწორად დიაგნოსტირებს, რადგან ამოხსნადი სახელი ქსელის ჯანმრთელობის მტკიცებად აღიქმება. ორივე სტრიქონი ქვემოთ სხვადასხვა განყოფილებაში გიგზავნით.
DNS გვირაბიზაციას აქვს ვერსიის ქვედა ზღვარი
Microsoft აღწერს WSL-ის ქსელურ რეჟიმს, რომელიც DNS მოთხოვნებს ვირტუალიზაციის არხით Windows-ის გადამწყვეტამდე ატარებს. მხარდაჭერილ Windows 11 კრებებზე ის ნაგულისხმევად ჩართულია, ამიტომ ერთსა და იმავე კორპორატიულ ქსელში ორი მანქანა განსხვავებულად იქცევა. ცვლადი კრების ნომერია და არა კორპორატიული პოლიტიკა.
WSL-ის ქსელის გზამკვლევი აღწერს ამ რეჟიმს და იმ ვერსიებს, რომლებიც მას მხარს უჭერენ. ფუნქცია მნიშვნელოვანია, რადგან კორპორატიული DNS პოლიტიკა ჩვეულებრივ Windows-ის გადამწყვეტში ცხოვრობს, და დისტრიბუცია, რომელიც Windows-ის გზას მემკვიდრეობით იღებს, პოლიტიკასაც იღებს. საჯარო გადამწყვეტს რომ ეკითხება, დისტრიბუციას კერძო სახელამდე არავითარი გზა არ აქვს, რაც არ უნდა მოწესრიგებული ჩანდეს მისი საკუთარი კონფიგურაცია. ეს მექანიზმი ხსნის მთელ სიმპტომს და ხსნის, რატომ ვარდება საჯარო-გადამწყვეტიანი შემოვლითი გზა.
წაიკითხეთ კრება, სანამ რამეს შეასწორებთ. უფრო ახალი ინსტალაციიდან კოპირებული პარამეტრი არ არის მტკიცება, რომ უფრო ძველი მას ახორციელებს. ჩაწერეთ კრების ნომერი ცვლილების გვერდით, რადგან ორ მანქანას შორის განსხვავება თითქმის ყოველთვის ვერსიაა და არა პოლიტიკა.
ძველი გადაფარვები იმაზე დიდხანს ცოცხლობენ, ვიდრე მათ მიერ გადაწყვეტილი პრობლემა
უფრო ძველი რეცეპტები თიშავდნენ გენერირებულ გადამწყვეტის ფაილებს, ხისტად წერდნენ სახელების სერვერს ან კეტავდნენ ფაილს უცვლელობის ატრიბუტით. ეს ცვლილებები ადგილზე რჩება დიდხანს მას შემდეგ, რაც მათ გამომწვევი კავშირის პრობლემა გაქრა, და ჩვეულებრივ სწორედ ისინი არიან მიზეზი, რომ უფრო ახალი პარამეტრი თითქოს არაფერს აკეთებს. ისინი ასევე გადაიტანს დისტრიბუციის ხელახალ ინსტალაციას shell პროფილის სახით, რომელიც ფაილს ყოველ შესვლაზე გადაწერს. უკანასკნელის პოვნა ყველაზე ძნელია, რადგან ის უხილავია იმ ფაილიდან, რომელსაც ყველა ამოწმებს.
მოძებნეთ ხელით დაწერილი გადამწყვეტის ფაილი, მასზე უცვლელობის ატრიბუტი და გაშვების სკრიპტი, რომელიც მას გადაწერს. შესწორებამდე შეამოწმეთ უცვლელობის დროშა, რადგან ჩაკეტილ ფაილში ჩაწერა ისე ვარდება, რომ ნებართვის პრობლემად იკითხება. შემდეგ შეამოწმეთ shell პროფილი, რადგან იქაური სკრიპტი თქვენი შესწორებიდან წამებში აღადგენს ძველ შიგთავსს.
გადაფარვის წაშლას შედეგები აქვს, ამიტომ ჩაწერეთ, რა წაშალეთ და რატომ. დისტრიბუცია, რომელსაც სხვა მიზნისთვის ნამდვილად სჭირდება სტატიკური გადამწყვეტი, გატყდება, როცა გენერირებული ფაილი დაბრუნდება.
ორი ფაილი, ორი განსხვავებული როლი
ორი კონფიგურაციის ფაილი სხვადასხვა ადგილას ცხოვრობს და სხვადასხვა რამეს აკონტროლებს, და მათი აღრევა არასწორ შრეზე გამოყენებულ შესწორებებს წარმოშობს. Windows-ის მხარეს ფაილი ვირტუალური მანქანის თვისებებს აყენებს, ხოლო დისტრიბუციის მხარეს ფაილი აყენებს, როგორ აშენებს ეს დისტრიბუცია საკუთარ გადამწყვეტის კონფიგურაციას. არც ერთი არ ფარავს მეორეს, ამიტომ ორივე უნდა შეთანხმდეს.
ინსტალაციისთვის, რომელიც მხარს უჭერს ამ ფუნქციას, Windows-ის მხარეს ფრაგმენტი მოკლეა. ეს არის მთელი ცვლილება იმ მხარეს:
[wsl2]
dnsTunneling=trueეს ფრაგმენტი Windows-ის მომხმარებლის პროფილში ხვდება და ვრცელდება ვირტუალურ მანქანაზე და არა ერთ დისტრიბუციაზე. გვირაბიზაცია ასევე მოითხოვს, რომ დისტრიბუციას არ გამოურთავს გადამწყვეტის გენერაცია, ამიტომ დისტრიბუციის მხარეს ფაილმა ეს ქცევა უნდა დატოვოს. შეცვალეთ ერთი მეორის გარეშე და რეჟიმი ჩუმად არაფერს აკეთებს, და ეს არის ყველაზე გავრცელებული გზა, რომლითაც ეს შესწორება გატეხილად ხდება ცნობილი. შეამოწმეთ ორივე ფაილი ერთსა და იმავე სესიაში, რადგან კვირების დაშორებით გაკეთებული ორი შესწორება ორი ისეთი შესწორებაა, რომელთა მიკუთვნებაც ვერავინ შეძლებს.
გადატვირთეთ, შემდეგ ჰკითხეთ ორივე მხრიდან
ეს პარამეტრები გარემოს გაშვებისას იკითხება, ამიტომ გაშვებული დისტრიბუციის შიგნით ახალი shell მათ ხელახლა არ ჩატვირთავს. გამორთეთ გარემო shell-ის გადატვირთვის ნაცვლად, და ჯერ შეინახეთ ნებისმიერი მიმდინარე სამუშაო, რადგან ყოველი დისტრიბუცია მასთან ერთად ჩერდება. მხოლოდ ეს გამოტოვება ხსნის ცვლილების უშედეგობის შესახებ ანგარიშების უმეტესობას.
შემდეგ დასვით იგივე კითხვა ორივე მხრიდან. გამოსავალი ასევე აჩვენებს, რომელ გადამწყვეტთან დარჩა დისტრიბუცია რეალურად:
wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'პირველი ბრძანება ამთავრებს გარემოს, მეორე აჩვენებს, რომელ გადამწყვეტს იყენებს დისტრიბუცია ახლა, ხოლო ბოლო ორი იგივე კითხვას უსვამს თითოეულ მხარეს. შეადარეთ პასუხები და არა პარამეტრის მდგომარეობა. მოთხოვნა, რომელიც ჯერ კიდევ ვარდება სუფთა გადატვირთვის შემდეგ ორივე ფაილის სისწორის პირობებში, მიუთითებს კორპორატიულ გადამწყვეტის პოლიტიკაზე, და ამ საუბარს სხვა მფლობელი ჰყავს.