จะรัน VPN บนโฮสต์หรือใน VM? คู่มือตัดสินใจ
เจ้าของอุโมงค์เป็นผู้กำหนดว่าอะไรครอบอะไร เลือกตำแหน่งบนโฮสต์หรือในเกสต์ แล้วยืนยันด้วยการตรวจเส้นทาง DNS และทางออกภายในเกสต์
การสร้างอุโมงค์ภายในเกสต์และการสร้างบนโฮสต์ต่างก็เปลี่ยนที่อยู่ที่เบราว์เซอร์รายงาน และความคล้ายคลึงก็จบลงตรงนั้น อุโมงค์ที่เป็นของเกสต์เก็บกุญแจ เส้นทางเริ่มต้น และตัวแก้ชื่อไว้ในเคอร์เนลของเกสต์ ขณะที่โฮสต์ส่งต่อแพ็กเก็ตที่เข้ารหัสไปยังที่อยู่ปลายทางเดียว อุโมงค์ที่เป็นของโฮสต์คือภาพกลับด้าน: ไคลเอนต์ของโฮสต์ถือเซสชันและใช้เส้นทางกับนโยบาย ส่วนเกสต์ยมอะไรก็ตามที่ออกมา หากเลือกเจ้าของผิด ทุกอาการที่ตามมาจะพาคุณไปผิดเครื่อง สองคำสั่งตัดสินคำถามนี้ได้ในราวหนึ่งนาที และส่วนที่เหลือของคู่มือนี้คือสิ่งที่ต้องทำกับคำตอบ
ตัดสินเจ้าของก่อนแตะไคลเอนต์
กฎนี้เกี่ยวกับตำแหน่งที่ข้อความเข้ารหัสถูกสร้าง ไม่ใช่เครื่องที่แสดงไอคอน VPN หากเกสต์เป็นผู้สร้าง เกสต์ต้องมีเส้นทางที่ใช้งานได้ไปยังเซิร์ฟเวอร์ VPN และไม่ต้องอะไรจากโฮสต์อีก หากโฮสต์เป็นผู้สร้าง เส้นทางของเกสต์ผ่านโฮสต์ต้องอยู่รอดได้ไม่ว่านโยบายใดที่ไคลเอนต์ของโฮสต์บังคับใช้กับทราฟฟิกภายใน
โดยปกติคำถามสามข้อจะเลือกตำแหน่งให้คุณ ทราฟฟิกของเกสต์ต้องผ่านไคลเอนต์องค์กรบนโฮสต์หรือไม่ ถ้าใช่ อุโมงค์อยู่ในเกสต์ เกสต์หลายตัวต้องใช้ข้อมูลรับรองเดียวและที่อยู่ทางออกเดียวหรือไม่ ถ้าใช่ อุโมงค์อยู่บนโฮสต์ โดยตั้งค่าการส่งต่อไว้อย่างจงใจ ทราฟฟิกของเกสต์ต้องอยู่นอก VPN ของโฮสต์ทั้งหมดหรือไม่ ถ้าใช่ อุโมงค์ในเกสต์คือทางเดียวที่จะให้สิ่งนั้นได้โดยโครงสร้าง
เขียนคำตอบเป็นบรรทัดเดียวข้างชื่อ VM: guest-owned หรือ host-owned ในห้องแล็บหกเครื่อง บันทึกนั้นประหยัดเวลากว่าขั้นตอนใด ๆ ด้านล่าง เพราะมันกันไม่ให้คุณตามหาอุโมงค์ที่ไม่เคยอยู่ในเครื่องที่คุณล็อกอินเข้า
WSL1 กับ WSL2 เป็นกรณีที่ตรงข้ามกัน
WSL1 ไม่ใช่เครื่องเสมือน คำถามเรื่องตำแหน่งจึงมักละลายหายไป ไบนารี Linux ของมันทำงานบนสแต็กเครือข่ายของ Windows ผ่านชั้นแปลภาษา และไคลเอนต์ VPN ของ Linux ไม่มีอินเทอร์เฟซแยกให้กำหนดค่า สิ่งที่ได้ผลคืออุโมงค์ฝั่ง Windows โดยดิสทริบิวชันใช้ผลลัพธ์โดยไม่ถือครองอะไรเลย
WSL2 ตรงกันข้าม มันรันเคอร์เนลจริงในยูทิลิตี VM ขนาดเบาเบื้องหลังสวิตช์เสมือน Hyper-V และพื้นที่ที่อยู่ของมันถูกแปลงด้วย NAT ผ่านอะแดปเตอร์ฝั่งโฮสต์ ไคลเอนต์ Linux ในดิสทริบิวชันจึงทำงานเหมือนอยู่บนเครื่อง Linux จริง: มันสร้าง tun0 หรือ wg0 ตั้งเส้นทางของตัวเอง และทำงานได้ ความล้มเหลวอยู่ฝั่งโฮสต์ เมื่อไคลเอนต์ VPN ของ Windows เชื่อมต่อด้วยนโยบายที่บล็อกทราฟฟิกบนเครือข่ายภายใน มันถือว่าซับเน็ต WSL2 เป็นเครือข่ายภายในที่ไม่น่าเชื่อถือและตัดเส้นทาง NAT ทิ้ง จากนั้นดิสทริบิวชันจะสูญเสีย DNS และการเข้าถึงภายนอก ขณะที่อุโมงค์ของมันเองยังแข็งแรงดี: wg show รายงานการจับมือ ip route ดูถูกต้อง และ curl ค้าง
จะใช้วิธีแก้แบบไหนได้ขึ้นอยู่กับบิลด์ของ Windows แบบเก่าคือข้อยกเว้นในไคลเอนต์ของโฮสต์สำหรับซับเน็ต WSL ซึ่งเพิ่มไว้ใต้การตั้งค่าเครือข่ายภายในหรืออุโมงค์แยกของไคลเอนต์ แบบใหม่บนบิลด์ Windows 11 ที่รองรับคือเครือข่ายแบบกระจก: ใส่ networkingMode=mirrored ในส่วน [wsl2] ของ %UserProfile%\.wslconfig รัน wsl --shutdown แล้วดิสทริบิวชันจะใช้ส่วนติดต่อของโฮสต์ร่วมกันแทนซับเน็ต NAT ส่วนตัว โหมดกระจกยังเปลี่ยนพฤติกรรมของ localhost และพอร์ตขาเข้าด้วย จึงควรมองว่าเป็นการย้ายระบบมากกว่าสวิตช์
NAT, บริดจ์ และสิ่งที่โฮสต์มองเห็น
ภายใต้ NAT แพ็กเก็ตอุโมงค์ของเกสต์ถูกส่งไปยังที่อยู่สาธารณะของเซิร์ฟเวอร์ VPN และออกผ่านอะแดปเตอร์ของโฮสต์เป็น UDP หรือ TCP ที่เข้ารหัส โฮสต์เห็นเพียงหนึ่งโฟลว์กับจำนวนไบต์ ไม่เห็นอะไรเกี่ยวกับปลายทางข้างใน ภายใต้อะแดปเตอร์แบบบริดจ์ เกสต์มีอัตลักษณ์ชั้น 2 ของตัวเองบน LAN จริง รับสัญญาเช่า DHCP ของตัวเอง และต่อนโยบายใดก็ตามที่อิง MAC ก็ดูเหมือนอุปกรณ์ตัวที่สอง ทั้งสองโหมดไม่มีโหมดใดให้โฮสต์อ่านเนื้อหาของอุโมงค์ เกสต์แบบบริดจ์เพียงแต่ปรากฏชัดต่อเครือข่ายรอบตัวมากกว่า
การแยกขอบเขตก็มีพื้นล่าง เกสต์ซ่อนจากเครื่องที่ถือหน่วยความจำของมันไม่ได้ และใครที่ควบคุมโฮสต์ก็อ่านกุญแจจาก RAM ของเกสต์ได้ สิ่งที่อุโมงค์ในเกสต์ให้คุณคือขอบเขตการจัดเส้นทางและขอบเขตมัลแวร์ ไม่ใช่การป้องกันจากคนที่ถือแล็ปท็อป โหมดอะแดปเตอร์ที่มีเอกสารกำกับควรเปิดไว้ขณะเลือก เพราะโหมดเปลี่ยนทั้งสิ่งที่โฮสต์เห็นและสิ่งที่ LAN เห็น
คู่มือ: วาง กำหนดค่า พิสูจน์
รันการตรวจสี่ข้อนี้ตามลำดับในเชลล์ของเกสต์ใหม่ และหยุดที่ข้อแรกที่ไม่ตรงกับเจ้าของที่คุณบันทึกไว้
ip route get 1.1.1.1ที่คืนtun0หรือwg0หมายถึงเป็นของเกสต์ และeth0ที่มีฮอปถัดไปเป็นส่วนตัวหมายถึงเป็นของโฮสต์resolvectl query example.comหรืออ่าน/etc/resolv.confในที่ที่เกสต์ไม่ได้รันบริการตัวแก้ชื่อ อุโมงค์ที่ขนทราฟฟิกแต่ไม่ขน DNS คือสภาพที่กำหนดค่าไว้ครึ่งเดียวซึ่งพบบ่อยที่สุด- เปรียบเทียบทางออก:
curl -4 -s https://ifconfig.meในเกสต์ เทียบกับcurl.exe -4 -s https://ifconfig.meบนโฮสต์ ที่อยู่ต่างกันหมายความว่าเกสต์เป็นเจ้าของอุโมงค์ และโฮสต์ที่อยู่บน VPN ขณะเกสต์แสดง ISP ของบ้านคือกรณีที่ไม่มีอะไรสืบทอดมาเลย - ทำซ้ำทั้งสองด้วย
-6อุโมงค์ที่มีแต่ v4 จะรั่ว v6 เว้นแต่ไคลเอนต์จะบล็อกหรือจัดเส้นทางให้ และไคลเอนต์จำนวนมากปล่อย v6 ไว้บนอินเทอร์เฟซจริงตามค่าเริ่มต้น
ในการออกแบบเกตเวย์บนโฮสต์ ซึ่งเกสต์หลายตัวใช้อุโมงค์เดียวร่วมกัน โฮสต์ต้องส่งต่อและแปลที่อยู่ บนโฮสต์ Linux นั่นคือสามส่วน และเกสต์จะถอยกลับไปใช้เส้นทางธรรมดาของตนอย่างเงียบ ๆ เมื่อส่วนใดส่วนหนึ่งหายไป:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPTฝั่ง WireGuard ค่า AllowedIPs ของพาร์ทเนอร์ฝั่งโฮสต์ต้องรวมซับเน็ตของเกสต์ เช่น 192.168.122.0/24 ไม่อย่างนั้นแพ็กเก็ตตอบกลับจะไม่มาถึงเลยและการตั้งค่าจะดูเหมือนปัญหาไฟร์วอลล์ โฮสต์ Windows ได้ผลเดียวกันด้วยการแชร์การเชื่อมต่ออินเทอร์เน็ตหรือกฎ NAT บนสวิตช์ Hyper-V และต้องการการตรวจเส้นทางขากลับแบบเดียวกัน
เมื่อรูปแบบยังเปิดอยู่ ตารางนี้ครอบการจัดวางที่พบบ่อยที่สุด:
| Situation | Owner | Check first |
|---|---|---|
| One VM, host also on a corporate VPN | Guest | Does the host client block local networks? |
| Six lab VMs, one exit address | Host plus forwarding | ip_forward, NAT rule, server AllowedIPs |
| Malware or research VM | Guest, NAT | Snapshot age and resolver state |
| Bridged VM on an office LAN | Guest | DHCP lease and port security |
สองอุโมงค์ สองเกสต์ และความขัดแย้งระหว่างกัน
เมื่อต้องการทางออกสองทางพร้อมกัน รูปแบบที่ทนคือหนึ่งอุโมงค์ต่อหนึ่งเกสต์ แต่ละ VM เก็บเส้นทางเริ่มต้นและตัวแก้ชื่อของตัวเอง โฮสต์ยังอยู่บนเครือข่ายปกติ และสองอุโมงค์ไม่เคยแย่งตารางเส้นทางเดียวกัน การเชื่อมเกสต์สองตัวด้วยบริดจ์ก็ไม่รวมเส้นทางของกันและกัน: เครือข่ายเสมือนให้เส้นทาง และยังต้องบอกไคลเอนต์แต่ละตัวว่าทราฟฟิกภายในนี้อาจข้ามอุโมงค์ได้
การรันอุโมงค์ของโฮสต์และอุโมงค์ของเกสต์พร้อมกันเป็นเรื่องชอบด้วยกฎหมาย และการซ้อนกันโดยเจตนาบางครั้งก็คือสิ่งที่คุณต้องการ โดยเกสต์ออกผ่านอุโมงค์ของตัวเองและอุโมงค์นั้นออกผ่านของโฮสต์ สิ่งที่ทำให้กลายเป็นเหตุขัดข้องคือไม่มีใครบันทึกว่าปลายทางใดต้องไปถึงผ่านชั้นใด เก็บบัญชีสองคอลัมน์ของปลายทางและเจ้าของไว้ แล้วความขัดแย้งของเส้นทางจะกลายเป็นการค้นครั้งเดียวแทนที่จะเป็นการค้นพบทั้งบ่าย
ตรวจสอบ แล้วเก็บการกู้คืนไว้กับเจ้าของ
ทดสอบจากภายในเกสต์ ด้วยโปรเซสแอปพลิเคชันใหม่: ทราฟฟิก การแก้ชื่อ ทั้งสองตระกูลที่อยู่ และสิ่งที่เกิดขึ้นเมื่ออุโมงค์ล้ม ไอคอน VPN ของโฮสต์ไม่ได้บอกอะไรเกี่ยวกับความครอบคลุมของเกสต์ และนั่นคือการยืนยันเท็จที่พบบ่อยที่สุดในเรื่องนี้ทั้งหมด
การกู้คืนก็เป็นของเจ้าของด้วย อุโมงค์ที่เป็นของเกสต์ถูกกู้ด้วยไคลเอนต์ของเกสต์เองและเส้นทางที่มันเขียนไว้ การออกแบบที่เป็นของโฮสต์ถูกกู้ด้วยลำดับการบูตของโฮสต์ และกฎการส่งต่อไม่รอดจากการรีบูต เว้นแต่ยูนิตหรืองานตอนเริ่มระบบจะนำมาใช้ใหม่ สแนปช็อตที่กู้คืนคือการติดตั้ง ไม่ใช่การย้อนกลับ เพราะมันนำข้อมูลรับรองเก่าและเส้นทางเก่ากลับมาพร้อมดิสก์ ก่อนจะบอกว่างานเสร็จ ให้ยืนยันว่าเจ้าของยังตรงกับบรรทัดที่คุณบันทึก DNS และทั้งสองตระกูลที่อยู่แก้ได้ภายในเกสต์ อุโมงค์ที่ตายแล้วทิ้งเครือข่ายที่ยังใช้ได้แทนหลุมดำ และการรีบูตหรือการกู้คืนสแนปช็อตให้สภาพเดิม