VM ของผู้เยี่ยมชมสามารถเข้าถึงโฮสต์บนเครือข่ายด้วยการเชื่อมต่อเครือข่ายแบบบริดจ์ได้อย่างไร

หลังจากถาม คำถามนี้ ฉันสามารถกำหนดค่าเครื่องเสมือนของฉันให้เชื่อมต่อโดยตรงกับ LAN สิ่งนี้ทำงานได้ตามที่ตั้งใจไว้ ยกเว้นว่า VM ของผู้เยี่ยมชมไม่สามารถสื่อสารกับโฮสต์ได้

เซิร์ฟเวอร์อูบุนตู 20.04.03 LTS

นี่คือ netplan โฮสต์ของฉัน:

เครือข่าย:
  อีเธอร์เน็ต:
    enp3s0:
      dhcp4: จริง
      ตัวเลือก: จริง
    enp4s0:
      dhcp4: เท็จ
      dhcp6: เท็จ
  สะพาน:
    br0:
      อินเทอร์เฟซ:
      -enp4s0
      ที่อยู่:
      - 192.168.1.200/24
      เกตเวย์ 4: 192.168.1.1
      เนมเซิร์ฟเวอร์:
        ที่อยู่:
        - 1.1.1.1
        - 1.0.0.1
        - 8.8.8.8
        - 8.8.4.4
        ค้นหา: []
      พารามิเตอร์:
        ขั้นตอน: จริง
      dhcp4: ไม่
      dhcp6: ไม่
  vlans:
    vlan15:
      ยอมรับรา: ไม่
      รหัส: 15
      ลิงค์: enp4s0
  รุ่น: 2

และนี่คือการกำหนดค่าเครือข่าย vm (virsh net-แก้ไขค่าเริ่มต้น)

<network>
  <name>default</name>
  <uuid>e0235996-534d-49c8-94d6-f213acd1552e</uuid>
  <forward mode='bridge'/>
  <bridge name='br0'/>
</network>

ในขณะที่ Guest VM ปรากฏบน LAN และมีการเข้าถึงจากภายนอก และสามารถเข้าถึงได้จากคอมพิวเตอร์จริงเครื่องอื่นๆ บนเครือข่าย แต่ VM ของแขกจะไม่สามารถเข้าถึงโฮสต์ได้

นี่คือเอาต์พุตจากพรอมต์คำสั่ง Windows Server ใน VM สำหรับ ping และ tracert: (โฮสต์คือ 192.168.1.200 แขกคือ 192.168.1.33 ซึ่งได้รับจาก DHCP ของเราเตอร์บน LAN)

C:\Users\Administrator>ping 192.168.1.200

ส่ง Ping 192.168.1.200 พร้อมข้อมูล 32 ไบต์:
ตอบกลับจาก 192.168.1.33: ไม่สามารถเข้าถึงโฮสต์ปลายทางได้

สถิติ Ping สำหรับ 192.168.1.200:
    แพ็กเก็ต: ส่ง = 1 ได้รับ = 1 สูญหาย = 0 (สูญเสีย 0%)

C:\Users\Administrator>tracert 192.168.1.200


ติดตามเส้นทาง 192.168.1.200 สูงสุด 30 กระโดด

  1 SVR-BACKUP [192.168.1.33] รายงาน: ไม่สามารถเข้าถึงโฮสต์ปลายทางได้

การติดตามเสร็จสมบูรณ์

ฉันต้องทำอะไรอีกเพื่อให้การเชื่อมต่อเสร็จสมบูรณ์ เพื่อให้ VM ของผู้เยี่ยมชมสามารถสื่อสารกับโฮสต์ได้

แก้ไข: ตามที่ร้องขอ นี่คือผลลัพธ์ของ sudo iptables -xvnL

