WSL2: คู่มือขั้นสูงเกี่ยวกับการกำหนดค่าเครือข่าย โหมด NAT และโหมดมิเรอร์

อินฟอร์เมเทค ดิจิตอล » Recursos » WSL2: คู่มือขั้นสูงเกี่ยวกับการกำหนดค่าเครือข่าย โหมด NAT และโหมดมิเรอร์

WSL2 ได้เปลี่ยนแปลงวิธีการที่ Linux ผสานรวมกับ Windows ไปอย่างสิ้นเชิงโดยเฉพาะอย่างยิ่งในทุกสิ่งที่เกี่ยวข้องกับเครือข่าย: ตอนนี้เรามีเครื่องเสมือนขนาดเล็กที่มีสแต็กเครือข่ายของตัวเอง ที่อยู่ IP ของตัวเอง และกฎการเข้าถึงแยกต่างหาก ซึ่งเปิดโอกาสมากมายสำหรับการพัฒนา การทดสอบ คอนเทนเนอร์ และสภาพแวดล้อมการโฮสต์ด้วยตนเอง แต่ก็ทำให้เกิดความกังวลเมื่อบริการไม่สามารถเข้าถึงได้ ดังเช่นที่เกิดขึ้นกับ WSL1

ทำความเข้าใจเกี่ยวกับการกำหนดค่าเครือข่าย WSL2, โหมด NAT และโหมดมิเรอร์, การใช้งานไฟล์ .wslconfig และ wsl.conf และวิธีการทำงานร่วมกับไฟร์วอลล์, VPN, Docker หรือเครื่องมือต่างๆ เช่น Tailscale นี่เป็นกุญแจสำคัญในการหลีกเลี่ยงปัญหาปวดหัว มาดูกันทีละขั้นตอนว่าการตั้งค่าทั้งหมดนี้ทำงานอย่างไร วิธีการเปิดเผยบริการให้กับ Windows และ LAN คำสั่งที่ใช้ในการรับ IP ที่ถูกต้อง และตัวเลือกการกำหนดค่าขั้นสูงที่คุณมีเพื่อปรับแต่งสภาพแวดล้อมของคุณให้มีเสถียรภาพ และที่สำคัญที่สุดคือปลอดภัย

เครือข่ายทำงานอย่างไรใน WSL2

WSL2 ไม่ได้ใช้สแต็กเครือข่ายโฮสต์ร่วมกันเหมือนใน WSL1 อีกต่อไปแล้วแต่ระบบจะรันแต่ละเวอร์ชันของ Linux ภายในเครื่องเสมือนขนาดเล็กที่จัดการโดย Hyper-V โดยเครื่องเสมือนนั้นจะมีอะแดปเตอร์เสมือนของตัวเอง (โดยปกติ) eth0) และที่อยู่ IP ส่วนตัวที่กำหนดโดยสวิตช์เสมือนภายใน

ในโหมดเริ่มต้น WSL2 ใช้สถาปัตยกรรมแบบ NAT (การแปลงที่อยู่เครือข่าย) Windows ทำหน้าที่เป็นเราเตอร์/โฮสต์ และระบบปฏิบัติการ Linux จะอยู่ในซับเน็ตส่วนตัว ซึ่งโดยทั่วไปจะอยู่ในช่วงที่กำหนด 172.16.0.0/12ซับเน็ตนี้อาจเปลี่ยนแปลงได้หลังจากการรีบูตหรือการรีสตาร์ท WSL ซึ่งเป็นสิ่งที่ทำให้หลายคนหัวเสียมาแล้วขณะตั้งค่ากฎไฟร์วอลล์แบบคงที่

ในทางปฏิบัติแล้ว นั่นหมายความว่าที่อยู่ IP ของระบบปฏิบัติการ WSL2 ของคุณนั้นไม่เสถียรและไม่สามารถเข้าถึงได้โดยตรงจากเครือข่าย LAN เช่นเดียวกับ WSL1: โดยค่าเริ่มต้น การเชื่อมต่อระหว่าง Windows และ WSL2 จะเกิดขึ้นผ่านกฎการเปลี่ยนเส้นทางและ NAT เท่านั้น และการเข้าถึงเครือข่ายภายในต้องใช้ขั้นตอนเพิ่มเติมหรือการใช้โหมดมิเรอร์

นอกเหนือจากโครงสร้างพื้นฐานนี้แล้ว Windows 11 22H2 และเวอร์ชันที่ใหม่กว่ายังเพิ่มความสามารถด้านเครือข่ายใหม่ๆ อีกด้วย (โหมดมิเรอร์, dnsTunneling, autoProxy, ไฟร์วอลล์ Hyper-V เป็นต้น) ซึ่งควบคุมได้จากไฟล์ส่วนกลาง .wslconfigในขณะที่ตัวเลือกบางอย่างใน Linux นั้นได้รับการจัดการด้วย /etc/wsl.conf.

ระบุที่อยู่ IP ใน WSL2

การทำงานกับ WSL2 เกี่ยวข้องกับการแยกแยะความแตกต่างระหว่างสถานการณ์ IP สองแบบอย่างชัดเจน: เมื่อคุณต้องการที่อยู่ IP ของระบบปฏิบัติการ Linux และเมื่อคุณต้องการที่อยู่ IP ของเครื่อง Windows ที่มองเห็นได้จาก Linux แต่ละอย่างจะใช้คำสั่งที่แตกต่างกัน

