ทำไม VPN ของแขกจึงล้มเหลวหลัง NAT ของ VirtualBox?

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

ระบุกระบวนการ VPN ก่อนโทษเครือข่าย

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

จดโหมดอะแดปเตอร์ของแขกตอนนี้ ก่อนเปลี่ยนสิ่งใด ค่าเดียวนั้นอธิบายส่วนใหญ่ของสิ่งที่ตามมา และเป็นสิ่งแรกที่ใครจะถามคุณในภายหลัง

การแลกเปลี่ยนภายนอกเป็นตัวกำหนดความเข้ากันได้

คู่มือเครือข่ายของ VirtualBox ระบุข้อจำกัดของ NAT ที่สำคัญที่นี่: มันจะไม่ผ่านโปรโตคอลอื่นนอกจาก TCP และ UDP, GRE ถูกระบุว่าไม่รองรับ และ PPTP ถูกยกเป็นตัวอย่างที่ได้รับผลกระทบ PPTP ใช้การแลกเปลี่ยนควบคุมแบบ TCP และ GRE สำหรับข้อมูล ดังนั้นการเชื่อมต่อควบคุมอาจสำเร็จได้ในขณะที่เส้นทางข้อมูลไม่สามารถข้ามพรมแดนเดียวกันได้ นี่เป็นหลักฐานสองอย่างที่ต่างกัน และมีเพียงอย่างเดียวที่เกี่ยวกับการพาทราฟฟิก การอนุญาตพอร์ต TCP 47 ในกฎไฟร์วอลล์ไม่เหมือนกับการอนุญาตโปรโตคอล IP 47 และสองสิ่งนี้ถูกสับสนอยู่เสมอ

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

บริดจ์เปลี่ยนอะไรจริง ๆ

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

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

สองอุโมงค์ สองร่องรอยหลักฐาน

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

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

เงื่อนไขใดกันแน่ที่ขวางคุณอยู่

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

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