Chain INPUT (นโยบายยอมรับแพ็กเก็ต 195866, 25432549 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง

เชน FORWARD (นโยบาย DROP 0 แพ็กเก็ต 0 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
       0 0 DOCKER-USER ทั้งหมด -- * * 0.0.0.0/0 0.0.0.0/0
       0 0 DOCKER-ISOLATION-STAGE-1 ทั้งหมด -- * * 0.0.0.0/0 0.0.0.0/0
       0 0 ยอมรับทั้งหมด -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate ที่เกี่ยวข้อง ก่อตั้ง
       0 0 นักเทียบท่าทั้งหมด -- * นักเทียบท่า0 0.0.0.0/0 0.0.0.0/0
       0 0 ยอมรับทั้งหมด -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
       0 0 ยอมรับทั้งหมด -- นักเทียบท่า0 นักเทียบท่า0 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (นโยบายยอมรับแพ็กเก็ต 252563, 775126408 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง

Chain DOCKER (อ้างอิง 1 รายการ)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
       0 0 ยอมรับ tcp -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:3690

Chain DOCKER-ISOLATION-STAGE-1 (อ้างอิง 1 รายการ)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
       0 0 DOCKER-ISOLATION-STAGE-2 ทั้งหมด -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
       0 0 คืนทั้งหมด -- * * 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (อ้างอิง 1 รายการ)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
       0 0 DROP ทั้งหมด -- * นักเทียบท่า0 0.0.0.0/0 0.0.0.0/0
       0 0 คืนทั้งหมด -- * * 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-USER (อ้างอิง 1 รายการ)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
       0 0 คืนทั้งหมด -- * * 0.0.0.0/0 0.0.0.0/0

และ sudo iptables -t แนท -xvnL

เชน PREROUTING (นโยบายยอมรับแพ็กเก็ต 39583, 13257450 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
    8156 2476484 DOCKER ทั้งหมด -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE ตรงกับ dst-type LOCAL

Chain INPUT (นโยบายยอมรับแพ็กเก็ต 8712, 2524965 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง

Chain OUTPUT (นโยบายยอมรับแพ็กเก็ต 10911, 606007 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
       6 1768 DOCKER ทั้งหมด -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE ตรงกับ dst-type LOCAL

Chain POSTROUTING (นโยบายยอมรับแพ็กเก็ต 10911, 606007 ไบต์)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
       0 0 สวมหน้ากากทั้งหมด -- * !docker0 172.17.0.0/16 0.0.0.0/0
       0 0 สวมหน้ากาก tcp -- * * 172.17.0.2 172.17.0.2 tcp dpt:3690

Chain DOCKER (ข้อมูลอ้างอิง 2 รายการ)
    pkts bytes target prot เลือกใช้ปลายทางต้นทาง
       0 0 ส่งคืนทั้งหมด -- นักเทียบท่า0 * 0.0.0.0/0 0.0.0.0/0
       0 0 DNAT tcp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3690 ถึง:172.17.0.2:3690

ปัญหาคือ netfilter

กำลังติดตาม คำแนะนำที่นี่ ฉันปิดการใช้งาน netfilter สำหรับบริดจ์และสามารถรับการสื่อสารเครือข่ายที่เหมาะสมระหว่าง VM, LAN และโฮสต์ ส่วนที่เกี่ยวข้อง:

เพื่อเหตุผลด้านประสิทธิภาพและความปลอดภัย ให้ปิดใช้ netfilter สำหรับบริดจ์ สร้าง /etc/sysctl.d/bridge.conf ด้วยเนื้อหาเหล่านี้:

net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-iptables=0
net.bridge.bridge-nf-call-arptables=0

สร้าง /etc/udev/rules.d/99-bridge.rules โดยมีเนื้อหาดังต่อไปนี้ กฎ udev นี้ใช้การตั้งค่า sysctl ด้านบนเมื่อโหลดโมดูลบริดจ์ (หากใช้ Linux kernel 3.18 หรือใหม่กว่า ให้เปลี่ยน KERNEL=="bridge" เป็น KERNEL="br_netfilter")

ACTION=="เพิ่ม", SUBSYSTEM=="โมดูล", KERNEL=="บริดจ์", RUN+="/sbin/sysctl -p /etc/sysctl.d/bridge.conf"

หลังจากทำเช่นนั้น ปัญหาทั้งหมดของฉันก็หมดไป