วิธีเข้าถึงบริการส่วนตัวผ่าน VPN ในเครื่องเสมือน

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

บันทึกทั้งสองเส้นทางก่อนเปลี่ยนแปลงสิ่งใด

บนเครื่องลูก ipconfig /all แสดงอะแดปเตอร์ที่รับส่ง VPN และที่อยู่ที่ได้รับจาก DHCP ของเครือข่ายเสมือน บน Mac ให้บันทึกอินเทอร์เฟซเสมือนที่ไฮเปอร์ไวเซอร์สร้างขึ้นสำหรับเซกเมนต์นั้น ใน VMware Fusion อุปกรณ์เฉพาะโฮสต์มักเป็น vmnet1 และ Parallels ตั้งชื่อของตัวเอง สังเกตว่าใครแจกที่อยู่ตรงนั้น แล้วจดทุกอย่างไว้ เพราะซับเน็ตเฉพาะโฮสต์มักถูกกำหนดใหม่เมื่อสร้างเครือข่ายเสมือนใหม่ ตรวจสอบโหมดเครือข่ายของเครื่องเสมือนในไฮเปอร์ไวเซอร์ ไม่ใช่ในความทรงจำของคุณ โหมดแชร์หรือ NAT สำหรับอะแดปเตอร์ที่หันออกอินเทอร์เน็ต บวกโหมดเฉพาะโฮสต์สำหรับอะแดปเตอร์ที่หันไปทาง Mac คือรูปแบบที่ขั้นตอนเหล่านี้ตั้งสมมติฐานไว้

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

ยืนยัน VPN ของเครื่องลูกเองก่อน

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

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

เพิ่มขาเฉพาะโฮสต์และทดสอบมันเพียงลำพัง

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

Windows อาจจัดประเภทอะแดปเตอร์ใหม่เป็นเครือข่ายสาธารณะ ซึ่งบล็อกทราฟฟิกขาเข้าโดยค่าเริ่มต้น ตั้งค่าโปรไฟล์ก่อนแก้ไขปัญหาอื่นใด

ส่งต่อพอร์ตเดียว ไม่ใช่ทั้งซับเน็ต

เลือกพอร์ตที่ส่งต่อเพียงพอร์ตเดียวแทนการส่งต่อ IP ทั้งหมด Windows มี netsh interface portproxy ซึ่งส่งต่อพอร์ตที่กำลังฟังไปยังโฮสต์และพอร์ตปลายทาง และต้องให้บริการ IP Helper ทำงานอยู่

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

ตรวจสอบ แล้วเขียนการย้อนกลับ

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

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