สถานการณ์ที่ 1: จากระบบปฏิบัติการ Windows คุณต้องการทราบที่อยู่ IP ของระบบปฏิบัติการ WSL2 เพื่อให้แอปพลิเคชันบนโฮสต์ (เช่น ไคลเอนต์ เบราว์เซอร์ หรือเครื่องมือทดสอบ) สามารถเชื่อมต่อกับบริการที่ทำงานอยู่ภายใน Linux ได้ โดยคุณสามารถเรียกใช้คำสั่งต่อไปนี้ใน Windows (โดยใช้ CMD หรือ PowerShell):

wsl.exe --distribution <DistroName> hostname -i

หากคุณต้องการใช้ระบบปฏิบัติการเวอร์ชันเริ่มต้น คุณสามารถละเว้นพารามิเตอร์ distribution ได้ และเพียงแค่โทร wsl.exe hostname -iในเบื้องหลัง คำสั่งนี้จะทำงานในระบบลินุกซ์ hostname --ip-addresses และส่งคืนที่อยู่ IP ของอินสแตนซ์ ผลลัพธ์ทั่วไปอาจมีลักษณะดังนี้:

172.30.98.229

สถานการณ์ที่ 2: จากระบบปฏิบัติการ Linux คุณจำเป็นต้องทราบที่อยู่ IP ของเครื่องโฮสต์ Windowsตัวอย่างเช่น ในการเชื่อมต่อแอปพลิเคชัน WSL2 กับเซิร์ฟเวอร์ที่ทำงานบน Windows โดยตรง (Node.js, SQL Server, Caddy เป็นต้น) ภายในเชลล์ Linux คุณสามารถใช้คำสั่งต่อไปนี้:

ip route show | grep -i default | awk '{ print $3 }'

ผลลัพธ์ที่ได้จะเป็นเกตเวย์เริ่มต้นของเครื่องเสมือน WSL2ซึ่งตรงกับที่อยู่ IP ของโฮสต์ Windows ที่มองเห็นได้จาก Linux ประมาณนี้:

172.30.96.1

ค่าดังกล่าว (ตัวอย่างเช่น 172.30.96.1) คือที่อยู่ซึ่งไคลเอนต์ Linux ของคุณควรชี้ไป เมื่อคุณต้องการเข้าถึงบริการที่ทำงานอยู่บนโฮสต์ Windows ในขณะที่อยู่ในโหมด NAT แบบคลาสสิก

โหมด NAT: ลักษณะการทำงานเริ่มต้นของเครือข่าย WSL2

โดยปกติแล้ว WSL2 จะทำงานในโหมด NAT ซึ่งสำหรับสภาพแวดล้อมการพัฒนาแบบง่ายๆ หลายๆ กรณี ก็เพียงพอแล้วสิ่งสำคัญคือต้องเข้าใจว่าอะไรได้ผล "ด้วยตัวมันเอง" และอะไรไม่ได้ผล เพื่อจะได้ไม่เสียเวลาไปกับการไล่ตามสิ่งที่ไม่มีอยู่จริง

การเข้าถึงบริการ Linux จาก Windows โดยใช้ localhostหากคุณใช้งานแอปพลิเคชันเครือข่าย (เช่น เซิร์ฟเวอร์ Node.js, เซิร์ฟเวอร์ Flask, เซิร์ฟเวอร์ SQL บน Linux) บนระบบปฏิบัติการ WSL2 คุณสามารถเข้าถึงได้จาก Windows โดยใช้ localhost:puertoWindows จะส่งต่อการเชื่อมต่อขาเข้าโดยอัตโนมัติไปยังที่อยู่ IP ภายในของเครื่องเสมือน WSL2

การเข้าถึงบริการที่ทำงานบน Windows จาก Linuxตรงนี้แหละที่ทุกอย่างเปลี่ยนไป ในการเข้าถึงแอปพลิเคชันเครือข่ายบนโฮสต์ (เช่น เซิร์ฟเวอร์ Node.js, SQL Server หรือ Caddy บน Windows) จาก WSL2 คุณต้องใช้ที่อยู่ IP ของโฮสต์ตามที่เห็นจาก Linux ซึ่งได้มาจากการใช้คำสั่ง route เริ่มต้น:

ip route show | grep -i default | awk '{ print $3 }'

ด้วยที่อยู่ IP นั้น คุณสามารถเชื่อมต่อจาก Linux ไปยังบริการใดๆ บนโฮสต์ได้ตัวอย่างเช่น http://172.30.96.1:3000 หากเซิร์ฟเวอร์ Windows ของคุณรับฟังการเชื่อมต่อบนพอร์ต 3000 บนทุกอินเทอร์เฟซ

