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 เป็นไฟล์ที่สร้างขึ้นซึ่งชี้ไปยัง stub resolver ที่ Windows เลือก ไม่มีสิ่งใดเปลี่ยนแปลงเพราะไคลเอนต์ VPN เริ่มทำงานฝั่ง Windows
นั่นคือเหตุผลที่ «เบราว์เซอร์ใช้งานได้» พิสูจน์ได้น้อยมาก เบราว์เซอร์ใช้สแตกของโฮสต์ อุโมงค์ และนโยบาย 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 ส่งต่อการค้นหาผ่าน resolver ของ Windows แม้ไคลเอนต์จะเขียนรายการ DNS ใหม่ มันไม่ใช่สากล: ไดรเวอร์ฟิลเตอร์บางตัวยังคงทิ้งเส้นทางกระจก และกฎไฟร์วอลล์ของ Hyper-V อาจต้องอนุญาตอย่างชัดเจน คู่มือเครือข่าย WSL ของ Microsoft คือหน้าที่ควรเทียบกับบิลด์ของคุณก่อนใช้สูตรที่เขียนสำหรับรุ่นใหม่กว่า
ทดสอบสามอย่างหลังทุกการเปลี่ยนแปลง
เลือกกลไกหนึ่งต่อเครื่องและจดไว้ เพราะทั้งสองรวมกันได้ไม่ดี sidecar บนโหมดกระจกเพิ่มการส่งต่อเป็นสองเท่า และโฮสต์กระจกที่มีรายการ sidecar ล้าสมัยใน .wslconfig มักล้มเหลวหลังการอัปเกรด ไม่ใช่ก่อนหน้า
ไม่ว่าคุณเลือกอะไร การทดสอบการยอมรับคือคำขอสามอย่างเดิมภายในดิสทริบิวชัน: ชื่อภายใน ชื่อสาธารณะ และที่อยู่ดิบ จากนั้นทำซ้ำหลังตัดและเชื่อมต่ออุโมงค์ใหม่ และหลัง wsl --shutdown หากเฉพาะชื่อภายในล้มเหลวคือ นโยบาย resolver; หากชื่อภายในและชื่อสาธารณะล้มเหลวพร้อมกันในขณะที่ที่อยู่ทำงาน ก็ยังเป็นนโยบาย resolver; หากทุกอย่างล้มเหลวคือเส้นทาง
หากโฮสต์ภายในตัวเดียวล้มเหลวในขณะที่ที่เหลือทำงาน ให้หยุดดู resolver และหาเส้นทางที่ขาดหายสำหรับคำนำหน้านั้น หากทุกอย่างทำงานจนถึงการเชื่อมต่อใหม่ครั้งถัดไป คุณพบการซ่อมที่ขึ้นกับสถานะขณะรัน และต้องนำไปใช้ซ้ำโดยอัตโนมัติหรือแทนที่ด้วยกลไกใดกลไกหนึ่งข้างต้น