Puncte:0

Gazda nu are acces la internet atunci când mașinile virtuale rulează

drapel eg

Cum configurez rețeaua, astfel încât atât gazda, cât și VM-urile să se poată conecta la internet?

Am configurat un server pentru a găzdui mai multe mașini virtuale folosind KVM. Este destinat să deservească o bibliotecă de cărți descărcabile pentru nevăzători (mai multe detalii mai jos).

Starea actuală este rezultatul încercării de a urma o serie de tutoriale despre crearea de rețele pentru mașini virtuale. Scopul este de a avea acces la internet atât de la gazdă, cât și de la VM.

Atât gazda, cât și oaspeții rulează Debian 10. Placa de rețea este configurată ca punte de rețea br0 cu o adresă statică („interfețe” vezi mai jos).

În prezent, VM-urile sunt pornite manual folosind virsh. Când nu rulează mașini virtuale, gazda are acces la internet (de exemplu ping debian.org, get update, wget ...).

Odată ce un VM este pornit, acesta are acces la internet folosind br0. Fiecare VM are o adresă statică. Gazda pierde apoi accesul la internet. Ping-ul este posibil pentru alte mașini din rețeaua locală, precum și pentru router, dar nu dincolo (fie ping un nume de domeniu sau o adresă IP).

Atât gazda, cât și VM-urile pot fi accesate folosind ssh de la alte mașini locale.

Odată ce VM-urile sunt setate la pornire automată, nu mai este posibilă actualizarea fără a opri manual VM-urile, de asemenea, gazda nu se conectează la un server de timp. În plus, ip arată pachetele abandonate.

Toate acestea sunt cel mai probabil rezultatul înțelegerii mele foarte limitate despre rețele și poduri în special. Sunt cel mai recunoscător pentru orice ajutor!

Iată câteva informații suplimentare.

Scop
Un VM ar trebui să servească utilizatorii din afara rețelei locale, folosind un server web NginX. Se ocupă de descărcarea cărților extrase de utilizatori care sunt stocate pe o unitate locală.

Al doilea VM oferă un server de baze de date PostgreSQL, care poate fi accesat numai de la stațiile de lucru locale, unde sunt administrați utilizatorii bibliotecii și împrumuturile.

Gazda ar trebui să fie accesibilă prin ssh din rețeaua locală. Accesul la internet este necesar pentru conectarea la un server de timp și pentru a putea menține software-ul la zi.

PC
Placa de baza: MSI MPG B550 GAMING PLUS
CPU: AMD Ryzen⢠7 3700X
RAM: Kit Corsair DIMM 32 GB DDR4-3200
HD: Samsung 980 PRO 1 TB, SSD
Placa grafica: MSI GeForce GT 710 1GD3H LP

OS
uname -r

4.19.0-17-amd64

lsb_release -a

Nu sunt disponibile module LSB.
ID distribuitor: Debian
Descriere: Debian GNU/Linux 10 (buster)
Lansare: 10
Nume de cod: buster

Reţea
Până când este mutat în bibliotecă, serverul este la biroul meu de acasă conectat la un router AVM Fritz!Box 7490.

ls /sys/class/net/

br0 enp42s0 lo

cat /etc/network/interfaces

# Acest fișier descrie interfețele de rețea disponibile pe sistemul dumneavoastră
# și cum să le activați. Pentru mai multe informații, consultați interfețe(5).

