ทำไม WSL จึงสูญเสียชื่อโฮสต์งานเมื่อ VPN เชื่อมต่อ?
ชื่อเดียวกันใช้งานได้ใน Windows แต่ล้มเหลวภายใน WSL ทันทีที่อุโมงค์ขึ้น ตรวจสอบโหมด DNS ของแพลตฟอร์มและการแทนที่เก่าก่อนเพิ่มรีโซลเวอร์
Windows แก้ชื่อโฮสต์ภายในได้โดยไม่มีปัญหาใด ๆ และชื่อเดียวกันก็ล้มเหลวภายใน WSL ในวินาทีที่อุโมงค์ขึ้น การซ่อมแซมตามปกติคือการเขียนรีโซลเวอร์สาธารณะลงในดิสทริบิวชัน ซึ่งทำให้การท่องเว็บปกติกลับมาและทำให้ชื่อโฮสต์งานแก้ไม่ได้เลย นั่นแลกความล้มเหลวหนึ่งกับอีกอย่างหนึ่ง และซ่อนชั้นที่เสียจริง ๆ ไว้ ก่อนจะเพิ่มหรือลบบรรทัดรีโซลเวอร์ใด ๆ ให้ระบุว่าชั้นใดในสามชั้นที่ล้มเหลว
ตัดความเป็นไปได้ของความล้มเหลวในการกำหนดเส้นทางก่อน
ถามชื่อที่ผ่านการรับรองเต็มรูปแบบเดียวกันทั้งสองฝั่ง ไม่ใช่สองชื่อที่ดูคล้ายกัน ความสำเร็จใน Windows และความล้มเหลวใน WSL สำหรับสตริงเดียวกันคือลายเซ็นของเส้นทางการแก้ชื่อสองเส้นทาง และมีน้อยสิ่งอื่นที่สร้างรูปแบบนั้นได้สะอาดเช่นนี้ ถ้า WSL เข้าถึงบริการที่อยู่เลขที่รู้จักไม่ได้ด้วย แสดงว่ามีปัญหาการกำหนดเส้นทางหรือการกรองด้วย ในกรณีนั้นงานด้าน DNS จะไม่เปิดเผยมัน และบ่ายนั้นจะเสียไปกับชั้นที่ผิด
สามอาการครอบคลุมกรณีเหล่านี้ส่วนใหญ่ และแต่ละอย่างชี้ไปที่อื่น อ่านแถวที่ตรงกันก่อนเปิดไฟล์กำหนดค่า:
| Symptom inside WSL | Likely layer | Where to look |
|---|---|---|
| Private name fails while public browsing works | Resolver path | Tunneling mode and the Windows build |
| A name that worked yesterday fails today | Stale override | Generated resolver file, immutable flag, shell profile |
| The name resolves but the service does not | Routing or filtering | The resolved address and the path to it |
แถวกลางคือแถวที่ผู้คนอ่านผิด เพราะการเปลี่ยนแปลงที่ทำให้มันเสียถูกทำเมื่อหลายสัปดาห์ก่อนและตอนนั้นดูเหมือนสำเร็จ แถวที่สามคือแถวที่ผู้คนวินิจฉัยผิด เพราะชื่อที่แก้ได้ให้ความรู้สึกเป็นหลักฐานว่าเครือข่ายแข็งแรง ทั้งสองแถวส่งคุณไปยังส่วนอื่นด้านล่าง
การทำอุโมงค์ DNS มีพื้นขั้นต่ำของเวอร์ชัน
Microsoft จัดทำเอกสารโหมดเครือข่ายของ WSL ที่ทำอุโมงค์คำขอ DNS ไปยังรีโซลเวอร์ของ Windows ผ่านช่องทางเสมือนจริง บนบิลด์ Windows 11 ที่รองรับ โหมดนี้เปิดใช้เป็นค่าเริ่มต้น จึงเป็นเหตุให้เครื่องสองเครื่องบนเครือข่ายองค์กรเดียวกันทำงานต่างกัน ตัวแปรคือหมายเลขบิลด์ ไม่ใช่นโยบายองค์กร
คู่มือเครือข่ายของ WSL อธิบายโหมดนั้นและเวอร์ชันที่รองรับ คุณลักษณะนี้สำคัญเพราะนโยบาย DNS ขององค์กรมักอาศัยอยู่ในรีโซลเวอร์ของ Windows และดิสทริบิวชันที่สืบทอดเส้นทางของ Windows ก็สืบทอดนโยบายไปด้วย ดิสทริบิวชันที่ถามรีโซลเวอร์สาธารณะไม่มีเส้นทางไปยังชื่อส่วนตัวเลย ไม่ว่าการกำหนดค่าของมันเองจะดูเรียบร้อยเพียงใด กลไกนั้นอธิบายอาการทั้งหมด และอธิบายว่าทำไมวิธีเลี่ยงด้วยรีโซลเวอร์สาธารณะจึงล้มเหลว
อ่านบิลด์ก่อนแก้ไขอะไรทั้งสิ้น การตั้งค่าที่คัดลอกจาก installation ที่ใหม่กว่าไม่ใช่หลักฐานว่า installation ที่เก่ากว่าจะนำไปใช้ บันทึกหมายเลขบิลด์ไว้ข้างการเปลี่ยนแปลง เพราะความต่างระหว่างสองเครื่องเกือบทุกครั้งคือเวอร์ชัน ไม่ใช่นโยบาย
การแทนที่เก่ามีอายุยืนกว่าปัญหาที่มันแก้
สูตรเก่า ปิดไฟล์รีโซลเวอร์ที่สร้างขึ้น กำหนดเนมเซิร์ฟเวอร์แบบตายตัว หรือล็อกไฟล์ด้วยแอตทริบิวต์ที่ไม่เปลี่ยนแปลง การเปลี่ยนแปลงเหล่านั้นยังคงอยู่ อีกนานหลังจากปัญหาการเชื่อมต่อที่ทำให้เกิดมันหายไป และมักเป็นเหตุให้การตั้งค่าใหม่ดูเหมือนไม่ได้ทำอะไรเลย มันยังอยู่รอดข้ามการติดตั้งดิสทริบิวชันใหม่ในรูปของโปรไฟล์ shell ที่เขียนไฟล์ใหม่ทุกครั้งที่เข้าสู่ระบบ ตัวสุดท้ายหาได้ยากที่สุด เพราะมองไม่เห็นจากไฟล์ที่ทุกคนตรวจสอบ
มองหาไฟล์รีโซลเวอร์ที่เขียนด้วยมือ แอตทริบิวต์ไม่เปลี่ยนแปลงบนไฟล์นั้น และสคริปต์เริ่มระบบที่เขียนมันใหม่ ตรวจสอบแฟล็กไม่เปลี่ยนแปลงก่อนแก้ไข เพราะการเขียนลงไฟล์ที่ถูกล็อกจะล้มเหลวในลักษณะที่อ่านได้เหมือนปัญหาเรื่องสิทธิ์ จากนั้นตรวจสอบโปรไฟล์ shell เพราะสคริปต์ที่นั่นคืนเนื้อหาเดิมภายในไม่กี่วินาทีหลังการแก้ไขของคุณ
การลบการแทนที่มีผลที่ตามมา จึงบันทึกว่าคุณลบอะไรและเพราะอะไร ดิสทริบิวชันที่ต้องการรีโซลเวอร์แบบคงที่เพื่อจุดประสงค์อื่นจริง ๆ จะพังเมื่อไฟล์ที่สร้างขึ้นกลับมา
สองไฟล์ สองบทบาทที่ต่างกัน
ไฟล์กำหนดค่าสองไฟล์อาศัยอยู่คนละที่และควบคุมคนละเรื่อง และการสับสนระหว่างกันทำให้การแก้ไขถูกนำไปใช้กับชั้นที่ผิด ไฟล์ฝั่ง Windows กำหนดคุณสมบัติของเครื่องเสมือน ส่วนไฟล์ฝั่งดิสทริบิวชันกำหนดว่าดิสทริบิวชันนั้นสร้างการกำหนดค่ารีโซลเวอร์ของตัวเองอย่างไร ไม่มีตัวใดแทนที่อีกตัว จึงต้องสอดคล้องกันทั้งคู่
สำหรับ installation ที่รองรับคุณลักษณะนี้ ส่วนฝั่ง Windows สั้น นั่นคือการเปลี่ยนแปลงทั้งหมดในฝั่งนั้น:
[wsl2]
dnsTunneling=trueส่วนนั้นอยู่ในโปรไฟล์ผู้ใช้ของ Windows และใช้กับเครื่องเสมือนไม่ใช่ดิสทริบิวชันเดียว การทำอุโมงค์ยังต้องให้ดิสทริบิวชันไม่ได้ปิดการสร้างรีโซลเวอร์ ดังนั้นไฟล์ฝั่งดิสทริบิวชันต้องปล่อยพฤติกรรมนั้นไว้ เปลี่ยนอย่างหนึ่งโดยไม่อีกอย่างหนึ่งแล้วโหมดจะไม่ทำอะไรเลยอย่างเงียบ ๆ และนี่คือวิธีที่พบบ่อยที่สุดที่การซ่อมแซมนี้ถูกรายงานว่าเสีย ตรวจสอบทั้งสองไฟล์ในเซสชันเดียวกัน เพราะการแก้ไขสองครั้งที่ทำห่างกันหลายสัปดาห์คือการแก้ไขสองครั้งที่ไม่มีใครอ้างสิทธิ์ได้
รีสตาร์ตแล้วถามจากทั้งสองฝั่ง
การตั้งค่าเหล่านี้ถูกอ่านเมื่อสภาพแวดล้อมเริ่มทำงาน ดังนั้น shell ใหม่ภายในดิสทริบิวชันที่กำลังทำงานอยู่จะไม่โหลดใหม่ ปิดสภาพแวดล้อมแทนการรีสตาร์ต shell และบันทึกงานที่กำลังทำอยู่ก่อน เพราะทุกดิสทริบิวชันหยุดไปพร้อมกับมัน การละเว้นข้อนี้เพียงอย่างเดียวอธิบายรายงานส่วนใหญ่ว่าการเปลี่ยนแปลงไม่มีผล
จากนั้นถามคำถามเดียวกันจากทั้งสองฝั่ง เอาต์พุตยังแสดงด้วยว่าดิสทริบิวชันลงเอยกับรีโซลเวอร์ตัวใดจริง ๆ:
wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'คำสั่งแรกจบสภาพแวดล้อม คำสั่งที่สองแสดงว่ารีโซลเวอร์ใดที่ดิสทริบิวชันใช้อยู่ตอนนี้ และสองคำสั่งสุดท้ายถามคำถามเดียวกันกับแต่ละฝั่ง เปรียบเทียบคำตอบไม่ใช่สถานะของการตั้งค่า คำถามที่ยังล้มเหลวหลังการรีสตาร์ตสะอาดด้วยไฟล์ทั้งสองถูกต้องชี้ไปที่นโยบายรีโซลเวอร์ขององค์กร และบทสนทนานั้นมีเจ้าของอีกคน