დისტრიბუტივის შიგნით დათვალიერება მუშაობს, და პირველი შიდა ჰოსტის სახელი ვარდება იმ მომენტში, როცა გვირაბი ამოდის. რეფლექსია დამატებითი საჯარო რეზოლვერის ჩასმა, რაც ინტერნეტს აბრუნებს და კორპორატიულ სახელს დღის ბოლომდე მიუწვდომელს ხდის. WSL 2-ში /etc/resolv.conf გენერირებული გამონატანია და არა კონფიგურაცია, და სწორედ ეს მექანიზმი ღირს გაგებად. გასწორება უკეთესი რეზოლვერი არ არის, არამედ ფაილის მფლობელობა.

ფაილი გენერირდება და არ კონფიგურირდება

WSL 2 ფაილს წერს გაშვებისას იმ Windows ადაპტერებიდან, რომლებსაც იმ მომენტში ხედავს, და ზემოთ ბეჭდავს კომენტარს, რომელიც ამას ამბობს. როცა VPN-ის კლიენტი შემდეგ ადაპტერს ამატებს ან გადაწერს, დისტრიბუტივი სულაც არ ქმნის ხელახლა რამეს, და ფაილი კვლავ აღწერს ქსელს, რომელიც აღარ არსებობს.

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

შეადარეთ Windows-ის ხედი Linux-ის ხედს

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

ls -l /etc/resolv.conf
cat /etc/resolv.conf
Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

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

გამორთეთ გენერაცია და დაწერეთ საკუთარი ფაილი

ერთი დოკუმენტირებული პარამეტრი უშლის WSL-ს ფაილის გადაწერას, და ის /etc/wsl.conf-შია. დაამატეთ ქსელის განყოფილება ამ ფაილს:

[network]
generateResolvConf = false

შემდეგ შეწყვიტეთ დისტრიბუტივი Windows-იდან wsl --shutdown-ით და ჩართეთ ხელახლა. თუ გზა სიმბოლური ბმულია და არა ჩვეულებრივი ფაილი, წაშალეთ ბმული სანამ საკუთარ შიგთავსს დაწერთ, რადგან ბმულით წერამ შეიძლება შემდეგ გაშვებაზე გენერირებული სამიზნე ხელახლა შექმნას. ამ მომენტიდან ფაილი თქვენია და არაფერი გადაწერს მას.

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

საძიებო დომენის გარეშე, არასრული ჰოსტის სახელი საჯარო ფესვით სრულდება და ბრუნდება როგორც ასეთი დომენი არ არსებობს. timeout ხელს უშლის მკვდარ პირველ სერვერს დაბლოკოს ყოველი ძებნა, attempts ზღუდავს რამდენ ცდას ხარჯავს ძებნა, და rotate ავრცელებს განმეორებით ცდებს ნაცვლად ყოველთვის ზემოდან დაწყებისა. ვაჭრობა ისაა, რომ ფაილი აღარ მიჰყვება VPN-ს, რომლის რეზოლვერის მისამართი სესიებს შორის იცვლება.

გაუმკლავდით მოძრავ რეზოლვერს, შემდეგ გადაამოწმეთ

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

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

სცადეთ სახელით და არა პაკეტით: getent hosts sensor-access0.corp.example გადის რეზოლვერის დასტაში, მაშინ როცა ping შეიძლება წარმატებული იყოს ქეშირებული ან პირდაპირი მისამართის მიმართ. შემდეგ გაიმეორეთ გათიშვისა და ხელახლა დაკავშირების შემდეგ, რადგან პარამეტრი, რომელიც ერთხელ მუშაობს და განახლებისას ხელახლა გენერირდება, არასოდეს გამოსწორებულა. შეინახეთ წინა შიგთავსი და ჩაინიშნეთ, რომელი კომპონენტი ფლობს გზას ამ მანქანაზე, რომ შემდეგი ცვლილება მტკიცებულებით დაიწყოს.

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