WSL2 เข้าไม่ถึงซับเน็ต VPN: อ่านเส้นทางของโฮสต์

จากภายในดิสโทร ping ไปยังเซิร์ฟเวอร์ภายในหมดเวลา ขณะที่ที่อยู่เดียวกันตอบกลับจาก Windows VPN เชื่อมต่ออยู่และเส้นทาง Windows ถูกต้อง ช่องว่างจึงเป็นขอบเขตของ WSL เดินเส้นทางจากคำสั่งที่ล้มเหลวกลับไปยังอินเทอร์เฟซของโฮสต์ วิธีแก้ไม่ใช่ CIDR คงที่ในไฟล์กำหนดค่า แต่เป็นการอ่านที่อยู่ปัจจุบันแล้วเพิ่มเข้าไปในที่ที่ดิสโทรใช้งานได้

ยืนยันว่าเส้นทางหยุดที่ไหน

รันการทดสอบเดียวกันทั้งสองฝั่ง: แปลงชื่อและเชื่อมต่อกับโฮสต์ภายในหนึ่งเครื่องจาก Windows แล้วทำซ้ำในดิสโทร ความสำเร็จใน Windows บวกกับการหมดเวลาในดิสโทรชี้ว่าความล้มเหลวอยู่ระหว่างทั้งสอง ไม่ใช่ในไคลเอนต์ VPN หรือเซิร์ฟเวอร์ภายใน ทำก่อนเปลี่ยนเส้นทางใด ๆ เพื่อให้ผลลัพธ์ทั้งสองอธิบายปลายทางเดียวกัน

ภายในดิสโทร ip -4 addr แสดงอะแดปเตอร์เสมือนที่มีที่อยู่จากช่วง NAT ของ WSL และ ip route แสดงเส้นทางเริ่มต้นที่ชี้ไปยังเกตเวย์ WSL ไม่มีเส้นทางสำหรับพรีฟิกซ์องค์กร เพราะอะแดปเตอร์อุโมงค์ของโฮสต์ไม่มีคู่กันภายในดิสโทร เกตเวย์เริ่มต้นนำไปยัง NAT ของ WSL ไม่ใช่เครือข่ายองค์กร

การเพิ่มเส้นทางองค์กรโดยไม่เพิ่มที่อยู่ในเครื่องบนลิงก์ที่เข้าถึงได้ก่อนจะทำให้เกิดการหมดเวลาหรือข้อผิดพลาดเครือข่ายเข้าถึงไม่ได้ ที่อยู่คือส่วนที่ทำให้เส้นทางใช้งานได้ จึงควรอ่านที่อยู่ก่อนและถือว่าเส้นทางเป็นขั้นตอนที่สอง

เลือกเครือข่ายแบบมิเรอร์หรือเส้นทางด้วยสคริปต์

เครือข่ายแบบมิเรอร์มอบอินเทอร์เฟซของโฮสต์เองให้ดิสโทร อุโมงค์และเส้นทางจึงปรากฏโดยไม่ต้องคัดลอก คุณลักษณะนี้ขึ้นกับบิลด์ Windows ใหม่และ networkingMode=mirrored ใน .wslconfig และการเปิดใช้จะเปลี่ยนพฤติกรรมที่ไม่เกี่ยวข้อง เช่น การส่งต่อ 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 ไม่ใช่จากเชลล์แบบโต้ตอบ สคริปต์ที่อ่านที่อยู่ เพิ่มที่อยู่ เพิ่มเส้นทาง และบันทึกค่า จะเปลี่ยนการซ่อมแซมด้วยมือที่เกิดซ้ำให้ทำซ้ำได้ และบันทึกคือสิ่งแรกที่ควรอ่านเมื่อพรีฟิกซ์เปลี่ยน

ปักหมุดชื่อและพิสูจน์เส้นทาง

เคอร์เนลอาจเปลี่ยนชื่ออินเทอร์เฟซของดิสโทรระหว่าง eth1 กับ eth2 หลังสลับเครือข่าย และสคริปต์ที่เขียนตามชื่อจะแก้ไขอุปกรณ์ผิดตัว กฎ udev ที่ผูกกับ MAC ให้ป้ายที่มั่นคงแก่อินเทอร์เฟซ:

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 ตรวจสอบไฟร์วอลล์ของโฮสต์และการกรองของไคลเอนต์ VPN เองก่อนแก้ไขสคริปต์ เพราะการแก้เส้นทางอีกครั้งจะไม่แก้แพ็กเก็ตที่ไปถึงโฮสต์แล้ว