WSL2 ვერ აღწევს VPN ქვექსელს: წაიკითხეთ ჰოსტის მარშრუტი

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

დაადასტურეთ, სად ჩერდება გზა

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

დისტრიბუციის შიგნით ip -4 addr აჩვენებს ვირტუალურ ადაპტერს WSL NAT დიაპაზონის მისამართით, ხოლო ip route აჩვენებს ნაგულისხმევ მარშრუტს WSL-ის კარიბჭისკენ. კორპორატიული პრეფიქსისთვის მარშრუტი არ არსებობს, რადგან ჰოსტის გვირაბის ადაპტერს დისტრიბუციის შიგნით შესატყვისი არ აქვს. ნაგულისხმევი კარიბჭე მიდის WSL NAT-ისკენ და არა კორპორატიული ქსელისკენ.

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

აირჩიეთ სარკისებრი ქსელი ან სკრიპტული მარშრუტი

სარკისებრი ქსელი დისტრიბუციას აძლევს ჰოსტის საკუთარ ინტერფეისებს, ამიტომ გვირაბი და მისი მარშრუტები კოპირების გარეშე ჩნდება. ფუნქცია დამოკიდებულია ახალ Windows-ის ბილდზე და .wslconfig-ში networkingMode=mirrored-ზე, და მისი ჩართვა ცვლის დაუკავშირებელ ქცევას, მაგალითად localhost-ის გადამისამართებას. მოეკიდეთ როგორც პლატფორმის ცვლილებას და არა მარშრუტის რეგულირებას. თუ ბილდი მხარს უჭერს და გვერდითი ეფექტები მისაღებია, ეს უმოკლესი გზაა.

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

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

ამოიღეთ გვირაბის მიმდინარე დეტალები ჰოსტიდან

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

powershell.exe 'Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" } | Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, PrefixLength'

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

powershell.exe '(Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" }).InterfaceIndex'
powershell.exe '(Get-NetIPConfiguration -InterfaceIndex 27).IPv4DefaultGateway.NextHop'

გაატარეთ გამოსავალი tr -d '\r'-ში სანამ ცვლადს მიანიჭებთ. PowerShell სტრიქონებს ასრულებს carriage return-ით, და ამოღების გარეშე ბოლო ველი ატარებს დამალულ სიმბოლოს, რომელიც მარშრუტის ბრძანებას ამარცხებს დამაბნეველი ანალიზის შეცდომით.

გამოიყენეთ მისამართი და მარშრუტი დისტრიბუციის შიგნით

დააყენეთ გვირაბის მისამართი როგორც პრეფიქსიანი მისამართი დისტრიბუციის ინტერფეისზე, შემდეგ გადაამისამართეთ კორპორატიული ბლოკი ჰოსტის კარიბჭის გავლით:

sudo ip addr add 172.20.14.37/22 dev vpn
sudo ip route add 172.20.0.0/16 via 172.20.12.1 dev vpn

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

nmcli con show vpn
sudo nmcli con mod vpn ipv4.method auto
sudo nmcli con up vpn

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

დაამაგრეთ სახელი და დაამტკიცეთ გზა

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

SUBSYSTEM=="net", ACTION=="add", ATTRS{address}=="3c:52:82:0a:1b:7c", NAME="vpn"

შემდეგ შეამოწმეთ მისამართით, მარშრუტით და რეალური TCP კავშირით: ip -4 addr show dev vpn, ip route get 172.20.4.10 და კავშირი ცნობილ შიდა პორტთან. მარშრუტის ძიებამ უნდა დაასახელოს vpn მოწყობილობა და თქვენ მიერ დამატებული წყაროს მისამართი.

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