14
KVM - Bridge Interface , kein VM Zugriff
HAllo zusammen,
ich jage leider ein kleinen Rätsel nach.
Folgendes:
Nachdem bei mienem Dedi Server der Raid Controller kaputt gegangen ist lief erstmal nichts mehr.
MEin PRovider hat mir dann ein Ersatz System zur verfügung gestellt.
Der Server lief bisher immer auf Ubuntu 16.04 LTS.
Also dachte ich mir, warum nicht gleich auf 18.04 gehen. Das war ein Fehler... Dachte ich.
ICh habe den Host installiert und eine neue Brücke gebaut. Das lief nicht sauber, da Netplan irgendwie voller Bugs ist.
Manuell deinstalliert und Ifupdown installiert lief dann auch die Brücke.
MEine zweite IP Adresse habe ich dann auch bekommen. Allerdings bekam ich über die VM keinen Internet Zugriff, obwohl die VM über die Brücke angesteuert wurde und die Feste IP eingetragen ist.
ICh hatte den Fehler beim PRovider gesehen , was aber niht der Fall war. Füge ich die zweite IP Adresse dem Host System als zweite Adresse hinzu, so funktioniert es.
Den Host habe ich dann auf Debian 9 neu installiert.
Dort gibt es ja noch ifupdown vorinstalliert.
Die Brücke lief dort von Anfang an einwandfrei.
Allerding auch hier das gleiche Phänomen.
Die VM, bekam keinen Zugriff ins Netz , mit dem Host als zweiter Adresse klappts.
Ich vermute entweder MAC Filter oder das interne Routing klappt nicht. Der Provider sagt alles gut.
Die zweite Adresse ist eine Failover Adresse also insofern nicht an eine MAC gebunden oder?
Pinge ich von der VM nach draussen kann ich den Ping auf dem Host sehen wie er die Brücke passiert.
Insofern denke ich eher ein Routing problem des Providers.
Wie bekomme ich raus, es hängt ?
/etc/network/interfaces ( vom Host )
auto lo
iface lo inet loopback
auto br1
iface br1 inet static
address X.X.X.X/24
gateway X.X.X.1
dns-nameservers 1.1.1.1
bridge_ports eno1
bridge_stp on
bridge_fd 0.0
/etc/network/interfaces ( VM)
auto lo
iface lo inet loopback
auto ens3
iface ens3 inet static
address Y.Y.Y.Y/32
gateway X.X.X.1 ( das gleiche wie vom Host Server)
dns-nameservers 1.1.1.1
Vielen Dank.
Christian
ich jage leider ein kleinen Rätsel nach.
Folgendes:
Nachdem bei mienem Dedi Server der Raid Controller kaputt gegangen ist lief erstmal nichts mehr.
MEin PRovider hat mir dann ein Ersatz System zur verfügung gestellt.
Der Server lief bisher immer auf Ubuntu 16.04 LTS.
Also dachte ich mir, warum nicht gleich auf 18.04 gehen. Das war ein Fehler... Dachte ich.
ICh habe den Host installiert und eine neue Brücke gebaut. Das lief nicht sauber, da Netplan irgendwie voller Bugs ist.
Manuell deinstalliert und Ifupdown installiert lief dann auch die Brücke.
MEine zweite IP Adresse habe ich dann auch bekommen. Allerdings bekam ich über die VM keinen Internet Zugriff, obwohl die VM über die Brücke angesteuert wurde und die Feste IP eingetragen ist.
ICh hatte den Fehler beim PRovider gesehen , was aber niht der Fall war. Füge ich die zweite IP Adresse dem Host System als zweite Adresse hinzu, so funktioniert es.
Den Host habe ich dann auf Debian 9 neu installiert.
Dort gibt es ja noch ifupdown vorinstalliert.
Die Brücke lief dort von Anfang an einwandfrei.
Allerding auch hier das gleiche Phänomen.
Die VM, bekam keinen Zugriff ins Netz , mit dem Host als zweiter Adresse klappts.
Ich vermute entweder MAC Filter oder das interne Routing klappt nicht. Der Provider sagt alles gut.
Die zweite Adresse ist eine Failover Adresse also insofern nicht an eine MAC gebunden oder?
Pinge ich von der VM nach draussen kann ich den Ping auf dem Host sehen wie er die Brücke passiert.
Insofern denke ich eher ein Routing problem des Providers.
Wie bekomme ich raus, es hängt ?
/etc/network/interfaces ( vom Host )
auto lo
iface lo inet loopback
- The primary network interface
auto br1
iface br1 inet static
address X.X.X.X/24
gateway X.X.X.1
dns-nameservers 1.1.1.1
bridge_ports eno1
bridge_stp on
bridge_fd 0.0
/etc/network/interfaces ( VM)
auto lo
iface lo inet loopback
- The primary network interface
auto ens3
iface ens3 inet static
address Y.Y.Y.Y/32
gateway X.X.X.1 ( das gleiche wie vom Host Server)
dns-nameservers 1.1.1.1
Vielen Dank.
Christian
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 441401
Url: https://administrator.de/contentid/441401
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
14 Kommentare
Neuester Kommentar
Würde darauf tippen den Provider zu kontaktieren, wenn er das auch nicht hinbekommt brauchst du Hilfe (oder der Provider) und/oder einen anderen Provider.
VG
VG
Und Spanning Tree auf dem Host Interface zu aktivieren ist nicht ganz unproblematisch. Du hast keinerlei Ahnung welches STP Protokoll der Hoster extern verwendet. Hat er Cisco im Umfeld kommt es zum Chaos, denn die sprechen PVSTP was inkompatibel zu deinem STP ist und der externe Switch setzt den Port dann in Error Disable.
Sowas unabgestimmt mit dem Provider zu machen ist gefährlich. Kollege @certifiedit.net hat da Recht.
Sowas unabgestimmt mit dem Provider zu machen ist gefährlich. Kollege @certifiedit.net hat da Recht.
@aqui , stmmt, STP ist an. ICh hatte gedacht ich hätte es deaktiviert.
Danke , das hatte ich übersehen.
JA, den PRoider habe ich ein weiteres Ticket zukommen lassen.
Mal schauen was ich da für eine Antwort bekomme.
Vielen Dank euch erstmal.
STP mache ich mal aus.
Danke , das hatte ich übersehen.
JA, den PRoider habe ich ein weiteres Ticket zukommen lassen.
Mal schauen was ich da für eine Antwort bekomme.
Vielen Dank euch erstmal.
STP mache ich mal aus.
Moin,
Erdtmal stp aus der C8nfig rausnehmen! Wofür sooll das in Deuier Ko stellation denn gut sein?
Danach auf dem externen interface sniffen, was durchgeht, wenn Du aus der VM heraus einen tracerout nach draußen machst
lks
Erdtmal stp aus der C8nfig rausnehmen! Wofür sooll das in Deuier Ko stellation denn gut sein?
Danach auf dem externen interface sniffen, was durchgeht, wenn Du aus der VM heraus einen tracerout nach draußen machst
lks
Guten Abend,
laut Support funktioniert die IP PRoblemlos.
Es soll also an meiner Bridge liegen.
STP habe ich off gestellt. - DAs hat er automatisch mit eingrtragen, als ich mittels Virt-Manager die Brcke gebaut habe.
Nun, ein traceroute ergibt nichts. Scheint als käme ich nicht raus.
Pinge ich von der VM nach extern und schaue auf dem Host mittels tcpdump nach icmp Paketen, so sehe ich dies.
Scheint als verlässt der das Interface oder?
163, das ist meine. Ich wollte das eigentlich übermalen. ISt aber der Übersichtlichkeit halber.
laut Support funktioniert die IP PRoblemlos.
Es soll also an meiner Bridge liegen.
STP habe ich off gestellt. - DAs hat er automatisch mit eingrtragen, als ich mittels Virt-Manager die Brcke gebaut habe.
Nun, ein traceroute ergibt nichts. Scheint als käme ich nicht raus.
Pinge ich von der VM nach extern und schaue auf dem Host mittels tcpdump nach icmp Paketen, so sehe ich dies.
Scheint als verlässt der das Interface oder?
163, das ist meine. Ich wollte das eigentlich übermalen. ISt aber der Übersichtlichkeit halber.
Scheint als käme ich nicht raus.
Was dann auch klar zeigt das die Bridge NICHT funktioniert !Wie grundsätzlich ein Bridge Interface einzurichten ist bei unixoiden OS kannst du hier nachlesen:
Netzwerk Management Server mit Raspberry Pi
Sorry,
das verstehe ich nicht.
ICh habe genauso die Brücke gebaut.
Ebenfalls wie es in einem anderen Tutorial beschrieben war.
Dort sollte ich die /etc/network/interfaces leer lassen und unter /etc/network/interfaces.d/br0 das ganze reinschreiben.
Anschließend erkennt virt-manager die brücke mehr.
Dennoch erhalte ich keinen Zugriff mit den VMs.
Unter Ubuntu 16.04 gabs da nie Probleme.
Gibts eine Möglichkeit herauszufinden, wo es häng
Sonst gehe ich einfach auf 16.04 zurück.
das verstehe ich nicht.
ICh habe genauso die Brücke gebaut.
Ebenfalls wie es in einem anderen Tutorial beschrieben war.
Dort sollte ich die /etc/network/interfaces leer lassen und unter /etc/network/interfaces.d/br0 das ganze reinschreiben.
Anschließend erkennt virt-manager die brücke mehr.
Dennoch erhalte ich keinen Zugriff mit den VMs.
Unter Ubuntu 16.04 gabs da nie Probleme.
Gibts eine Möglichkeit herauszufinden, wo es häng
Sonst gehe ich einfach auf 16.04 zurück.
Kann es schlicht sein, dass dein Hoster fremde MAC-Adressen ingress am Switchport filtert und die MAC-Adresse deiner VM noch erlaubt werden muss?
Zitat von @LordGurke:
Kann es schlicht sein, dass dein Hoster fremde MAC-Adressen ingress am Switchport filtert und die MAC-Adresse deiner VM noch erlaubt werden muss?
Kann es schlicht sein, dass dein Hoster fremde MAC-Adressen ingress am Switchport filtert und die MAC-Adresse deiner VM noch erlaubt werden muss?
Oder daß vielleicht noch andere Kunden kvm nutzen und daher die MAC-Adresse schon "auf einem anderen Porr" des Providerswitches benutzt wird.
Ich würde mal eine zufällig gewählte MAC-Adresse benutzen.
lks
Diese Idee hatte ich auch schon.
Auf diese Frage ist der Support erst garnicht eingegangen.
Ich tippe ja immer noch auf den Mac filter.
Eine zufällige MAc Adresse ergab leider keine Besserung.
ICh werde mal auf 16.04 LTS zurück gehen.
VG
Christian
Auf diese Frage ist der Support erst garnicht eingegangen.
Ich tippe ja immer noch auf den Mac filter.
Eine zufällige MAc Adresse ergab leider keine Besserung.
ICh werde mal auf 16.04 LTS zurück gehen.
VG
Christian
Alternativ kannst du auch versuchen, ein Routed Setup auzusetzen, sofern die zweite IP geroutet wird.
Auf dem Host musst du dafür das IP-Forwarding per sysctl auf eno0 deines Hosts aktivieren.
Dann legst du eine statische Route an, die auf das Interface deiner VM zeigt:
A.B.C.D ist deine zusätzliche IP-Adresse, die für die VM genutzt werden soll.
br0 muss natürlich der Name deiner Bridge sein, an der die VM hängt.
Deiner VM konfigurierst du dann die IP des Hosts, die er auf ens0 hat, als Default-Gateway.
Dann sieht dein Hoster für jedes Paket die MAC-Adresse deines Hosts (denn er ist ja der Router) und das Problem sollte weg sein.
Auf dem Host musst du dafür das IP-Forwarding per sysctl auf eno0 deines Hosts aktivieren.
Dann legst du eine statische Route an, die auf das Interface deiner VM zeigt:
ip -4 route add A.B.C.D/32 dev br0br0 muss natürlich der Name deiner Bridge sein, an der die VM hängt.
Deiner VM konfigurierst du dann die IP des Hosts, die er auf ens0 hat, als Default-Gateway.
Dann sieht dein Hoster für jedes Paket die MAC-Adresse deines Hosts (denn er ist ja der Router) und das Problem sollte weg sein.
Interessant,
vielen Dank für den Tipp.
Jetzt kann ich zumindest vom Host in die VM Pingen. Klar, wegen der Static Route.
Also die Brücke scheint zu laufen
Hmmmm sehr merkwürdig.
vielen Dank für den Tipp.
Jetzt kann ich zumindest vom Host in die VM Pingen. Klar, wegen der Static Route.
Also die Brücke scheint zu laufen
Hmmmm sehr merkwürdig.
IP-Forwarding für die Interfaces aktiviert?
Und ggf. Forwarding in der Firewall erlaubt?
Und ggf. Forwarding in der Firewall erlaubt?
Ja genau.
ICh habe den Host jetzt auf 16.04 neu installiert.
Ach nein , was eine Überraschung. Auf einmal steht in der Verwaltungskonsole des Dedi Servers für die zweite IP Adresse eine MAC Adresse drin.
Und siehe da, es geht dann. Wie überraschend. Echt. Ehrlich, eine menge Arbeit ersparen können.
Ich werde mal fragen warum die nicht direkt mit dabei stand. DAs hätte mir eine menge Stress erspart.
Vielen Dank an euch.
Es geht.... Endlich .
Netplan ist dennoch für mich gestorben.
Sowas unsauberes.
ICh habe den Host jetzt auf 16.04 neu installiert.
Ach nein , was eine Überraschung. Auf einmal steht in der Verwaltungskonsole des Dedi Servers für die zweite IP Adresse eine MAC Adresse drin.
Und siehe da, es geht dann. Wie überraschend. Echt. Ehrlich, eine menge Arbeit ersparen können.
Ich werde mal fragen warum die nicht direkt mit dabei stand. DAs hätte mir eine menge Stress erspart.
Vielen Dank an euch.
Es geht.... Endlich .
Netplan ist dennoch für mich gestorben.
Sowas unsauberes.