เมื่อคุณเชื่อมต่อโดยใช้ที่อยู่ IP ระยะไกล (ไม่ใช่ localhost) แอปพลิเคชันจะมองเห็นการเชื่อมต่อเหล่านั้นเป็นการเชื่อมต่อ LANหมายความว่าต้องมีการตั้งค่าเซิร์ฟเวอร์จำนวนมากให้พร้อมรับฟังการเชื่อมต่อ 0.0.0.0 แทนที่ 127.0.0.1ตัวอย่างเช่น คุณสามารถใช้ Flask เพื่อเรียกใช้คำสั่งต่อไปนี้:

app.run(host='0.0.0.0')

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

การเข้าถึง WSL2 จากเครือข่ายท้องถิ่น (LAN) โดยใช้ NAT

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

ใน WSL2 เครื่องเสมือน (VM) จะมีที่อยู่ IP ส่วนตัวของตนเอง และจะไม่ถูกประกาศบนเครือข่าย LAN โดยอัตโนมัติเพื่อให้ได้ผลลัพธ์ที่คล้ายคลึงกับพฤติกรรมเดิมในโหมด NAT คุณต้องสร้างพร็อกซีพอร์ตใน Windows เช่นเดียวกับการสร้างพร็อกซีพอร์ตในเครื่องเสมือน Hyper-V ทั่วไป

ระบบปฏิบัติการ Windows มีเครื่องมือคลาสสิกสำหรับสิ่งนี้อยู่แล้ว: netsh interface portproxyคำสั่งทั่วไปในการเปลี่ยนเส้นทางพอร์ตของโฮสต์ไปยัง IP/พอร์ตของ WSL2 จะมีดังนี้:

netsh interface portproxy add v4tov4 listenport=<puertoHost> listenaddress=0.0.0.0 connectport=<puertoWSL> connectaddress=(wsl hostname -I)

ในทางปฏิบัติ คุณจะต้องแทนที่ตัวบ่งชี้ด้วยค่าเฉพาะเจาะจงตัวอย่างเช่น:

netsh interface portproxy add v4tov4 listenport=4000 listenaddress=0.0.0.0 connectport=4000 connectaddress=192.168.101.100

ที่นี่ listenaddress=0.0.0.0 นี่แสดงว่า Windows จะรับฟังการเชื่อมต่อจากทุกที่อยู่ IPv4 ของโฮสต์และจะส่งต่อสิ่งที่เข้ามาทางพอร์ต 4000 ไปยัง 192.168.101.100:4000ซึ่งจะเป็นที่อยู่ IP ของ WSL2 ที่ได้รับจากการดำเนินการดังนี้:

• wsl hostname -I มันจะแสดงที่อยู่ IP ของระบบปฏิบัติการ Linux ภายในเครื่องเสมือน WSL2 ให้คุณทราบ
• cat /etc/resolv.conf วิธีนี้จะแสดงที่อยู่ IP ของโฮสต์ Windows Vista จาก WSL2

ด้วยเทคนิคนี้ คุณสามารถทำให้บริการที่ทำงานบน WSL2 สามารถเข้าถึงได้จากคอมพิวเตอร์เครื่องใดก็ได้ในเครือข่าย LANโดยมีเงื่อนไขว่าไฟร์วอลล์ของ Windows อนุญาต และคุณเข้าใจอย่างชัดเจนว่าคุณกำลังเปิดเผยบริการของเครื่องเสมือน (VM) ไม่ใช่โฮสต์โดยตรง

IPv6 และคุณสมบัติเครือข่ายสมัยใหม่

WSL2 ยังสามารถทำงานร่วมกับ IPv6 ได้ ซึ่งมีความสำคัญอย่างยิ่งในสภาพแวดล้อมสมัยใหม่ เครือข่าย VPN และเครือข่ายองค์กรในการจัดการที่อยู่ คำสั่งพื้นฐานใน Linux นั้นเทียบเท่ากับคำสั่งของ IPv4:

• wsl hostname -i จาก Windows เพื่อดูที่อยู่ IP ของการแจกจ่าย WSL2
• ip route show | grep -i default | awk '{ print $3 }' จากระบบ Linux เพื่อรับที่อยู่ IP ของโฮสต์ Windows

จุดเด่นที่เห็นได้ชัดที่สุดของการพัฒนาคุณภาพในการรองรับ IPv6 และ VPN คือโหมดเครือข่ายแบบมิเรอร์ซึ่งมีให้ใช้งานใน Windows 11 22H2 และเวอร์ชันที่ใหม่กว่า ซึ่งเราจะมาดูรายละเอียดกันในภายหลัง

โหมดเครือข่ายแบบมิเรอร์: การจำลองอินเทอร์เฟซของ Windows ใน Linux

บนคอมพิวเตอร์ที่ใช้ Windows 11 เวอร์ชัน 22H2 หรือสูงกว่า คุณสามารถเปิดใช้งานโหมดเครือข่ายแบบ "มิเรอร์" ได้ ใน WSL2 รูปแบบการทำงานเปลี่ยนไปอย่างสิ้นเชิง: แทนที่จะใช้ NAT แบบคลาสสิก Linux จะ "มองเห็น" อินเทอร์เฟซเครือข่ายของ Windows ที่สะท้อนกลับมา

หากต้องการเปิดใช้งาน คุณต้องแก้ไขไฟล์ .wslconfig ของผู้ใช้ของคุณซึ่งอยู่ใน %UserProfile%\.wslconfigจาก PowerShell ที่มีสิทธิ์ผู้ดูแลระบบ คุณสามารถเปิดไฟล์ได้ด้วยคำสั่ง:

