Hyper-V เกสต์สูญเสีย DNS เมื่อ VPN ของโฮสต์เชื่อมต่อ
VM เกสต์ไม่ได้รับทันเนลของโฮสต์ ค้นหาโหมดสวิตช์หรือ NAT แชร์อะแดปเตอร์ VPN ในที่ที่เสนอให้ และส่งต่อพอร์ตในที่ที่ไม่ได้เสนอ
เกสต์ปกติดีเมื่อเช้านี้ จากนั้นโฮสต์เปิด Cisco AnyConnect และ VM ก็สูญเสีย DNS ความเชื่อถือโดเมน และโฟลเดอร์ที่แชร์ โดยไม่มีอะไรเปลี่ยนแปลงภายใน ทันเนลของโฮสต์และเครือข่ายของเกสต์เป็นเส้นทางแยกกัน การเชื่อมต่อหนึ่งไม่ได้ย้ายอีกอัน ทำงานจากภายในเกสต์ออกไปข้างนอก และจดสิ่งที่เห็นก่อนเปลี่ยนแปลงอะไร
สิ่งที่เกสต์ยังมองเห็นได้
บันทึกที่อยู่ เกตเวย์เริ่มต้น และตัวแก้ไขชื่อใน VM หนึ่งครั้งก่อนโฮสต์เชื่อมต่อและอีกครั้งหลังจากนั้น เกสต์ที่รักษาที่อยู่ไว้และสูญเสียเพียงการแก้ไขชื่อมีปัญหาเรื่องตัวแก้ไข เกสต์ที่ไม่เคยมีเส้นทางมีปัญหาเรื่องเส้นทาง และทั้งสองต้องทำงานต่างกัน จากโฮสต์แยกสองอย่างนี้ไม่ได้ การอ่านจึงต้องมาจากภายใน
การอ่านทั้งสามครั้งที่ทำสองรอบคือเส้นฐานของคุณ ทุกอย่างหลังจากนั้นวัดเทียบกับมัน
เกสต์ใช้อุโมงค์ทางออกใด
Hyper-V ตอบด้วยสองคำสั่ง: Get-VMSwitch แสดงรายการสวิตช์ และ Get-VMNetworkAdapter -VMName TestVM แสดงสวิตช์ที่เกสต์เชื่อมต่ออยู่ Default Switch คือเครือข่าย NAT ที่ Windows จัดการ สวิตช์ภายนอกส่งทราฟฟิกไปยังอะแดปเตอร์จริง สวิตช์ภายในไม่พาอะไรจนกว่าจะมีคนเพิ่ม NAT หรือเราเตอร์ VirtualBox นำเสนอแนวคิดเดียวกันสามแบบเป็น NAT, NAT Network และ bridged
โหมดเป็นตัวกำหนดว่าทันเนลของโฮสต์มีความสำคัญได้หรือไม่ NAT เกสต์ถูกแปลโดย WinNAT แล้วส่งต่อโดยสแต็กของโฮสต์ จึงตามตารางเส้นทางของโฮสต์ เมื่อใช้ไคลเอนต์ทันเนลเต็มรูปแบบ ทราฟฟิกของมันคือทราฟฟิกที่เข้าสู่อะแดปเตอร์ VPN และจะถูกทิ้งเมื่อไคลเอนต์บล็อกซับเน็ตภายใน ส่วนเกสต์ที่บริดจ์บนสวิตช์ภายนอกไม่เคยไปถึงการกำหนดเส้นทางของโฮสต์ เพราะเฟรมออกจาก NIC จริงโดยตรง จึงข้ามทั้งทันเนลและนโยบาย LAN ภายในของไคลเอนต์
การแชร์ทันเนลของโฮสต์กับ Hyper-V
ถ้าเกสต์ต้องการทันเนลและรันไคลเอนต์ของตัวเองไม่ได้ Windows สามารถแชร์การเชื่อมต่อ VPN เปิดคุณสมบัติของอะแดปเตอร์ VPN ไปที่การแชร์ และอนุญาตให้ผู้ใช้เครือข่ายอื่นเชื่อมต่อผ่านมัน ชี้อินเทอร์เฟซเครือข่ายในบ้านไปที่อะแดปเตอร์ Hyper-V vEthernet (Default Switch) จากนั้นทดสอบคำขอใหม่จากภายในเกสต์
ถือว่าการตั้งค่านี้เป็นวิธีแก้แบบห้องทดลอง เพราะมันประพฤติเช่นนั้น ต้องนำไปใช้ใหม่หลังตัดการเชื่อมต่อ เชื่อมต่อใหม่ หรือรีบูตโฮสต์ ใน Windows 11 บางบิลด์อะแดปเตอร์หายไปจากรายการดรอปดาวน์ทั้งหมด และเส้นทางนี้ก็ปิด
การติดตั้งคุณสมบัติ Hyper-V ใหม่ช่วยกู้เกสต์ดื้อๆ ได้บางเครื่อง เก็บไว้ทำทีหลัง และบันทึกสถานะของเกสต์ก่อน
การส่งต่อพอร์ตเมื่อซับเน็ตถูกกรอง
VPN ของโฮสต์ที่กรองซับเน็ต NAT ของเกสต์ทำให้การเข้าถึงโดยตรงเสียหาย ไม่ใช่การแก้ไขชื่อ VM ทำงานอยู่ แต่ ssh [email protected] ค้าง ขณะที่การแปลของไฮเปอร์ไวเซอร์ยังทำงาน ส่งต่อพอร์ตที่งานต้องการและเชื่อมต่อกับที่อยู่ของโฮสต์แทน บรรทัด Vagrantfile ด้านล่างครอบคลุม SSH และบริการ HTTPS หนึ่งบริการ ทั้งสองใส่ก่อนการโหลดใหม่
config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443การแก้ไขชื่อเป็นการตัดสินใจแยก และสมควรได้รับการแก้ไขของตัวเอง เปิดคุณสมบัติตัวแก้ไขของโฮสต์สำหรับอะแดปเตอร์ NAT นั้น หรือกำหนดค่าเซิร์ฟเวอร์ DNS ภายในเกสต์ด้วยมือ การชี้เกสต์ไปยังตัวแก้ไขสาธารณะทำให้การท่องเว็บทำงานและทำให้ชื่อภายในทุกชื่อเสีย ซึ่งแย่กว่าการหยุดให้บริการเพราะดูเหมือนสำเร็จ ทดสอบชื่อที่ตัวแก้ไขภายในเท่านั้นรู้
การตรวจสอบที่บอกว่ามันได้ผล
หลังการเปลี่ยนแปลงใดๆ เหล่านี้ ให้รันคำขอใหม่จากภายในเกสต์ขณะที่ VPN ของโฮสต์เชื่อมต่ออยู่ ไม่ใช่ก่อนหน้านั้น ตรวจสอบการแชร์อีกครั้งหลังเชื่อมต่อใหม่และหลังรีบูต เพราะการแก้ไขที่รอดเพียงอย่างใดอย่างหนึ่งไม่ใช่การแก้ไข ยืนยันว่ารายการตัวแก้ไขของเกสต์ตรงกับเครือข่ายที่ทราฟฟิกใช้จริง จากนั้นทดสอบการส่งต่อพอร์ตจากที่อยู่ของโฮสต์ เพราะการทดสอบจากเกสต์ไม่พิสูจน์อะไร จากภายในเกสต์ การตรวจสอบ PowerShell สองรายการครอบคลุมตัวแก้ไขและพอร์ตที่ส่งต่อ:
Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22บันทึกทุกการเปลี่ยนแปลงสวิตช์หรือไดรเวอร์พร้อมขั้นตอนย้อนกลับ Microsoft คู่มือ Hyper-V NAT อธิบายว่า Default Switch คืออะไรจริงๆ และควรอ่านก่อนสร้างเครือข่าย NAT ที่สองที่ขัดแย้งกับมัน