Hyper-V VM ใช้ VPN ของโฮสต์หรือไม่? ขึ้นอยู่กับสวิตช์

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

ตำนาน เล่ากันตรงๆ

ความเชื่อคือ VPN ที่ติดตั้งบนโฮสต์ปกป้องทั้งเครื่องรวมถึง VM เพราะ VM เป็นเพียงกระบวนการที่ทำงานบนเครื่องนั้น เป็นความเชื่อที่สบายใจ เพราะแอนติไวรัสและไฟร์วอลล์ของโฮสต์มักทำงานแบบนั้นจริง แต่เส้นทางเครือข่ายไม่เป็นเช่นนั้น

เฟรมของเกสต์จะถูกสแต็ค VPN ของโฮสต์แตะเมื่อโฮสต์กำหนดเส้นทางหรือกรองมัน จดประโยคนั้นลงกระดาษโน้ต เพราะทุกกรณีด้านล่างเป็นแค่รูปแบบหนึ่งของมัน

สามประเภทสวิตช์ สามเส้นทาง

สวิตช์ภายนอกผูกอะแดปเตอร์เสมือนเข้ากับการ์ดเครือข่ายจริง และเกสต์ส่งเฟรมผ่านการผูกนั้นด้วยที่อยู่ MAC ของตัวเอง เกสต์กลายเป็นสมาชิกเท่าเทียมบนเครือข่ายจริง มีสัญญาเช่า DHCP เกตเวย์ และเซิร์ฟเวอร์ DNS ของตัวเอง เส้นทางเริ่มต้นของ VPN บนโฮสต์อยู่ในสแต็คของโฮสต์และไม่ย้ายเฟรมเหล่านั้น เพราะพวกมันถูกบริดจ์แทนที่จะถูกกำหนดเส้นทางผ่านโฮสต์ นี่ก็เป็นเหตุผลที่สวิตช์ภายนอกบนอะแดปเตอร์ Wi-Fi เป็นความคิดที่ไม่ดี ไดรเวอร์ไร้สายส่วนใหญ่จะไม่ส่งเฟรมสำหรับที่อยู่ MAC ที่สอง

สวิตช์ภายในเชื่อมเกสต์กับอะแดปเตอร์เสมือนของโฮสต์ โดยลำพังมันไม่มีทางออกอินเทอร์เน็ต ออบเจ็กต์ NAT บนโฮสต์เป็นผู้ให้การแปลที่อยู่ รายละเอียดอยู่ใน คู่มือ NAT ของ Hyper-V ตอนนี้แพ็กเก็ตของเกสต์เข้าสู่การกำหนดเส้นทางและเส้นทาง NAT ของโฮสต์ ดังนั้นเส้นทางและฟิลเตอร์ของไคลเอนต์ VPN จึงสำคัญอีกครั้ง นี่คือการจัดวางที่ VM ตาม VPN ของโฮสต์จริงๆ และเป็นที่ที่ kill switch ตัดเกสต์ออกได้ทั้งหมด

สวิตช์ส่วนตัวไม่มีอะแดปเตอร์โฮสต์และไม่มีลิงก์ขึ้น เกสต์คุยกันเองเท่านั้น ดังนั้นถ้า VM บนสวิตช์ส่วนตัวไม่มีอินเทอร์เน็ต สาเหตุคือเราเตอร์ที่หายไป และ VPN ไม่เกี่ยวข้อง

สวิตช์เริ่มต้นคือการจัดวางของมันเอง

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

ถ้า VM อยู่บนสวิตช์เริ่มต้น ให้อ่านที่อยู่ที่เกสต์ได้รับ แล้วเปรียบเทียบกับตาราง NAT ของโฮสต์ก่อนแตะไคลเอนต์ VPN ความไม่ตรงกันระหว่างเกตเวย์ของเกสต์กับคำนำหน้า NAT อธิบายความล้มเหลวได้มากกว่าการตั้งค่าไคลเอนต์ใดๆ

ข้อเท็จจริงสี่ข้อที่ยุติคำถาม

เก็บข้อมูลเหล่านี้ก่อนจะเปลี่ยนอะไร ประเภทสวิตช์และลิงก์ขึ้นของมัน อะแดปเตอร์ที่ผูกกับ VM ที่อยู่ เกตเวย์ และ DNS ของเกสต์เอง และสถานะ NAT กับเส้นทางเริ่มต้นของโฮสต์ คำสั่งอ่านอย่างเดียวคือ Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat และ Get-NetRoute -DestinationPrefix 0.0.0.0/0 ภายในเกสต์ ipconfig /all ให้ส่วนที่เหลือ

จากนั้นตัดสินว่าเกสต์ควรทำอะไร ถ้าควรอยู่นอก VPN ให้ขอข้อยกเว้นที่ผู้ให้บริการสนับสนุนสำหรับเส้นทางนั้นโดยเฉพาะ เพราะการยกเว้นไฟล์ปฏิบัติของโฮสต์ไม่ได้ยกเว้นทราฟฟิก VM ที่ถูกส่งต่อ ถ้าควรใช้ VPN ให้ยืนยันการจัดการทราฟฟิก VM ตามเอกสารของไคลเอนต์ แทนที่จะสมมติว่าการทดสอบเบราว์เซอร์บนโฮสต์ครอบคลุมเรื่องนี้

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

ราคาที่ตำนานนี้เรียกเก็บ

ผู้คนปิด kill switch เพิ่มเส้นทางแบบสถิต หรือลบแล้วสร้างสวิตช์ใหม่ เพียงเพื่อให้การทดสอบผ่าน ทุกทางลัดเปลี่ยนโหมดความล้มเหลว เกสต์อาจออกสู่อินเทอร์เน็ตทางเส้นที่ไม่มีใครตั้งใจ หรือโฮสต์อาจสูญเสียการเชื่อมต่อเมื่อสวิตช์ภายนอกผูกอะแดปเตอร์จริงของมันใหม่

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

คำตอบที่ยั่งยืนคือหนึ่งบรรทัดต่อ VM หนึ่งเครื่องในทะเบียนคลังสินค้า ใช้สวิตช์ใดและองค์การใดให้เกตเวย์ของมัน เมื่อเขียนไว้แล้ว การเปลี่ยน VPN ครั้งต่อไปคือการค้นหา ไม่ใช่การเดาทั้งบ่าย