notepad $env:USERPROFILE\.wslconfig

ภายใน ให้เพิ่ม (หรือแก้ไข) ส่วน [wsl2] เพื่อเปิดใช้งานโหมดมิเรอร์:

[wsl2]
networkingMode=mirrored

เมื่อบันทึกไฟล์แล้ว คุณต้องรีสตาร์ท WSL2 เพื่อให้การเปลี่ยนแปลงมีผลตัวอย่างเช่น:

wsl --shutdown

เมื่อคุณรีสตาร์ท WSL จะใช้สถาปัตยกรรมเครือข่ายแบบมิเรอร์ใหม่ซึ่งนำมาซึ่งข้อดีที่มีประสิทธิภาพหลายประการ:

• รองรับ IPv6 โดยตรงและปรับปรุงการทำงานร่วมกับเครือข่ายองค์กรและ VPN ให้ดียิ่งขึ้น
• ความสามารถในการเชื่อมต่อกับบริการ Windows จาก Linux โดยใช้ 127.0.0.1 โดยตรง (ถึงแม้จะไม่ได้รับอนุญาตก็ตาม) ::1 (เช่น การใช้ IPv6 loopback สำหรับกรณีนี้)
• ปรับปรุงการรองรับมัลติแคสต์ภายในระบบการทำงานร่วมกันระหว่าง Windows และ Linux
• เข้าถึง WSL ได้โดยตรงจาก LAN โดยไม่ต้องใช้ netsh portproxyโดยใช้ที่อยู่ IP ของเครื่อง Windows เอง

การเปิดใช้งานโหมดนี้จะช่วยแก้ไขปัญหา NAT ทั่วไปของ WSL2 ได้หลายประการ และเป็นตัวเลือกที่แนะนำในสภาพแวดล้อมการพัฒนาและการโฮสต์ด้วยตนเองสมัยใหม่ส่วนใหญ่ ที่คุณสามารถใช้ Windows 11 เวอร์ชันล่าสุดได้

การทำ DNS tunneling และการใช้พร็อกซีใน WSL2

ใน Windows 11 เวอร์ชัน 22H2 และเวอร์ชันที่ใหม่กว่า การแก้ไขชื่อจาก WSL2 ได้รับการปรับปรุงครั้งสำคัญเช่นกันหัวใจสำคัญอยู่ที่ฟังก์ชันการทำงานสองอย่างที่กำหนดไว้ใน .wslconfig: dnsTunneling y autoProxy.

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

สำหรับส่วนของตน autoProxy=true บังคับให้ WSL ใช้การตั้งค่าพร็อกซี HTTP ของ Windowsหากเครื่องโฮสต์อยู่หลังพร็อกซีขององค์กรหรือพร็อกซีด้านความปลอดภัย WSL2 จะรับค่าพร็อกซีนั้นโดยอัตโนมัติโดยที่คุณไม่ต้องยุ่งยากกับการตั้งค่าตัวแปรสภาพแวดล้อมด้วยตนเอง

ตัวอย่างเช่น คุณอาจมีสิ่งแบบนี้อยู่ในของคุณ .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

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

ไฟร์วอลล์ Hyper-V และการเปิดเผยบริการที่ปลอดภัย

ในสภาพแวดล้อมสมัยใหม่ เครือข่าย WSL2 ยังต้องผ่านไฟร์วอลล์เฉพาะอีกด้วยตั้งแต่ WSL เวอร์ชัน 2.0.9 บน Windows 11 22H2 เป็นต้นไป คุณสมบัติไฟร์วอลล์ Hyper-V จะถูกเปิดใช้งานโดยค่าเริ่มต้น ซึ่งจะเพิ่มชั้นการกรองเพิ่มเติมสำหรับทราฟฟิกของ VM (รวมถึงทราฟฟิกของ WSL2)

หากคุณกำลังทำงานในโหมดมิเรอร์และต้องการเปิดเผยบริการ WSL2 ไปยังเครือข่าย LAN อย่างถาวร (ตัวอย่างเช่น API, แดชบอร์ด หรือบริการโฮสติ้งด้วยตนเอง) คุณต้องตรวจสอบให้แน่ใจว่ากฎไฟร์วอลล์อนุญาตให้ใช้งานได้

แนวทางที่เหมาะสมจาก PowerShell ด้วยสิทธิ์ผู้ดูแลระบบคือการสร้างกฎ Hyper-V สำหรับเครือข่ายส่วนตัว:

New-NetFirewallHyperVRule -DisplayName "WSLPrivateInboundRule" -Profiles Private -Direction Inbound -Action Allow -VMCreatorId ((Get-NetFirewallHyperVVMCreator).VMCreatorId)

หากคุณต้องการปิดใช้งานการป้องกัน Hyper-V เฉพาะนั้นด้วยเหตุผลใดก็ตาม (วิธีที่ไม่แนะนำ) คุณอาจใช้:

Set-NetFirewallHyperVVMSetting -Name ((Get-NetFirewallHyperVVMCreator).VMCreatorId) -Enabled False

