การแชร์เซสชัน VPN ของโฮสต์กับเกสต์ VMware

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

สองเหตุผลที่บริดจ์ทำงานไม่ได้

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

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

สร้างเซกเมนต์ที่โฮสต์ถือครอง

ในตัวแก้ไขเครือข่ายเสมือน ให้เพิ่มเครือข่าย host-only เช่น VMnet3 บนพรีฟิกซ์ที่คุณไม่กำหนดเส้นทางที่อื่น เช่น 172.28.90.0/24 โฮสต์รับ 172.28.90.1 บนอะแดปเตอร์นั้น และเกสต์เชื่อมต่อกับสวิตช์เดียวกัน ปิด DHCP ของไฮเปอร์ไวเซอร์บนเซกเมนต์นั้นเพื่อให้บริการที่อยู่เดียวถือครอง

ยืนยันว่า Windows มองเห็นอินเทอร์เฟซก่อนที่คุณจะสร้างสิ่งใดบนนั้น เพราะการออกแบบทั้งหมดขึ้นอยู่กับว่าอะแดปเตอร์นั้นเป็นเรื่องปกติ:

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24

อะแดปเตอร์ host-only ปรากฏที่นั่นเหมือนอะแดปเตอร์จริงทั่วไป นั่นคือความแตกต่างจากอะแดปเตอร์อุโมงค์ซึ่งเชื่อมต่อกับสิ่งใดไม่ได้เลย

แปลพรีฟิกซ์ของเกสต์

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

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24

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

ตรวจสอบฮอปแรก แล้วจึงตรวจสอบราคา

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

tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"

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

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