VPN เกตเวย์ของ VirtualBox สำหรับ LAN: บริดจ์ เส้นทาง และการย้อนกลับ

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

ใช้ที่อยู่ที่เข้าถึงได้

ตั้งค่าอะแดปเตอร์ LAN ของ VM ให้เป็นโหมด Bridged Adapter ที่ได้รับอนุญาตสำหรับเครือข่ายนั้น และให้ที่อยู่ผ่านกระบวนการจัดสรรปกติ จากนั้น VM จะปรากฏบน LAN จริงเหมือนโฮสต์อื่น ๆ เส้นทางเริ่มต้นยังคงต้องใช้เกตเวย์จริง เพื่อให้การขนส่งที่เข้ารหัสไปยังเพียร์ VPN ยังเข้าถึงได้ อย่าใช้ที่อยู่ NAT เริ่มต้นของ VirtualBox เป็นฮอปถัดไปของ LAN เพราะที่อยู่นั้นอยู่หลัง NAT เสมือนและไม่ใช่ on-link สำหรับโฮสต์หรือเครื่องอื่นใน LAN

LAN router:          192.168.70.1/24
VirtualBox host:     192.168.70.5/24
VPN gateway VM:      192.168.70.10/24
Example LAN service: 192.168.70.40
VPN client pool:     10.80.0.0/24

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

ประกาศ LAN แล้วจึงส่งต่อ

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

dev tun
topology subnet
server 10.80.0.0 255.255.255.0
push "route 192.168.70.0 255.255.255.0"

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

เส้นทางย้อนกลับอยู่บนเราเตอร์ของ LAN

อุปกรณ์ใน LAN ตอบกลับผ่านเกตเวย์เริ่มต้นของตน ซึ่งคือเราเตอร์ LAN ที่ 192.168.70.1 เราเตอร์นั้นไม่รู้ว่า 10.80.0.0/24 อยู่ที่ใดเว้นแต่จะบอก เพิ่มเส้นทางของพูลลงในการตั้งค่าถาวรที่เราเตอร์รองรับ โดยชี้ไปที่ที่อยู่ LAN ของ VM การเพิ่มเฉพาะบนโฮสต์ VirtualBox จะซ่อมเฉพาะเส้นทางที่ถามโฮสต์นั้น และนั่นไม่ใช่ทุกอุปกรณ์ใน LAN

ip route add 10.80.0.0/24 via 192.168.70.10

ไฟร์วอลล์ของปลายทางเองยังต้องอนุญาตพูลไคลเอนต์เป็นต้นทาง เส้นทางพาแพ็กเก็ตไป แต่ไม่ได้ให้บริการ

หากเปลี่ยนเราเตอร์ LAN ไม่ได้ ทางเลือกคือการแปลต้นทางแบบจำกัดบน VM ซึ่งทำให้การตอบกลับย้อนกลับได้โดยไม่ต้องมีเส้นทาง และซ่อนที่อยู่ไคลเอนต์แต่ละรายจากบริการ LAN

ติดตามแพ็กเก็ตหนึ่งแพ็กเก็ตตั้งแต่ต้นจนจบ

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

ทดสอบด้วยแอปพลิเคชันจริงจากไคลเอนต์ระยะไกล แล้วทำซ้ำหลังจากโหลดการตั้งค่าที่จัดการใหม่ทั้งบน VM และบนเราเตอร์

หากไคลเอนต์เข้าถึง VM ได้แต่เข้าถึงบริการไม่ได้ ให้ตรวจสอบเส้นทางของเราเตอร์ก่อน หากบริการได้รับคำขอแต่ไคลเอนต์ไม่เคยเห็นการตอบกลับ เส้นทางย้อนกลับคือผู้ต้องสงสัย