หลักการคือควรเปิดใช้งานไฟร์วอลล์ไว้ตลอดเวลาเท่าที่จะเป็นไปได้จำกัดกฎเกณฑ์เฉพาะเครือข่ายส่วนตัวและเฉพาะพอร์ตที่คุณต้องการจริงๆ เท่านั้น และสงวนการปิดใช้งานจำนวนมากไว้เป็นทางเลือกสุดท้ายเสมอ โดยคำนึงถึงการปรับปรุงการกำหนดค่าให้มีความปลอดภัยมากขึ้นอีกครั้งเมื่อทุกอย่างทำงานได้อย่างราบรื่น

สถาปัตยกรรมเครือข่าย WSL2, X11 และช่วง IP 172.16.0.0/12

ตัวอย่างคลาสสิกที่เผยให้เห็นรายละเอียดของเครือข่าย WSL2 คือการใช้งานแอปพลิเคชันแบบกราฟิกผ่าน X11ตัวอย่างเช่น การเปิดใช้งาน Xming บน Windows และส่งแอปพลิเคชัน Linux ผ่าน DISPLAY

เมื่ออัปเกรดจาก WSL1 เป็น WSL2 ผู้ใช้หลายคนพบว่าโปรแกรม X หยุดทำงาน เนื่องจากเครือข่ายดังกล่าวจะไม่ใช่เครือข่าย "ร่วมใช้" อีกต่อไป แต่จะกลายเป็นเครือข่าย NAT เสมือนที่มีช่วง IP ต่างๆ เช่น 172.16.0.0/12ซึ่งอาจเปลี่ยนแปลงได้หลังจากรีสตาร์ท Windows หรือ WSL ทุกครั้ง

เพื่อให้ X กลับมาใช้งานได้อีกครั้งกับ Xming จาก WSL2 วิธีการทั่วไปคือการหาที่อยู่ IP ของ Windows ที่ Linux มองเห็น ใช้:

ENS

DISPLAY=$(grep nameserver /etc/resolv.conf | cut -d' ' -f2):0

ในขณะเดียวกัน จำเป็นต้องปรับไฟร์วอลล์ของ Windows เพื่ออนุญาตการรับส่งข้อมูล X11 จากซับเน็ต NAT นั้นวิธีการทั่วไปคือการแก้ไขกฎ Xming โดยการเพิ่มช่วง 172.16.0.0/12 ใน TCP+UDP 6000

หลายคนจึงปิดใช้งานการตรวจสอบสิทธิ์ Xming ด้วยตัวเลือกดังกล่าว -acวิธีนี้เปรียบเสมือน "การเปิดประตู" ให้กับไคลเอ็นต์ X ใดๆ ที่เข้ามาจากเครือข่ายนั้น มันใช้งานได้ แต่จากมุมมองด้านความปลอดภัยแล้วค่อนข้างน่าสงสัย ดังนั้นจึงควรพิจารณาโซลูชันที่จำกัดกว่า หรือใช้ WSLg (แอปพลิเคชัน GUI แบบบูรณาการ) ใน Windows 11 แทน

wsl.conf และ .wslconfig: การกำหนดค่า WSL2 ขั้นสูง

WSL มีไฟล์การกำหนดค่าหลักสองไฟล์ที่ควบคุมทั้งพฤติกรรมของเครื่องเสมือน (VM) และของแต่ละระบบปฏิบัติการ: /etc/wsl.conf (ตามการแจกจ่าย) และ %UserProfile%\.wslconfig (ใช้ได้กับทุกดิสทริบิวชัน WSL2)

wsl.conf อาศัยอยู่ภายในระบบปฏิบัติการ Linux ใน /etc/wsl.confใช้สำหรับกำหนดค่าตัวเลือกภายในเครื่องสำหรับดิสโทรนั้นๆ เช่น การเมานต์อัตโนมัติ การสร้างไฟล์ hosts y resolv.confความสามารถในการทำงานร่วมกับ Windows, ผู้ใช้เริ่มต้น, systemd และอื่นๆ

