เครือข่าย VM แบบ NAT หรือ bridged: แบบไหนส่งทราฟฟิก VPN?

แขก NAT ยืมอุโมงค์ของโฮสต์เฉพาะเมื่อไคลเอนต์ทำอุโมงค์ตามเส้นทาง แขก bridged เลือกเส้นทางเอง ทดสอบแขกแล้วจึงเลือกโหมดให้ตรง

Bridged กับ NAT ไม่ใช่สองวิธีในการต่อแขกคนเดียวกันเข้ากับ VPN ของคุณ แต่เป็นเรื่องของ ว่าใครเป็นเจ้าของแพ็กเก็ตของแขกก่อนที่อุโมงค์ใดจะเข้ามาเกี่ยวข้อง. ในโหมด NAT ไฮเปอร์ไวเซอร์เขียนทราฟฟิกของแขกใหม่แล้วปล่อยออกมาจากโค้ดฝั่งโฮสต์ แขกจึงวิ่งไปตามเส้นทางที่โฮสต์มอบให้โค้ดนั้น ในโหมด bridged แขกได้อัตลักษณ์ชั้นลิงก์ของตัวเองบนเซกเมนต์จริงและเลือกเกตเวย์เริ่มต้นเอง ทำให้อุโมงค์ของโฮสต์ไม่เกี่ยวกับแขกเลย เว้นแต่เราเตอร์ LAN จะเป็นผู้ทำอุโมงค์ ผมเลิกมองว่า VM อยู่บน VPN แล้วหันมามองว่าเส้นทางเริ่มต้นของแขกนั้นชี้ไปที่ใด การทดสอบด้านล่างใช้เวลาสองสามนาทีต่อโหมดและตัดสินได้โดยไม่ต้องเดา

NAT เก็บแขกไว้หลังโค้ดของไฮเปอร์ไวเซอร์ ซึ่งเส้นทางของโฮสต์มีผล

ใน VirtualBox แขกแบบ NAT อยู่ใน 10.0.2.0/24 มีเกตเวย์เสมือนที่ 10.0.2.2 พร็อกซี DNS ที่ 10.0.2.3 และไม่มีเส้นทางของตัวเองไปยังเครือข่ายจริง แพ็กเก็ตขาออกถูกจับโดยกลไก NAT เขียนใหม่ให้ต้นทางเป็นโฮสต์ แล้วส่งต่อให้สแตก IP ของโฮสต์ จากตรงนั้นทราฟฟิกของแขกก็คือโฟลว์ของโฮสต์ และการค้นหาเส้นทางทำตามปลายทาง ไคลเอนต์อุโมงค์เต็มที่ติดตั้ง 0.0.0.0/1 และ 128.0.0.0/1 บนโฮสต์ก็จับมันได้โดยไม่เคยรู้ว่ามี VM อยู่ บทว่าด้วยเครือข่ายของ VirtualBox จาก Oracle ระบุค่าเริ่มต้นเหล่านี้ไว้ ถ้าคุณต้องการยืนยันที่อยู่ในบิลด์ของคุณ

เครือข่ายเริ่มต้นของ libvirt มาถึงจุดเดียวกันจาก 192.168.122.0/24 โดย dnsmasq แจกซับเน็ตและโฮสต์ทำแมสคาราดให้ซับเน็ตนั้น แพ็กเก็ตของแขกจึงกลับมาถึงการตัดสินใจเรื่องเส้นทางของโฮสต์อีกครั้ง ข้อยกเว้นคือไคลเอนต์ที่เลือกทราฟฟิกตามโปรเซสแทนที่จะเป็นตามเส้นทาง ถ้ารายการอุโมงค์แบบแบ่งมีแค่เบราว์เซอร์ของคุณ กลไก NAT ไม่อยู่ในรายการนั้น แขกก็ออกจากเครื่องโดยไม่มีอุโมงค์ ขณะที่เบราว์เซอร์บนโฮสต์ยังดูเหมือนถูกคลุมอยู่ ซับเน็ตเดียวกัน ผลตรงกันข้าม

Bridged ให้แขกมีที่ของตัวเองบน LAN จริง

แขกแบบ bridged ได้การ์ดเครือข่ายเสมือนที่ผูกกับอะแดปเตอร์จริง ได้ที่อยู่ MAC ของตัวเอง และได้ลีส DHCP จากเครือข่ายจริง เกตเวย์เริ่มต้นคือเราเตอร์ LAN ไม่ใช่ไฮเปอร์ไวเซอร์ และเฟรมของแขกออกสู่สายผ่านอะแดปเตอร์นั้น เส้นทางอุโมงค์ของโฮสต์อยู่ในตารางของโฮสต์และไม่ถูกนำมาพิจารณาเลย เพราะเฟรมของแขกไม่เคยเข้าสู่สแตก IP ของโฮสต์

เรื่องนี้ตัดทั้งสองทาง การท่อง mDNS และ SMB เริ่มทำงานเพราะแขกเห็นทราฟฟิกแพร่กระจายของ LAN และแขกก็เข้าถึงได้จากเครื่องอื่นในเซกเมนต์เดียวกันโดยไม่มีไฟร์วอลล์ของโฮสต์กั้นอยู่ Bridging ไม่ใช่วิธีดันแขกผ่านอุโมงค์ที่มีอยู่แล้ว การต่อ VM เข้ากับอินเทอร์เฟซ WireGuard หรือ OpenVPN ของโฮสต์ไม่ใช่สิ่งที่ VirtualBox หรือ libvirt ทำให้คุณ ถ้าแขกแบบ bridged ต้องถูกทำอุโมงค์ อุโมงค์นั้นต้องสิ้นสุดที่ใดที่หนึ่งบน LAN นั้น

