VPN เชื่อมต่อแล้ว WSL2 สูญเสีย DNS? สองสาเหตุ

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

ทำไมดิสทริบิวชันจึงเก็บ resolver ของตัวเอง

ไคลเอนต์ DNS ของ Windows ไม่ถูกใช้ภายในดิสทริบิวชัน WSL2 สร้างไฟล์ resolver ของตัวเองตอนเริ่มระบบ ชี้ไปยังที่อยู่ stub ที่ Windows ประกาศบนสวิตช์เสมือนสำหรับเครื่องเสมือนช่วย

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

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

เก็บหลักฐานทั้งสองด้านก่อน

บันทึกสิ่งที่ดิสทริบิวชันเห็น แล้วจึงบันทึกสิ่งที่ Windows เห็น ก่อนจะเปลี่ยนฝ่ายใดฝ่ายหนึ่ง มุมมองทั้งสองรวมกันคือสิ่งที่แยกแยะรูปแบบความล้มเหลว

ภายในดิสทริบิวชัน พิมพ์ไฟล์ resolver ตารางเส้นทาง และการค้นหาภายในหนึ่งครั้งและการค้นหาสาธารณะหนึ่งครั้ง:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

บน Windows ให้แสดงเซิร์ฟเวอร์ DNS ตามอะแดปเตอร์และตาราง IPv4 พร้อมการวัด VPN ไคลเอนต์มักติดตั้งเส้นทางสำหรับซับเน็ต WSL2 และการวัดของเส้นทางนั้นตัดสินว่าทราฟฟิกนั้นออกทางอุโมงค์หรืออยู่ภายในเครื่อง

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

การวัดเส้นทางหรือไฟล์เก่า

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

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

การทดสอบที่แยกแยะได้ใช้เพียงหนึ่งบรรทัด ถ้าที่อยู่เชิงตัวเลขเช่น resolver สาธารณะยังตอบ ping ขณะที่ชื่อล้มเหลว แสดงว่าเส้นทางยังสมบูรณ์และปัญหาเป็นที่ DNS นี่คือกรณีที่การเปลี่ยน resolver มีเหตุผล และกรณีที่ไม่มีเหตุผลก็ชัดเจนขึ้นเช่นกัน ถ้าการทดสอบเชิงตัวเลขล้มเหลวด้วย เครื่องเสมือนช่วยได้สูญเสียเส้นทางแล้ว และไม่มีไฟล์ resolver ใดแก้ไขได้

สำหรับกรณีเส้นทาง ให้เอาการวัดอัตโนมัติออกจากอะแดปเตอร์ของอุโมงค์และกำหนดตัวเลขที่สูงกว่าเส้นทางลิงก์ของ WSL2:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

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

รับไฟล์นั้นมาเองอย่างตั้งใจ

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

สร้าง /etc/wsl.conf ภายในดิสทริบิวชันพร้อมส่วนเครือข่ายที่ปิดการสร้าง แล้วเขียนไฟล์ resolver ด้วยตัวเอง เริ่มจากเซิร์ฟเวอร์องค์กรและตามด้วยเซิร์ฟเวอร์สาธารณะสำรอง:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

ลำดับสำคัญ resolver สาธารณะตอบชื่อภายในไม่ได้ และตัวสำรองมีไว้สำหรับการค้นหาทางอินเทอร์เน็ตเท่านั้น เมื่อไฟล์เป็นของคุณแล้ว จะไม่มีสิ่งใดสร้างมันใหม่ ดังนั้น resolver องค์กรที่ย้ายที่จะกลายเป็นการหยุดชะงักที่คุณต้องสังเกตเอง

ตรวจชื่อก่อน แล้วจึงตรวจแพ็กเกจ

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

ถ้าคุณทำให้การเขียนใหม่เป็นอัตโนมัติ ให้ทำให้ได้ผลลัพธ์เดิมทุกครั้ง: เมื่อไม่มีอุโมงค์ ให้เก็บไฟล์ที่มีอยู่แล้วไว้แทนการเขียนรายการเซิร์ฟเวอร์ว่างเปล่า

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

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