เกสต์แบบบริดจ์ของ VMware สูญเสียเครือข่ายหลัง OpenVPN
อะแดปเตอร์ TAP ใหม่เปลี่ยนว่า VMware ทำบริดจ์ไปยัง NIC ตัวใดของโฮสต์ ตัดสินใจระหว่างการปักหมุด VMnet0 กับการเราเตอร์เกสต์ แล้วอ่านผลลัพธ์ภายใน VM
เกสต์ที่เคยทำบริดจ์และเข้าถึงได้เมื่อชั่วโมงก่อนตอนนี้หมดเวลาทุกอย่าง และไม่มีใครแก้การตั้งค่าของมัน บนโฮสต์ อินเทอร์เน็ตยังทำงานผ่านอุโมงค์ ข้อเท็จจริงสองข้อนี้รวมกันชี้ให้ออกห่างจาก VPN และไปทางไฮเปอร์ไวเซอร์ เพราะโฮสต์และเกสต์ไม่ได้ใช้เส้นทางเดียวกันอีกต่อไป อะแดปเตอร์เสมือนใหม่ตัวเดียวก็เพียงพอที่จะทำให้เกิดเรื่องนี้
เกสต์ไม่ได้เปลี่ยน บริดจ์ต่างหากที่เปลี่ยน
การติดตั้งไคลเอนต์ OpenVPN บน Windows จะเพิ่มอะแดปเตอร์เครือข่ายเสมือนที่บริการผูกไว้เมื่ออุโมงค์ถูกยกขึ้น สำหรับระบบปฏิบัติการมันดูเหมือนอินเทอร์เฟซธรรมดาที่มีสถานะลิงก์ และบ่อยครั้งมีที่อยู่ของตัวเอง เท่านี้ก็พอให้ VMware มองว่าเป็นตัวเลือกสำหรับบริดจ์
VMnet0 ถูกตั้งเป็นอัตโนมัติโดยค่าเริ่มต้น ซึ่งหมายความว่าไฮเปอร์ไวเซอร์เลือกอะแดปเตอร์ของโฮสต์ทุกครั้งที่ทำบริดจ์ อะแดปเตอร์เสมือนที่เพิ่งติดตั้งจะเข้าสู่กลุ่มนั้น และถ้าถูกเลือก ทุกเฟรมที่เกสต์ส่งออกจะไปยังอุปกรณ์อุโมงค์แทนที่จะไปยังพอร์ตจริงของสวิตช์
ปักหมุดบริดจ์หรือเราเตอร์เกสต์
สาขาแรกถูกต้องเมื่อเกสต์ควรเป็นสมาชิกที่เท่าเทียมบน LAN จริง หยุดปล่อยให้บริดจ์เลือก และระบุอะแดปเตอร์อย่างชัดเจน สาขาที่สองใช้เมื่อเกสต์ควรใช้อุโมงค์ขององค์กร ซึ่งในกรณีนั้นบริดจ์ไม่เคยเป็นการออกแบบที่ถูกต้อง เพราะเกสต์แบบบริดจ์ไม่ได้รับเส้นทาง VPN ของโฮสต์
ตัดสินใจเรื่องนั้นก่อน เพราะคำตอบสองแบบนำไปสู่งานที่ต่างกัน การสลับลำดับจะได้บริดจ์ที่ปักหมุดอย่างถูกต้องแต่ผูกกับเกสต์ที่ไม่ควรถูกทำบริดจ์เลย
สำหรับสาขาแรก ให้เปิด Virtual Network Editor บนโฮสต์ เลือก VMnet0 และแทนที่อัตโนมัติด้วยอะแดปเตอร์จริง ถ้ามีอะแดปเตอร์หลายตัว ให้ใช้รายการการตั้งค่าอัตโนมัติและยกเลิกเครื่องหมายถูกสำหรับทุกสิ่งที่ไม่ควรรับส่งทราฟฟิกของเกสต์เด็ดขาด ได้แก่ อุปกรณ์ OpenVPN TAP หรือ Wintun รวมถึงอะแดปเตอร์ Hyper-V, WSL, Docker และ loopback ให้คงเครื่องหมายถูกไว้ทั้งอะแดปเตอร์จริงแบบมีสายและไร้สายบนแล็ปท็อป มิฉะนั้นเกสต์จะสูญเสียบริดจ์ในครั้งถัดไปที่ผู้ใช้ต่อกลับเข้าแท่นวาง
สามเงื่อนไขที่ตัดสินการเลือก
บริดจ์จะเหมาะสมหรือไม่ขึ้นอยู่กับว่าเกสต์มีไว้เพื่ออะไร ถ้าเกสต์ต้องปรากฏเป็นโฮสต์ของตัวเองบน LAN พร้อมที่อยู่ของตัวเองและการเข้าถึงขาเข้าของตัวเอง บริดจ์คือรูปแบบที่ถูกต้องและการปักหมุดคือการแก้ไขทั้งหมด ถ้าเกสต์ต้องการเพียงการเข้าถึงขาออก เครือข่ายแบบเฉพาะโฮสต์หรือ NAT นั้นง่ายกว่าและไม่ได้รับผลกระทบจากการเปลี่ยนอะแดปเตอร์
ถ้าเกสต์ต้องใช้อุโมงค์เดียวกับโฮสต์ ทั้งโหมดบริดจ์และอะแดปเตอร์ที่ปักหมุดไว้ก็ไม่ช่วย เพราะทราฟฟิกของเกสต์ไม่เคยเข้าสู่การตัดสินใจเรื่องเส้นทางของโฮสต์ กรณีนั้นต้องใช้เส้นทางที่เราเตอร์หรือแปลงบนโฮสต์ และการเลือกอะแดปเตอร์ก็ไม่มีความหมาย
VMware Player ไม่มีตัวแก้ไขเครือข่ายในอินเทอร์เฟซ ดังนั้นโฮสต์ที่รันเฉพาะ Player ต้องใช้ตัวแก้ไขแบบแยกเดี่ยวหรือการติดตั้ง Workstation เพื่อเข้าถึงการตั้งค่าเหล่านี้ ข้อจำกัดนั้นบางครั้งก็เป็นตัวกำหนดแนวทางด้วยตัวเอง
อ่านผลลัพธ์จากภายในเกสต์
รีสตาร์ต NIC เสมือน หรือรีสตาร์ตเกสต์ เพื่อให้ขอเช่าที่อยู่อีกครั้ง จากนั้นอ่านสิ่งที่มันได้รับจริง ไม่ใช่สิ่งที่โฮสต์คิดว่าได้ตั้งค่าไว้
ipconfig /all
ip addr
ip route
อ่านสองฟิลด์ในผลลัพธ์นั้นและเพิกเฉยส่วนที่เหลือไปก่อน เกตเวย์ควรเป็นเราเตอร์ของ LAN และคำอธิบายอะแดปเตอร์ควรระบุอุปกรณ์ Ethernet ของ VMware ไม่ใช่อุโมงค์ ที่อยู่ใน 169.254.0.0/16 ที่กำหนดให้ตัวเองหมายความว่าไม่มีเซิร์ฟเวอร์ DHCP ตอบ และนั่นคือลักษณะของบริดจ์บนอะแดปเตอร์อุโมงค์เมื่อมองจากฝั่งเกสต์
ยังมีความแตกต่างอีกข้อที่ควรทำก่อนจะเปลี่ยนสิ่งอื่นใด เกสต์ที่ไปถึงเราเตอร์แต่ไม่ถึงอินเทอร์เน็ตมีบริดจ์ที่ทำงานได้และมีปัญหาที่ต้นทาง เกสต์ที่ได้รับที่อยู่ในช่วงของอุโมงค์ยังคงเชื่อมต่อกับอุปกรณ์ผิดตัว การปิดอะแดปเตอร์ TAP ไม่ใช่ทางแก้สำหรับทั้งสองกรณี เพราะบริการ OpenVPN ต้องการมัน