การทดสอบที่ยุติข้อโต้แย้ง

รันการตรวจเดียวกันในทั้งสองโหมดแล้วจดคำตอบไว้:

  • บนโฮสต์ curl -s https://ifconfig.me ให้ที่อยู่สาธารณะ v4
  • ในแขก คำสั่งเดียวกัน บวกกับ ip route บน Linux หรือ Get-NetRoute -DestinationPrefix 0.0.0.0/0 บน Windows สำหรับเกตเวย์เริ่มต้น
  • อัตลักษณ์ของตัวแก้ไขชื่อ: resolvectl status หรือ cat /etc/resolv.conf ในแขก เพื่อดูว่าชี้ไปที่ 10.0.2.3 หรือเซิร์ฟเวอร์ใน LAN
  • ตระกูลที่อยู่: ip -6 addr show scope global และคำขอ v6 หนึ่งครั้ง เพราะอุโมงค์ v4 ไม่ได้บอกอะไรเกี่ยวกับที่อยู่ v6 สาธารณะที่แขกอาจมี

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

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

โหมดไหนเหมาะกับงาน

โหมดคือการตัดสินใจเรื่องเส้นทาง จึงควรเลือกจากความต้องการไม่ใช่จากความเคยชิน:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

แถวแรกคือที่ที่คนพลาด: NAT บวกไคลเอนต์อุโมงค์เต็มบนโฮสต์คลุมแขกได้จริง แต่เฉพาะเมื่อไคลเอนต์ทำอุโมงค์ตามเส้นทางและอัปลิงก์ของโฮสต์คืออุโมงค์นั้น ย้ายไคลเอนต์ไปเป็นรายการอนุญาตเฉพาะเบราว์เซอร์ การคลุมนั้นก็หายไปโดยไม่มีข้อผิดพลาดที่ไหนเลย แถวที่สี่คือความผิดพลาดกลับทาง แขกที่ทำ bridged เพื่อความสะดวกแล้วจู่ ๆ ก็ตอบ SMB หรือ SSH บน LAN ของออฟฟิศ

ความล้มเหลวที่มักถูกโทษว่าเป็นความผิดของ VPN

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

Bridging ไปยัง Wi-Fi คืออีกเคสคลาสสิก จุดเชื่อมต่อมักไม่ส่งต่อเฟรมที่มี MAC ต้นทางแปลกปลอม บริดจ์บน wlan0 จึงล้มเหลวทันทีหรือทำงานได้จนกว่าการแยกไคลเอนต์บน AP จะเริ่มทิ้งมัน VirtualBox ยังคงเสนออะแดปเตอร์ไร้สายในรายการ ถ้าโฮสต์อยู่บน Wi-Fi และแขกต้องเป็น bridged ให้วางแผนทดสอบแทนการสันนิษฐาน

MTU คือตัวที่สาม แขกแบบ bridged คง MTU ของ LAN ที่ 1500 ไบต์ และถ้ามันรันไคลเอนต์ WireGuard ของตัวเองที่ 1420 การจับมือ TLS ขนาดใหญ่จะค้างขณะที่คำขอเล็กผ่านได้ ภายใต้ NAT ค่า MTU ของอุโมงค์โฮสต์เป็นปัญหาของโฮสต์ แต่แขกยังเชื่อว่า 1500 และ UDP ที่ตั้งบิต don't-fragment ก็ตกหลุมดำแบบเดียวกัน

จดโหมดไว้ แล้วตรวจซ้ำทุกครั้งที่อะแดปเตอร์เปลี่ยน

บันทึกโหมด อินเทอร์เฟซของโฮสต์ที่บริดจ์ใช้ เกตเวย์เริ่มต้นของแขก ตัวแก้ไขชื่อ และที่อยู่ขาออกทั้ง v4 และ v6 บันทึกนี้คือสิ่งที่ทำให้ความล้มเหลวครั้งถัดไปถูกแก้ได้ถูก ๆ เมื่อแล็ปท็อปย้ายจากด็อกไป Wi-Fi แขกแบบ bridged จะตามบริดจ์ไปยังอะแดปเตอร์จริงอีกตัวและอาจได้ลีสใหม่ในอีกซับเน็ต ขณะที่แขก NAT ยังคงที่อยู่ 10.0.2.x และสืบทอดอัปลิงก์ที่ต่างออกไปอย่างเงียบ ๆ

ก่อนปิดตั๋ว ให้ยืนยันแต่ละข้อต่อไปนี้:

  • ที่อยู่ขาออกของแขกต่างจากที่อยู่ขาออกของโฮสต์ แปลว่าแขกไม่ได้อยู่บนอุโมงค์ของโฮสต์
  • ตัวแก้ไขชื่อคือพร็อกซี 10.0.2.3 หรือเซิร์ฟเวอร์ใน LAN และคุณรู้ว่าตัวไหนตอบ
  • ไม่มีที่อยู่ v6 สาธารณะในแขก ถ้าดีไซน์อุโมงค์เป็น v4 เท่านั้น
  • เมื่ออุโมงค์ของโฮสต์ถูกปิด แขกหยุดท่อง หรือตอนนี้คุณรู้แล้วว่ามันไม่เคยพึ่งอุโมงค์นั้น
  • แขกไม่เห็นทราฟฟิกแพร่กระจายของ LAN ที่มันไม่ควรเห็น

บทความที่เกี่ยวข้อง