Routing von Win7-Rechner 10.0.10.25 zur Nagios-VM 192.168.122.124 scheitert

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
hardstyle247
Beiträge: 8
Registriert: 13.12.2017 07:19:53

Re: Routing von Win7-Rechner 10.0.10.25 zur Nagios-VM 192.168.122.124 scheitert

Beitrag von hardstyle247 » 15.12.2017 08:34:57

Ich habe jetzt alle Interfaces und virtuelle Netzwerke im Virt-Manager entfernt.
Dann hab ich auf dem Gast das nervige NAT-Interface endlich wegbekommen(warum und wie das da überhaupt rein kam, weiß der Kuckuck), und zwar so:

Code: Alles auswählen

grep -wir 192.168.124.1 /*
Die Suche ergab einen Treffer in /etc/libvirt/qemu/default.xml
Also öffnete ich die Datei und siehe da, der Rotzlöffel virbr0 war da drin!
Die Einträge habe ich eiskalt gelöscht, sodass die default.xml jetzt nur noch Kommentare beinhaltet.
Nach

Code: Alles auswählen

systemctl restart libvirtd.service && systemctl restart network
spuckte aber immer noch den vibr0 und seinen Gefolgen virbr0-nic aus...
Nach dem

Code: Alles auswählen

reboot
und erneutem waren die beiden Übeltäter endlich weg!

Jetzt schalte ich die VM ab, schließe den Virt-Manager auf dem Debianhost und nehme die Schritte laut Ubuntu-Anleitung vor, welche mir @DynaBlaster freundlicherweise gestern Abend noch zur Verfügung stellte.
https://wiki.ubuntu.com/KvmWithBridge

hardstyle247
Beiträge: 8
Registriert: 13.12.2017 07:19:53

Re: Routing von Win7-Rechner 10.0.10.25 zur Nagios-VM 192.168.122.124 scheitert

Beitrag von hardstyle247 » 15.12.2017 10:19:52

Ok, laut Beschreibung der Anleitung hat alles soweit funktioniert. Internetzugang ist zwar auf der VM noch nicht möglich, aber das liegt daran, dass die VM jetzt eine neue IP (10.0.12.34) erhalten hat und die Firewall diese erst noch fürs Internet freischalten müsste.

Aufpassen muss man nur noch bei den Konfigdateien. Die sind ja nicht zwangsweise im Ubuntu/Debian-Format.
Unter Centos7 müsste man zu /etc/sysconfig/network-scripts/ifcfg-eth0 gehen und dort Folgendes eintragen (in meinem Beispiel 10.0.0.0/16-Netzwerk):

Code: Alles auswählen

NAME=eth0
DEVICE=eth0
TYPE=Ethernet
BOOTPROTO=static
IPADDR=10.0.12.34
PREFIX=16
NETWORK=10.0.0.0
BROADCAST=10.0.255.255
GATEWAY=10.0.18.1
DNS1=10.0.10.120
DNS2=8.8.8.8
ONBOOT=yes
Hätte das Ganze jetzt auch funktioniert, wenn ich anstatt 10.0.0.0-Netzwerk 192.168.122.0-Netzwerk eingetragen hätte? Warum nicht?

Benutzeravatar
DynaBlaster
Beiträge: 958
Registriert: 25.03.2004 18:18:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DF0://dynablaster.adf

Re: Routing von Win7-Rechner 10.0.10.25 zur Nagios-VM 192.168.122.124 scheitert

Beitrag von DynaBlaster » 16.12.2017 17:59:07

So ohne weiteres häte das vermutlich nicht dem Netz 192.168.122.124 geklappt. Auf dem Debian-Host gibts ja durch das Löschen der virbr0 keine Netzwerkkarte mehr aus dem 192.168.122.0/24. Folglich wäre deine Route aus dem 10.0.0.0-Netz über den Debian-Host ins Leere gelaufen. Der hätte da zwar Pakte für empfangen, hätte die aber nirgendwo hinleiten können.

Wenn es unbedingt ein getrenntes Netz sein soll, würde ich eine 2. Netzwerkkart im Debian-Host nutzen. Entweder physikalisch oder durch eine weitere IP auf eth0. Und dann die KVM-Bridge auf dieses Interface statt eth0 im 10.10.10.0-Netz binden.

Dein ursprüngliches Problem mit dem "Pingen" lag einfach daran, das du von dem Windows-7-Rechner wegen der Route ins 192.168.122.0-Netz zwar die VM per Ping erreichen konntest (hättest mit tcpdump eigentlich solche Ping-Requests sehen müssen), der Debian-Host bzw. die virbr0-Konfiguration dann die Antwortpakete zurück ins 10.0.0.0-Netz "ge-natted" hat. Auf deinem Windows-7-Rechner sind dann als auf einmal Ping-Antworten von 10.10.12.33 angekommen die er aber eigentlich von 192.168.122.124 zurück erwartet hat.

Bei dem Pingen von 192.168.122.124 zu 10.0.0.25 gab es dieses Problem nicht, weil der Debian-Host das initiale Paket gleich auf 10.0.12.33 umgebaut hat, dein Windows 7 dann brav auf den Request geantwortet hat (aus Sicht des Windows 7 kommt die Ping-Anfrage von 10.0.12.33, nicht von 192.168.122.124), und das Antwort-Paket hat der Debian-Host dann wieder zurück-gebaut und an die 192.168.122.124 geschickt

Antworten