.wslconfig ไฟล์นี้ถูกบันทึกไว้ภายนอกระบบ Linux ในโปรไฟล์ผู้ใช้ของ Windows (C:\Users\<Usuario>\.wslconfigและควบคุมพารามิเตอร์ทั่วโลกของเครื่องเสมือน (VM) ที่ใช้ขับเคลื่อน WSL2 ได้แก่ หน่วยความจำ ซีพียู เคอร์เนล โหมดเครือข่าย ไฟร์วอลล์ DNS ขนาดดิสก์เสมือน การสนับสนุน GUI เป็นต้น

รายละเอียดที่น่าสนใจอย่างหนึ่งคือ "กฎ 8 วินาที" เมื่อทำการเปลี่ยนการตั้งค่าเมื่อคุณแก้ไขไฟล์ใดๆ เหล่านี้ คุณต้องตรวจสอบให้แน่ใจว่า WSL VM ปิดตัวลงอย่างสมบูรณ์แล้ว แม้ว่าคุณจะปิดหน้าต่างของระบบปฏิบัติการแล้วก็ตาม มันอาจยังคงอยู่ในหน่วยความจำอีกสองสามวินาที

หากต้องการบังคับให้ระบบย่อยเริ่มต้นใหม่ คุณสามารถใช้คำสั่งต่อไปนี้:

• wsl --list --running เพื่อตรวจสอบว่ามีดิสโทรใดบ้างที่ยังใช้งานอยู่
• wsl --shutdown เพื่อปิดการแจกจ่ายทั้งหมดพร้อมกัน
• wsl --terminate <distroName> เพื่อหยุดดิสทริบิวชันเฉพาะตัวหนึ่ง

การเปลี่ยนแปลงการตั้งค่าจะมีผลจริงก็ต่อเมื่อปิดและเริ่มต้น WSL ใหม่เท่านั้นสิ่งที่หลายคนมองข้ามและคิดว่าการปรับเปลี่ยนของพวกเขานั้น "ไม่ได้ผล"

ตัวเลือกหลักของไฟล์ wsl.conf แยกตามส่วน

ไฟล์ wsl.conf มันได้รับแรงบันดาลใจจากรูปแบบไฟล์ .ini แบบคลาสสิก ที่มีส่วนต่างๆ และคีย์ส่วนประกอบหลักได้แก่ [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] คุณสามารถควบคุมวิธีการเชื่อมต่อไดรฟ์ของ Windows ภายใน Linux ได้ (โดยทั่วไปต่ำ) /mnt):

• enabled (บูลีน, ค่าเริ่มต้นคือ true)ถ้าเป็นจริง ไดรฟ์ C:/, D:/ ฯลฯ จะถูกเมานต์โดยอัตโนมัติ /mnt/c, /mnt/d...
• mountFsTab (บูล)ถ้าเป็นความจริง ก็จะถูกประมวลผล /etc/fstab เมื่อเริ่มต้นใช้งานระบบปฏิบัติการ
• root (โซ่): ไดเร็กทอรีหลักที่จะใช้ในการติดตั้งไดรฟ์ ตัวอย่างเช่น /windir/ ที่จะมี /windir/c.
• options (รายการที่คั่นด้วยเครื่องหมายจุลภาค)พารามิเตอร์เฉพาะของ DrvF เช่น metadata, uid, gid, umask, fmask, dmask o case.

DrvFs คือระบบไฟล์ที่เชื่อมต่อระหว่าง Windows และ Linuxออกแบบมาเพื่อเข้าถึง NTFS จาก WSL พร้อมการควบคุมสิทธิ์ เมตาเดตา และการคำนึงถึงตัวพิมพ์ใหญ่-เล็ก

ในส่วน [network] คุณสามารถปรับการสร้างไฟล์เครือข่ายอัตโนมัติได้:

• generateHostsหากเป็นจริง WSL จะสร้างโดยอัตโนมัติ /etc/hosts.
• generateResolvConfถ้าเป็นจริง WSL จะสร้าง /etc/resolv.conf โดยใช้ DNS รุ่นเก่า
• hostname: ชื่อโฮสต์ที่ระบบปฏิบัติการจะใช้

ส่วน [interop] การควบคุมการทำงานร่วมกันกับ Windows:

• enabled: เปิดใช้งานหรือปิดใช้งานความสามารถในการเรียกใช้กระบวนการของ Windows จาก WSL
• appendWindowsPath: ตัดสินใจว่าจะเพิ่มเส้นทางของ Windows เข้าไปหรือไม่ $PATH ลินุกซ์

En [user] คุณสามารถระบุผู้ใช้ที่จะใช้เป็นค่าเริ่มต้นเมื่อเริ่มใช้งานระบบปฏิบัติการได้:

• default: ชื่อผู้ใช้ที่จะเริ่มต้นทำงานโดยค่าเริ่มต้นใน WSL

ส่วน [boot] มีประโยชน์อย่างยิ่งใน Windows 11 และ Server 2022 เพื่อเรียกใช้บริการต่างๆ โดยอัตโนมัติ เช่น Docker ภายใน WSL:

• command: สตริงคำสั่งที่จะเรียกใช้เมื่อเริ่มต้น WSL ตัวอย่างเช่น service docker start.
• protectBinfmt: ป้องกันการสร้างหน่วย systemd เมื่อเปิดใช้งาน systemd

นอกจากนี้ยังมีส่วนต่างๆ เช่น [gpu] (เปิดใช้งานการเข้าถึง GPU ของ Windows จาก Linux) และ [time] เพื่อซิงโครไนซ์เขตเวลาให้ตรงกับ Windowsวิธีนี้จะช่วยป้องกันปัญหาที่อาจเกิดขึ้นเมื่อคุณเปลี่ยนเวลาเป็นเวลาฤดูร้อนหรือเดินทาง

.wslconfig: การควบคุมเครื่องเสมือน WSL2

ในขณะที่ไฟล์ wsl.conf ปรับแต่งพฤติกรรมของแต่ละดิสทริบิวชัน ไฟล์ .wslconfig ช่วยให้คุณปรับแต่ง VM ที่ใช้ร่วมกันโดยดิสทริบิวชัน WSL2 ทั้งหมดได้ไฟล์นี้จะถูกนำมาพิจารณาเฉพาะในระบบปฏิบัติการที่ทำงานบน WSL2 เท่านั้น ไม่ใช่ WSL1

