qemu-kvm guest OS poate accesa gazda folosind bridge, dar nu poate accesa alte dispozitive din aceeași rețea (Administrarea sistemului, Rețea, Virtualizare Kvm, Pod, Libvirt, Qemu)

ngj a intrebat.

Doresc să ruleze un oaspete qemu-kvm cu Debian 9 ca sistem de operare pe o gazdă Debian 10. Gazda este conectată la rețeaua locală, iar eu aș dori ca invitatul să fie „vizibil” în rețeaua locală ca și cum ar fi un dispozitiv obișnuit conectat direct la rețea. În acest scop, am configurat o punte numită br0 pe gazdă prin editarea /etc/network/interfaces după cum urmează:

auto lo
iface lo inet loopback

allow-hotplug eth0
auto eth0
iface eth0 inet manual
    up ifconfig eth0 promisc up
    down ifconfig eth0 promisc down

auto br0
iface br0 inet static
    hwaddress ether 08:60:6e:69:4a:b5
    address 192.168.1.11
    netmask 255.255.255.0
    gateway 192.168.1.1

    bridge_ports eth0
    bridge_stp on
    bridge_fd 0

Adresa MAC configurată pentru punte este aceeași cu cea a dispozitivului meu de eth0 interfață.

Rețeaua gazdei mele pare să funcționeze bine după această modificare.

Utilizarea sudo virsh edit debian9 (unde debian9 este numele oaspetelui), am editat interfața de rețea implicită după cum urmează:

    <interface type='bridge'>
      <mac address='52:54:00:bc:8c:97'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

În interiorul oaspetelui, am atribuit o adresă IP statică prin editarea /etc/network/interfaces după cum urmează, deoarece nu părea să primească o adresă IP folosind DHCP:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

allow-hotplug enp1s0
auto enp1s0
iface enp1s0 inet static
    address 192.168.1.13
    netmask 255.255.255.0
    gateway 192.168.1.1

Invitatul pare să apară corect în br0 bridge de pe gazdă atunci când fac sudo brctl show:

bridge name     bridge id               STP enabled     interfaces
br0             8000.08606e694ab5       yes             eth0
                                                        vnet0
docker0         8000.024202321e8f       no              veth7291e29
virbr0          8000.5254005aa541       yes             virbr0-nic

Acum, gazda se poate conecta corect la invitat (de exemplu, folosind ping sau ssh), iar invitatul se poate conecta corect la gazdă, dar alte dispozitive din aceeași rețea locală nu pot accesa invitatul, sau invers.

Bănuiesc că acest lucru trebuie să se datoreze unei probleme de firewall/rutare pe gazdă, dar nu sunt sigur cum să diagnostichez mai departe acest lucru. Următoarea este ieșirea din iptables -S de pe gazdă. Nu am configurat eu însumi nicio regulă iptables: majoritatea sunt legate de rețeaua NAT implicită a libvirt sau de o instalare docker pe gazdă:

-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-ISOLATION-STAGE-2
-N DOCKER-USER
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
-A DOCKER -d 172.17.0.1/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 8050 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN

Are cineva vreo sugestie cu privire la modul în care aș putea face ca oaspetele să devină „vizibil” în rețeaua locală?

Comentarii

  • Dacă doriți să știți de ce iptables (care lucrează la rutarea IP: nivelul 3) afectează un pod Ethernet (nivelul 2), verificați acolo: serverfault.com/questions/963759/… –  > Por A.B.
1 răspunsuri
Tero Kilkanen

Acest lucru se întâmplă deoarece FORWARD politica de lanț este DROP.

Ați putea folosi

iptables -I FORWARD -i br0 -j ACCEPT
iptables -I FORWARD -o br0 -j ACCEPT

pentru a accepta tot traficul redirecționat de la / către br0 interfață.

Acesta este, de asemenea, motivul pentru care clientul nu primește adresa prin DHCP. Pachetele DHCP de la client sunt eliminate de către FORWARD politică.

Comentarii

  • Acest lucru mi-a rezolvat problema; mulțumesc! –  > Por ngj.