VPN เปิดอยู่แต่เข้า VM ไม่ได้? ปัญหาน่าจะไม่เคยอยู่ที่เส้นทาง

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

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

เส้นทางมักยังคงเป็นแบบท้องถิ่น

ถามเคอร์เนลแทนที่จะอ่านหน้าแรกของตารางเส้นทาง บนลินุกซ์ ip route get 192.168.56.10 รายงานเส้นทาง อินเทอร์เฟซ และที่อยู่ต้นทางที่จะใช้จริง ซึ่งเป็นคำตอบที่ต่างจากการอ่านเส้นทางเริ่มต้นแล้วเดา ถ้าเอาต์พุตระบุอินเทอร์เฟซ host-only อุโมงค์ก็ไม่ได้เกี่ยวข้องกับเส้นทางนั้นเลย

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

การเลือกเส้นทางและการรับแพ็กเก็ตเป็นการตัดสินใจคนละอย่าง

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

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

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

แขกมีสามวิธีที่จะบอกว่าไม่

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

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

ตรวจสอบทั้งสามข้อก่อนคิดจะเปลี่ยนโหมดเครือข่ายของ VM แต่ละข้อเป็นการเปลี่ยนแปลงที่เล็กกว่าการออกแบบการเชื่อมต่อของแขกใหม่ และแต่ละข้อมีการทดสอบที่ชัดเจน

บริดจ์คืออะไรจริง ๆ และมีต้นทุนเท่าไร

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

ใช้เมื่อแขกจำเป็นต้องเป็นสมาชิกที่เท่าเทียมบน LAN นั้นจริง ๆ และการเปิดเผยได้รับอนุมัติ อย่าใช้เพราะบริการหนึ่งหยุดตอบสนอง เนื่องจากการเปลี่ยนแปลงอาจย้ายแขกออกจากพื้นที่แยกที่ทำให้การพัฒนากับมันปลอดภัย

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

ส่วน เครือข่าย host-only ของ VirtualBox อธิบายอินเทอร์เฟซซอฟต์แวร์ฝั่งโฮสต์และความแตกต่างจากการเชื่อมต่อแบบบริดจ์ ซึ่งเป็นแหล่งอ้างอิงที่ควรอ่านก่อนสันนิษฐานว่าโหมดทั้งสองใช้แทนกันได้