sursa /etc/network/interfaces.d/*

# Interfața de rețea loopback
auto lo
iface lo inet loopback

# Interfața de rețea principală
iface enp42s0 inet manual

# Setările podului br0
auto br0
iface br0 inet static
   bridge_ports enp42s0
      adresa 192.168.10.50
      rețeaua 192.168.10.0
      difuzat 192.168.10.255
      mască de rețea 255.255.255.0
      gateway 192.168.10.1
      servere de nume dns 94.247.43.254 194.36.144.87 192.168.10.1
      bridge_stp off
      bridge_fd 0
      bridge_maxwait 0

(Machinele virtuale au adrese 192.168.10.51, 192.168.10.52)

ip -s link arată dev br0

3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT grup implicit qlen 1000
    link/ether 2c:f0:5d:e4:36:d5 brd ff:ff:ff:ff:ff:ff
    RX: octeți pachete erori scăpat depășire mcast   
    206602 2218 0 1130 0 177     
    TX: octeți pachete erori eliminate collsns de transportator 
    99981 593 0 0 0 0       

cat /proc/net/dev

  Inter-| Primește | Transmite
   fata | octeți pachete erori drop fifo frame comprimat multicast| octeți pachete erori drop fifo colls purtător comprimat
    br0: 210026 2268 0 1138 0 0 0 177 103273 615 0 0 0 0 0 0
  vnet0: 1384510 18903 0 0 0 0 0 0 58389276 40523 0 0 0 0 0 0
     lo: 1840 26 0 0 0 0 0 0 1840 26 0 0 0 0 0 0
enp42s0: 58580534 42260 0 38 0 0 0 289 1467123 19358 0 0 0 0 0 0

traseul -n

Kernel-IP-Routentabelle
Ziel Router Genmask Steaguri Metric Ref Utilizare Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 vnet0
0.0.0.0 192.168.10.1 0.0.0.0 UG 0 0 0 br0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 vnet0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br0

ls /sys/class/net/

br0 enp42s0 lo vnet0
Puncte:1
drapel cz

Podul tău scapă jumătate din pachetele primite! Uimitor că aveți orice conexiune.

Văd doar o problemă evidentă cu configurația dvs. și, din păcate, este o versiune implicită Debian prost aleasă:

      bridge_stp off

STP ar trebui să fie activat pentru orice punte virtuală utilizată de libvirt sau pentru VM. Este mult prea ușor să construiți o buclă fie accidental, fie intenționat. Ceea ce înseamnă că trebuie să fie și la Fritz!Box-ul tău, dar cel mai probabil este deja. Același lucru pentru orice comutator la care îl conectați la bibliotecă, dar din nou, cel mai probabil, are deja STP activat.

StefanF avatar
drapel eg
Mulțumiri! Voi schimba asta cât de curând și voi raporta înapoi. :-)
StefanF avatar
drapel eg
Activarea bridge_stp nu a schimbat comportamentul. Voi încerca să aflu mai întâi dacă problema este legată de routerul meu. La un moment dat, Fritz!Boxes avea STP dezactivat în mod implicit. Din păcate, producătorul a dezactivat accesul ssh în sistemul său de operare, iar GUI-ul nu îl arată, din câte văd. Poate că suportul AVM poate clarifica.Vă mulțumim din nou pentru timpul acordat și pentru că ați subliniat această problemă!
Puncte:0
drapel eg
  1. STP: producătorul Fritz!Boxes a confirmat că nu acceptă STP.

  2. Pachete aruncate: Voi ignora asta pentru moment, deoarece două laptopuri Linux (Ubuntu Mate, Lubuntu) arată aprox. aceeași cantitate de pachete abandonate, fără a avea probleme evidente de conectivitate.

  3. Lipsa accesului la internet a gazdei pare să fi fost legat de connman setarea adresei IP a rețelelor virtuale prin DHCP.

Primul indiciu a fost când m-am uitat la rezultatul ping debian.org după a fost pornit un VM:

PING debian.org (130.89.148.77) 56(84) octeți de date.
De la blibu.local (169.254.210.100) icmp_seq=1 Gazdă destinație inaccesabilă

ip a a dat următoarea ieșire (fragment)

3: br0: ... inet 192.168.10.50/24
4: vnet0: ... inet 169.254.210.100/16

Deci ping folosea vnet0 cu o adresă diferită de spațiul de adrese din rețeaua locală.

După ce am încercat o serie de abordări diferite (a doua NIC, macvtap) cu același rezultat, mi-am amintit în sfârșit să adaug toate rețelele virtuale în /etc/connman/main.conf:

NetworkInterfaceBlacklist = vmnet,vboxnet,virbr,ifb,ve-,vb-,br,enp42s0,eno1,vnet0,vnet1,vnet2

Aparent, fiecare VM care rulează adaugă o rețea virtuală.

Cel mai probabil, aceasta nu este cea mai elegantă sau eficientă soluție și voi aprecia foarte mult orice ajutor în îmbunătățirea configurației mele.

Totuși, atât gazda, cât și toate VM-urile au acum acces la internet și pot obține actualizări de software. :-)

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.