ภายใน .wslconfig ส่วนหลักคือ [wsl2]โดยที่คุณกำหนดพารามิเตอร์หลัก:

• kernel y kernelModules: เส้นทางสัมบูรณ์จาก Windows ไปยังเคอร์เนล Linux ที่กำหนดเองและโมดูลต่างๆ ของเคอร์เนลนั้น
• memory: ขีดจำกัดหน่วยความจำ VM (ค่าเริ่มต้น 50% ของ RAM โฮสต์) ตัวอย่างเช่น 4GB.
• processors: จำนวนโปรเซสเซอร์เชิงตรรกะที่จัดสรรให้กับเครื่องเสมือน (VM)
• localhostForwarding: อนุญาตให้เข้าถึงพอร์ตที่เปิดอยู่บน WSL2 จาก Windows โดยใช้ localhost.
• swap y swapFileขนาดและตำแหน่งของไฟล์สวอปสำหรับเครื่องเสมือน (VM)
• guiApplications: เปิดใช้งานหรือปิดใช้งานการสนับสนุนแอปพลิเคชัน GUI (WSLg)
• dnsProxyเมื่อคุณใช้งานในโหมด NAT ระบบจะตัดสินใจว่าเซิร์ฟเวอร์ DNS ของ Linux จะเป็นอินสแตนซ์ NAT ของโฮสต์หรือสำเนาของเซิร์ฟเวอร์ DNS ของ Windows
• networkingModeที่นี่คุณสามารถเลือกได้ระหว่าง none, nat, bridged (ล้าสมัย), mirrored o virtioproxy.
• firewall, dnsTunneling y autoProxy: ตัวเลือกที่เราได้หารือกันเพื่อบูรณาการเครือข่าย WSL เข้ากับนโยบายของ Windows ให้ดียิ่งขึ้น
• defaultVhdSize: ขนาดสูงสุดของไฟล์ VHD ที่ใช้จัดเก็บระบบไฟล์ของดิสทริบิวชัน (ค่าเริ่มต้น 1 TB)

นอกจากนี้ยังมีส่วนอีกด้วย [experimental] โดยที่ฟีเจอร์ต่างๆ จะถูกเปิดใช้งานในการทดสอบ เป็น:

• autoMemoryReclaim: การตั้งค่าการกู้คืนหน่วยความจำอัตโนมัติ (ปิดใช้งาน, ค่อยเป็นค่อยไป, dropCache)
• sparseVhd: การสร้างดิสก์เสมือนแบบเบาบางเพื่อประหยัดพื้นที่
• bestEffortDnsParsing y dnsTunnelingIpAddress: การปรับแต่งอย่างละเอียดสำหรับการทำ DNS tunneling
• ignoredPorts: พอร์ตที่แอปพลิเคชัน Linux สามารถใช้งานได้แม้ว่าจะถูกใช้งานอยู่บน Windows ในโหมดมิเรอร์
• hostAddressLoopback: อนุญาตให้โฮสต์และคอนเทนเนอร์เชื่อมต่อกันโดยใช้ที่อยู่ IP ภายในของโฮสต์ในโหมดมิเรอร์

การตั้งค่า .wslconfig อย่างถูกต้องจะทำให้ VM ของคุณใช้ทรัพยากรมากเกินไป หรือกลายเป็นสภาพแวดล้อมที่เหมาะสมซึ่งทำงานได้ดีกับระบบ Windows และเครือข่ายของคุณโดยเฉพาะอย่างยิ่งหากคุณทำงานกับปริมาณงานหนัก คอนเทนเนอร์ หรือระบบปฏิบัติการหลายตัวพร้อมกัน

WSL2, Docker และระบบเครือข่ายสำหรับการโฮสต์ด้วยตนเองโดยใช้ Tailscale

ตัวอย่างที่เป็นรูปธรรมมากคือการใช้ WSL2 บนเซิร์ฟเวอร์ Windows (แม้แต่ Windows Server 2025) เป็นแพลตฟอร์มสำหรับการโฮสต์ด้วยตนเองโดยการรวม Ubuntu บน WSL2, Docker Engine (โดยไม่ใช้ Docker Desktop), Tailscale และพร็อกซีแบบย้อนกลับ เช่น Caddy เพื่อเปิดเผยบริการต่างๆ เช่น n8n หรือ Supabase

แนวคิดคือการสร้างสภาพแวดล้อม Docker ที่เสถียรภายใน WSL2 โดยหลีกเลี่ยงปัญหาของ Docker Desktop บนเซิร์ฟเวอร์เมื่อติดตั้ง Docker Engine โดยตรงบน Ubuntu (WSL2) เครือข่ายคอนเทนเนอร์จะอาศัยเครือข่าย WSL2 ซึ่งจะขึ้นอยู่กับโหมด NAT หรือโหมดมิเรอร์ที่กำหนดไว้ในไฟล์ .wslconfig

เมื่อติดตั้ง Tailscale บน WSL2 แล้ว คุณสามารถเผยแพร่บริการของคุณบนเครือข่าย VPN แบบ Mesh ได้ โดยไม่ต้องเปิดพอร์ตบนเราเตอร์ และใช้ Caddy เป็นรีเวิร์สพร็อกซีเพื่อรวมศูนย์ใบรับรอง TLS เส้นทาง และการกระจายโหลดแบบเบาๆ ระหว่างคอนเทนเนอร์

