คุณสามารถใช้บริดจ์โดยไม่ต้องบังคับอินเทอร์เฟซอีเทอร์เน็ตทางกายภาพใดๆ ของคุณบนโฮสต์ VM
สมมติว่าเรายึดติดกับเครือข่ายย่อย 10.0.2.0/24 (ซึ่งไม่จำเป็น):
# ip l เพิ่มสะพานประเภท natbr0
# ip เพิ่ม 10.0.2.1/24 dev natbr0
จากนั้นสร้างไฟล์ต่อไปนี้:
$ echo 'อนุญาต natbr0' | sudo tee /etc/qemu/bridge.conf
อนุญาต natbr0
จากนั้นเริ่ม qemu ด้วยเช่น -สะพานนิค br=natbr0 หรือ สะพาน -netdev,br=natbr0,id=nb0 -อุปกรณ์ virtio-net,netdev=nb0, ซึ่งจะ แตะ VM ของคุณไปยังสะพานในลักษณะไดนามิก (เช่น แตะ อินเทอร์เฟซจะถูกลบออกเมื่อปิด VM)
คุณจะต้องกำหนดค่า IP แบบคงที่บน VM ด้วย:
# ip เพิ่ม 10.0.2.2/24 dev ens3
# ip r เพิ่มค่าเริ่มต้นผ่าน 10.0.2.1
เว้นแต่คุณจะตั้งค่าเซิร์ฟเวอร์ DHCP (เช่น dnsmasq) บนโฮสต์ด้วย อย่าลืมกำหนดค่าเซิร์ฟเวอร์ DNS เพื่อใช้ภายใน VM ด้วย
โปรดทราบว่า VM ที่ใช้บริดจ์เดียวกันสามารถสื่อสารกันได้ เว้นแต่คุณจะปิดกั้นการสื่อสารดังกล่าวด้วยวิธีบางอย่าง (เช่น ebtables)
เดอะ ค่าเริ่มต้น เส้นทาง (และเซิร์ฟเวอร์ DNS ที่จะใช้) จำเป็นเฉพาะในกรณีที่คุณต้องการให้ VM สามารถเข้าถึง "ภายนอก" ได้ หากคุณต้องการให้สามารถสื่อสารกับโฮสต์ VM ได้ คุณควรข้ามคำสั่งที่สองและหยุดอ่านได้ (อ่านดีๆ. ป.ล.)
จะเป็นการดีที่สุดที่จะกำหนดค่าเช่น dnsmasq บนโฮสต์เพื่อเป็นตัวส่งต่อ DNS หากคุณไม่ต้องการใช้เซิร์ฟเวอร์ DNS "สาธารณะ" เฉพาะใน VM แม้ว่าจะใช้ DNAT เพื่อส่งต่อคำขอ DNS ไปยังเช่น 192.168.1.1 ควรใช้ได้กับคนพื้นฐาน
จากนั้นคุณจะต้องเปิดใช้งานการส่งต่อ IP:
# sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
หากคุณต้องการหลีกเลี่ยงการส่งต่อ IP จาก/ไปยังอินเทอร์เฟซเครือข่ายบางอย่าง (เช่น. จูน0) เพื่อความปลอดภัย คุณจะต้องตั้งค่าไฟร์วอลล์ ตัวอย่างเช่น:
# iptables -A ไปข้างหน้า -i tun0 -j DROP
# iptables -A ไปข้างหน้า -o tun0 -j DROP
เนื่องจากคุณมีเส้นทางอุโมงค์ (VPN) ที่แทนที่เส้นทางจริง ค่าเริ่มต้น เส้นทางการรับส่งข้อมูลจาก VM ไปยังอินเทอร์เน็ตจะเข้าสู่อุโมงค์ด้วยเช่นกัน (เว้นแต่คุณจะเพิ่มกฎตัวอย่างด้านบน) หากคุณต้องการให้ทราฟฟิกดำเนินไปเช่น ผ่านเราเตอร์ของคุณ คุณจะต้องกำหนดเส้นทางตามนโยบาย ตัวอย่างเช่น:
# ip ru เพิ่มตารางการค้นหา iif natbr0 123
# ip r เพิ่ม 192.168.1.1 dev wlan0 ตาราง 123 # อาจเป็นทางเลือก
# ip r เพิ่มค่าเริ่มต้นผ่าน 192.168.1.1 ตาราง 123
คุณยังสามารถป้องกันไม่ให้ VM ของคุณเข้าถึงโฮสต์ LAN ของคุณได้:
# iptables -A ส่งต่อ -i natbr0 -d 192.168.1.0/24 -j DROP
ทำข้อยกเว้น (หมายเหตุ -ฉัน) หากคุณกำลังจะเปลี่ยนเส้นทางคำขอ DNS ไปยังเราเตอร์ของคุณ:
# iptables -I FORWARD -i natbr0 -d 192.168.1.1 -p tcp --dport 53 -j ยอมรับ
# iptables -I FORWARD -i natbr0 -d 192.168.1.1 -p udp --dport 53 -j ยอมรับ
สุดท้าย กำหนดค่า iptables เพื่อดำเนินการ SNAT แบบไดนามิก (ตามอินเทอร์เฟซขาออก) สำหรับซับเน็ต VM ของคุณ:
# iptables -t nat -A โพสต์ -s 10.0.2.0/24 -j MASQUERADE
โปรดทราบว่าสิ่งนี้ไม่ได้มีไว้เพื่อและจะไม่ป้องกันการรับส่งข้อมูลบางอย่างจาก "ภายนอก" (โฮสต์ LAN จริงหรืออินเทอร์เน็ตของคุณ ไม่นับโฮสต์ VM) เพื่อให้สามารถเข้าถึง VM ของคุณได้ เป็นเพียงการหยุดการสื่อสารเป็นผลข้างเคียงเมื่อที่อยู่ต้นทางของการตอบกลับทราฟฟิกจาก VM มีการเปลี่ยนแปลงก่อนที่จะส่งต่อออกไปสำหรับการแยกตัวที่เหมาะสม คุณจะต้องมีกฎที่เหมาะสม (เพิ่มเติม) ใน ซึ่งไปข้างหน้า โซ่. พิจารณาการตั้งค่า "stateful" ที่นั่นหากคุณต้องการ
นอกจากนี้ คุณสามารถเปลี่ยนเส้นทางคำขอ DNS ไปยังโฮสต์จาก VM ไปยังเราเตอร์ของคุณ:
iptables -t nat -A PREROUTING -d 10.0.2.1 -p udp --dport 53 -j DNAT --to-destination 192.168.1.1
iptables -t nat -A PREROUTING -d 10.0.2.1 -p tcp --dport 53 -j DNAT --to-destination 192.168.1.1
ซึ่งจะมากหรือน้อยให้คุณใช้ 10.0.2.1 เป็นเซิร์ฟเวอร์ DNS ใน VM
ป.ล. การจัดการทั้งหมดข้างต้น (ยกเว้นการสร้าง / เขียนถึง /etc/qemu/bridge.conf) มีความผันผวน เช่น จะหายไปเมื่อคุณรีบูต (เว้นแต่ distro ของคุณจะทำอะไรโง่ๆ) ฉันจะไม่ลงลึกถึงวิธีที่คุณจะทำให้สิ่งเหล่านี้คงอยู่ได้ เนื่องจากมีวิธี/แนวทางที่แตกต่างกันและอาจเป็นแบบเฉพาะเจาะจง