WSL2 კორპორატიულ VPN-ს არ მემკვიდრეობს და სწორედ ეს არის ხარვეზი
WSL2 საკუთარ ვირტუალურ ქსელში მუშაობს და ჰოსტის VPN სტეკს არასოდეს მემკვიდრეობს. resolv.conf-ის რედაქტირებამდე სახელების ჩავარდნები ბილიკის ჩავარდნებისგან გამოყავით.
შიდა ვიკი Edge-ში იტვირთება, ხოლო git clone დისტრიბუციის შიგნით დროის ამოწურვას იწვევს. ამ ერთ დაკვირვებას ჩვეულებრივ კითხულობენ როგორც «VPN WSL2-ს ბლოკავს», და შემდეგი საათი /etc/resolv.conf-ის რედაქტირებას ხმარდება. უფრო სასარგებლო კითხვაა, რომ WSL2-ს ჰოსტის ქსელური ბილიკი არასოდეს ჰქონია: ის დამხმარე VM-ში მუშაობს საკუთარი ადაპტერით, საკუთარი მარშრუტებით და resolver-ის ფაილით, რომელსაც Windows მისთვის ქმნის. ყველაფერი შემდგომი დამოკიდებულია იმაზე, თუ ამ სამიდან რომელი გაკლიათ სინამდვილეში.
VM-ს აქვს საკუთარი სტეკი, მეტრიკები და resolver
ნაგულისხმევ NAT რეჟიმში დისტრიბუცია ვირტუალური კომუტატორის უკან ზის და ინტერნეტს ჰოსტის გავლით აღწევს, მაგრამ ჰოსტის ადაპტერებს ვერ ხედავს. ip addr აჩვენებს ერთ ინტერფეისს კერძო მისამართით, ip route აჩვენებს ნაგულისხმევ მარშრუტს ამ კომუტატორის გავლით, ხოლო /etc/resolv.conf გენერირებული ფაილია, რომელიც Windows-ის მიერ არჩეულ stub resolver-ზე მიუთითებს. ამათგან არაფერი იცვლება იმით, რომ Windows-ის მხარეს VPN კლიენტი ამუშავდა.
ამიტომ «ბრაუზერი მუშაობს» იმდენად ცოტას ამტკიცებს. ბრაუზერი იყენებს ჰოსტის სტეკს, გვირაბს და ჰოსტის resolver პოლიტიკას. თქვენი ჭურვი სხვა სტეკს იყენებს, რომელიც შემთხვევით ფიზიკურ ქსელურ ბარათს იზიარებს. ისინი კარგ შემთხვევაში ემთხვევიან და განსხვავდებიან ზუსტად მაშინ, როცა VPN ფილტრს აყენებს, DNS სიას გადაწერს ან ვირტუალური კომუტატორის ქვექსელისთვის მარშრუტს ამატებს.
ორი ტესტი წყვეტს, რომელ სამყაროში ხართ, და ისინი დისტრიბუციის შიგნით უნდა გაშვდეს:
getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.confსახელების ჩავარდნა, როცა ლიტერალური მისამართი პასუხობს, resolver-ის პრობლემაა. სახელებისა და მისამართების ერთად ჩავარდნა ბილიკის პრობლემაა, და resolver-ის არც ერთი რედაქტირება მას არ შეეხება. შემდეგ მოდის Windows-ის მხრიდან მტკიცებულებები: Get-NetAdapter | Get-DnsClientServerAddress და route print -4 აჩვენებენ, დაიკავა თუ არა გვირაბმა ის ქვექსელი, სადაც თქვენი VM ცხოვრობს.
პირველი მითი: კორპორატიული DNS სერვერები აგვარებენ
resolver-ის ფაილის რედაქტირება კლასიკური რჩევაა და დაახლოებით ნახევარ შემთხვევაში სწორია. როცა სწორია, კონკრეტული მიზეზით სწორია: გენერირებული ფაილი resolver-ზე მიუთითებს, რომელმაც მხოლოდ საჯარო სახელები იცის, ამიტომ intranet.example.internal-ზე მოთხოვნა არარსებულად ბრუნდება, თუმცა ბილიკი რიგშია.
VPN-ის სერვერების მიმაგრება ნიშნავს Windows-ისთვის ფაილის ხელახლა გენერირების შეჩერებას, რადგან ხელით დაწერილი ნებისმიერი ფაილი შემდეგ ჩართვაზე შეიცვლება:
[network]
generateResolvConf = falseშეინახეთ ეს როგორც /etc/wsl.conf, გაუშვით wsl --shutdown Windows-იდან, შემდეგ გაუშვით დისტრიბუცია და დაწერეთ /etc/resolv.conf გვირაბის სერვერებით პირველად და საჯარო resolver მხოლოდ სარეზერვოდ. ეს ხანგრძლივი ცვლილებაა მოვლის ხარჯით: ფაილი ჰოსტს აღარ მიჰყვება, ამიტომ როცა კორპორატიული DNS მისამართები იცვლება, დისტრიბუცია ძველებს კვლავ ეკითხება. ვინმემ ამ ფაილის მფლობელი უნდა იყოს.
არაფერს აკეთებს მაშინაც, როცა ჩავარდნა უფრო ფართოა. თუ curl-დან 1.1.1.1-მდე დროის ამოწურვა ხდება, გვირაბის კლიენტი ვირტუალურ კომუტატორს ფილტრავს ან VM-ის ქვექსელს გვირაბში ამისამართებს, და სწორი resolver მხოლოდ იმ სახელებს გაძლევთ, რომლებზეც ჯერ კიდევ შეუძლებელია მისვლა.
მეორე მითი: მეტრიკის ცვლილება ნარჩუნდება
როცა სახელები იხსნება, მაგრამ ტრაფიკი ფიზიკური ადაპტერიდან გადის, ბერკეტი ინტერფეისის მეტრიკებია. VPN ადაპტერს მაღალი ღირებულება მიეცით, WSL კომუტატორს კი დაბალი:
Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1შემდეგ გაიხსენეთ, რომ კლიენტის ბევრ ვერსიაში გვირაბის ადაპტერი ყოველ დაკავშირებაზე ხელახლა იქმნება და მეტრიკა ნაგულისხმევს უბრუნდება. ერთჯერადი ბრძანება სწორებაა, რომელიც ჩუმად იწურება, ჩვეულებრივ შაბათ-კვირას, და ბილეთი «წინა კვირას მუშაობდა»-თი ბრუნდება. VPN მოვლენით გაშვებული დაგეგმილი ამოცანა, ან მომხმარებლის მიერ დაკავშირების შემდეგ გაშვებული სკრიპტი, ამ სწორების პატიოსანი ვერსიაა.
იგივე ვადა ეხება ჰოსტის მარშრუტებს, რომლებიც ერთი ჯიუტი პრეფიქსისთვის დაემატა. ისინი ღირებულია დიაგნოსტიკისთვის, რადგან გეუბნებიან, პრობლემა ერთი დანიშნულებაა თუ მთელი ბილიკი, მაგრამ არქიტექტურა არ არიან.
მესამე მითი: ერთი სწორება ფარავს ყველა Windows ვერსიას
| Approach | What it actually does |
|---|---|
| Resolver pin | Fixes private names only; no effect on path failures |
| Sidecar distribution | Forwards traffic over a socket to a helper VM, so the switch's filter no longer matters |
| Mirrored networking | Gives the distribution the host's interface set; also enables DNS tunnelling |
wsl-vpnkit sidecar-ის ნიმუშია: პატარა დისტრიბუცია ფლობს ჰოსტის მხრიდან ბილიკს და ვირტუალური სოკეტით სხვა დისტრიბუციებისთვის გადასცემს, ამიტომ აპლიკაციების ტრაფიკი ფილტრირებულ კომუტატორზე დამოკიდებულებას წყვეტს. საჭიროა სტანდარტული ბილიკი მუშაობდეს, რაც ნიშნავს networkingMode და dnsTunneling გადაფარვების %UserProfile%\.wslconfig-იდან მოცილებას, generateResolvConf = true-ის აღდგენას თითოეულ მუშა დისტრიბუციაში და სერვისის გაშვებას შესვლისას.
სარკული რეჟიმი Windows 11 22H2-სა და უფრო ახლებში ჩაშენებული ალტერნატივაა, და ეს ერთი პარამეტრი პლუს გამორთვაა:
[wsl2]
networkingMode=mirroredდისტრიბუციის შიგნით ip addr შემდეგ ჩამოთვლის ჰოსტის ადაპტერებს, გვირაბი შეიძლება მათ შორის გამოჩნდეს, და DNS გვირაბიზაცია მოთხოვნებს Windows-ის resolver-ის გავლით გადასცემს მაშინაც, როცა კლიენტი DNS სიას გადაწერს. ეს უნივერსალური არ არის: ზოგიერთი ფილტრის დრაივერი ჯერ კიდევ ყრის სარკულ ბილიკს, და Hyper-V ფაირვოლის წესებს შეიძლება ცხადი ნებართვა დასჭირდეს. Microsoft-ის WSL ქსელის გიდი ის გვერდია, რომელიც უფრო ახლისთვის დაწერილი რეცეპტის გამოყენებამდე თქვენს ვერსიას უნდა შეადაროთ.
ყოველი ცვლილების შემდეგ სამი რამ შეამოწმეთ
აირჩიეთ ერთი მექანიზმი თითო მანქანაზე და ჩაწერეთ, რადგან ორივე ცუდად ერწყმის. სარკული რეჟიმის ზემოთ sidecar გადაცემას აორმაგებს, და .wslconfig-ში მოძველებული sidecar ჩანაწერის მქონე სარკული ჰოსტი, როგორც წესი, განახლების შემდეგ ვარდება და არა მანამდე.
რაც არ უნდა აირჩიოთ, მიღების ტესტი დისტრიბუციის შიგნით იგივე სამი მოთხოვნაა: შიდა სახელი, საჯარო სახელი და ნედლი მისამართი. შემდეგ გაიმეორეთ ისინი გვირაბის გათიშვისა და ხელახლა დაკავშირების შემდეგ, და wsl --shutdown-ის შემდეგ. მხოლოდ შიდა სახელის ჩავარდნა resolver პოლიტიკაა; შიდა და საჯარო სახელების ერთად ჩავარდნა მუშა მისამართის პირობებში კვლავ resolver პოლიტიკაა; ყველაფრის ჩავარდნა ბილიკია.
თუ ერთი შიდა ჰოსტი ვარდება, სანამ დანარჩენი მუშაობს, შეწყვიტეთ resolver-ზე ყურება და მოძებნეთ დაკარგული მარშრუტი ამ პრეფიქსისთვის. თუ ყველაფერი მუშაობს შემდეგ ხელახლა დაკავშირებამდე, იპოვეთ სწორება, რომელიც გაშვების დროის მდგომარეობაზეა დამოკიდებული, და ის ავტომატურად უნდა გამოყენდეს ხელახლა ან შეიცვალოს ზემოთ მოცემული ორი მექანიზმიდან ერთით.