เพื่อให้เครือข่ายมีความสะอาด เสถียร และปลอดภัย จึงควรดำเนินการดังต่อไปนี้:

• เลือกโหมดเครือข่ายที่สอดคล้องกันเพียงโหมดเดียว (NAT หรือแบบมิเรอร์) และบันทึกรายละเอียดไว้
• หลีกเลี่ยงปัญหาพอร์ตขัดแย้งระหว่าง Windows และ WSL2, อาศัย ignoredPorts หากคุณใช้แบบมิเรอร์
• ควบคุมการเปิดรับบริการผ่านทาง Tailscale หรือ Caddy เท่านั้นแทนที่จะเปิดพอร์ต "โดยค่าเริ่มต้น" ในไฟร์วอลล์
• ทำการเริ่มต้นใช้งาน Docker, Tailscale และ Caddy โดยอัตโนมัติ [boot] ในไฟล์ wsl.conf เพื่อให้มีสภาพแวดล้อมที่ใกล้เคียงกับการผลิตมากขึ้น

ด้วยสถาปัตยกรรมนี้ WSL2 จึงไม่ใช่แค่เครื่องมือสำหรับการพัฒนาอีกต่อไป แต่สามารถกลายเป็นแพลตฟอร์มการโฮสต์ด้วยตนเองที่ค่อนข้างจริงจังได้โดยมีเงื่อนไขว่าคุณต้องยอมรับข้อจำกัดของมัน (การจำลองเสมือนผ่าน Hyper-V, เลเยอร์เครือข่ายเพิ่มเติม ฯลฯ) และกำหนดค่าอย่างระมัดระวัง

แนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้งานเครือข่าย WSL2 สำหรับการพัฒนาและการทดสอบ

นอกเหนือจากการปรับแต่งอย่างละเอียดแล้ว ยังมีแนวทางอีกหลายประการที่จะช่วยให้คุณทำงานกับเครือข่าย WSL2 ได้อย่างสะดวกสบาย โดยไม่ต้องคอยต่อสู้กับ IP, พอร์ต และไฟร์วอลล์อยู่ตลอดเวลา

สำหรับบริการพัฒนาซอฟต์แวร์ ให้ใช้พอร์ตที่มีหมายเลขสูง (มากกว่า 1024) และหลีกเลี่ยงพอร์ตที่มีสิทธิ์พิเศษหรือใช้งานหนัก เพื่อลดความขัดแย้งและขจัดความจำเป็นในการขอสิทธิ์เพิ่มเติม

ตรวจสอบให้แน่ใจว่าโค้ดและข้อมูลอยู่ในระบบไฟล์ของลินุกซ์ (เฉิงตู ~/ หรือเส้นทางภายใน) แทนที่จะทำงานโดยตรงกับ /mnt/cเนื่องจากการเข้าถึง NTFS จาก WSL นั้นช้ากว่าและอาจส่งผลเสียต่อบริการที่ใช้การรับส่งข้อมูลจำนวนมาก

ตั้งค่าเครือข่ายและกฎการเปลี่ยนเส้นทางโดยอัตโนมัติด้วยสคริปต์ ใน PowerShell และ Bash: ตัวอย่างเช่น สคริปต์ที่กำหนดค่า WSL2 เมื่อเริ่มต้นทำงาน netsh portproxy (หากคุณยังคงใช้ NAT ต่อไป) หรือตรวจสอบกฎไฟร์วอลล์เมื่อใช้การทำมิเรอร์

หลีกเลี่ยงการพึ่งพาการเปลี่ยนที่อยู่ IP สร้างโดยสวิตช์เสมือนภายใน เมื่อใดก็ตามที่เป็นไปได้ ให้ทำงานร่วมกับ localhostชื่อโฮสต์หรือรายการใน /etc/hosts เพื่อบริการของคุณ เพื่อป้องกันไม่ให้การเปลี่ยนแปลง IP ส่งผลกระทบต่อโครงสร้างพื้นฐานการทดสอบของคุณครึ่งหนึ่ง

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

เมื่อตั้งค่าอย่างถูกต้อง WSL2 จะมอบเครือข่ายที่แยกเป็นอิสระแต่มีความยืดหยุ่น เหมาะอย่างยิ่งสำหรับการพัฒนาขั้นสูง การทดสอบ API การทำงานกับคอนเทนเนอร์ และการจำลองสภาพแวดล้อมแบบกระจายหัวใจสำคัญคือการเชี่ยวชาญโหมดเครือข่าย (NAT เทียบกับแบบมิเรอร์), ไฟล์ wsl.conf และ .wslconfig, และการทำงานร่วมกันกับไฟร์วอลล์และเครื่องมือต่างๆ ในระบบของคุณ (Docker, Tailscale, รีเวิร์สพร็อกซี) เพื่อให้ Windows และ Linux สามารถทำงานบนเครื่องเดียวกันได้โดยไม่ทับซ้อนพอร์ตหรือลดทอนความปลอดภัย