กำหนดเส้นทางทราฟฟิก VM ในเครือข่าย host-only ผ่านเซิร์ฟเวอร์ TUN OpenVPN

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

สองเครือข่าย สองคำนำหน้า

ให้พูลของอุโมงค์และเครือข่าย host-only มีคำนำหน้าที่ต่างกัน และอย่าใช้คำนำหน้าหนึ่งแทนอีกอัน ในตัวอย่างนี้พูล VPN คือ 10.44.0.0/24 และเครือข่าย host-only คือ 192.168.99.0/24 โดยโฮสต์อยู่ที่ 192.168.99.1 และเกสต์อยู่ที่ 192.168.99.20 การกำหนดคำนำหน้าเดียวกันให้ทั้งอุปกรณ์ TUN และอะแดปเตอร์ host-only ไม่ได้ทำให้ทั้งสองเชื่อมกัน มันสร้างการอ้างสิทธิ์สองรายการบนช่วงที่อยู่เดียว และตารางเส้นทางจะตอบให้กับการอ้างสิทธิ์ที่บังเอิญเก็บไว้

อะแดปเตอร์ host-only มีอยู่บนโฮสต์และภายในเกสต์ และ ตัวมันเองไม่มีทางออกจากเครื่อง. การเชื่อมต่อแบบบริดจ์และ NAT มีการเปิดเผยที่ต่างกัน และการสลับไปโหมดบริดจ์ไม่ใช่ข้อกำหนดในการเข้าถึงบริการเดียวของเกสต์

โฮสต์มีเส้นทางอยู่แล้ว

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

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

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

ดันเส้นทาง แล้วกรองสิ่งที่มันเข้าถึง

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

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

เกสต์ต้องการทางกลับ

เกสต์ที่เข้าถึงได้จาก 10.44.0.x ต้องส่งการตอบกลับไปยังที่อยู่ host-only ของโฮสต์ หรือโฮสต์ต้องแปลต้นทาง การได้รับที่อยู่จาก DHCP ของ VirtualBox ไม่ได้บอกอะไรเกี่ยวกับการจัดวางทั้งสองแบบ

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

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

อุปกรณ์ TUN พาแพ็กเก็ต IP ดังนั้นการเพิ่มเกตเวย์เริ่มต้นภายในเกสต์ไม่ได้ทำให้อุโมงค์กลายเป็นเซกเมนต์อีเทอร์เน็ตกับอะแดปเตอร์ host-only สะพาน TAP เป็นการออกแบบที่ต่างออกไปโดยมีการสนับสนุนไคลเอนต์และความเป็นเจ้าของที่อยู่ของตัวเอง และการผสมคำอธิบายทั้งสองจะนำไปสู่การกำหนดค่าที่ไม่บรรจบกัน

ตรวจสอบ แล้วทำให้ทนต่อการรีสตาร์ต

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

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

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