[GELÖST] Externe IP-Adresse funktioniert nach Systemupgrade nicht mehr

[mat6937]

Ich möchte zusätzlich erwähnen, dass das Problem mit der IP-Adresse nach dem Bookworm-Systemupgrade aufgetreten ist. Diese interfaces-Datei mit diesen zwei Netzwerken besteht seit zwei Jahren und funktionierte.
...
. Und wie gesagt, das Ganze funktionierte, die anderen VM's haben die gleichen interfaces, abgesehen von den individuellen Host-IPs.

Versuch mal nur als Test, mit "auto" statt mit "allow-hotplug", denn das ist ja eine feste IP-Adresse mit permanenter Verbindung, oder?

Code: Alles auswählen

# The primary network interface 
## allow-hotplug enp1s0 
auto enp1s0
iface enp1s0 inet static 
       address 176.59.170.141 
       netmask 255.255.255.255 
       pointopoint 78.6.75.155 
       gateway 78.6.75.155 
       dns-nameservers 192.168.1.1 213.133.100.100 9.9.9.9 
       dns-search example.com 

BTW: Auch wenn es "funktioniert" und Du zwei default route (warum auch immer) hast, kannst Du mit Hilfe der metric "regeln/beeinflussen", welche default route benutzt werden soll.

[bluestar]

Warum tritt dann das Problem nur dort auf und nicht bei den 8 anderen VM's?

Es hängt auf jeden Fall an der Reihenfolge der Initialisierung der Netzwerkschnittstellen, bei dir kommt enp7s0 vor enp1s0 hoch und damit die falsche Default-Route.

Noch mal eine Frage an dich: Wozu brauchst du die Default-Route auf 192.168.1.1 überhaupt, wenn an enp7s0 nur das Netzwerk 192.168.1.0/24 dranhängt, dann brauchst du da keinerlei Default-Gateway.

[mat6937]

Es hängt auf jeden Fall an der Reihenfolge der Initialisierung der Netzwerkschnittstellen, bei dir kommt enp7s0 vor enp1s0 hoch und damit die falsche Default-Route.

In der Ausgabe von "ip a" des TE sieht man, dass das enp1s0-Interface den Interface-Index 2 hat und somit schon vor dem enp7s0-Interface (Interface-Index 3) hoch kommt. M. E. kann es aber sein, dass zu dem Zeitpunkt, das gateway (device, IP) für diese default route, noch nicht erreichbar ist und deshalb die default route nicht zustande kommt.
Ob und welchen Einfluss (in bookworm) das "allow-hotplug" hat (wird zu schnell aufgegeben?), weiß ich nicht und könnte evtl. getestet werden.

[mat6937]

... funktionierte, die anderen VM's haben die gleichen interfaces, abgesehen von den individuellen Host-IPs.

Welches OS/OS-Version haben die anderen VM's?

[bluestar]

Warum tritt dann das Problem nur dort auf und nicht bei den 8 anderen VM's?

Poste doch mal bitte die Netzwerkkonfiguration einer deiner anderen VMs, Danke.

[Mpenzi]

... funktionierte, die anderen VM's haben die gleichen interfaces, abgesehen von den individuellen Host-IPs.

Welches OS/OS-Version haben die anderen VM's?

Alle Maschinen Host wie VM's hatten Debian 11 und jetzt Debian 12 Linux.

[Mpenzi]

Warum tritt dann das Problem nur dort auf und nicht bei den 8 anderen VM's?

Poste doch mal bitte die Netzwerkkonfiguration einer deiner anderen VMs, Danke.

Bitte, das ist die des Apache-Servers

Code: Alles auswählen

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp1s0
iface enp1s0 inet static
        address 176.59.170.143
        netmask 255.255.255.255
        pointopoint 78.6.75.155
        gateway 78.6.75.155
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 192.168.1.1 213.133.100.100 9.9.9.9
        dns-search example.com

# The internal network interface
allow-hotplug enp7s0
iface enp7s0 inet static
        address 192.168.1.143/24
        gateway 192.168.1.1
        dns-nameservers 192.168.1.1 213.133.100.100 9.9.9.9
        dns-search example.com

Der ist ereichbar.

[bluestar]

Bitte, das ist die des Apache-Servers

Wie sieht die Ausgabe von ip route dort aus?

[Mpenzi]

Bitte, das ist die des Apache-Servers

Wie sieht die Ausgabe von ip route dort aus?

Stimmt, hätte ich auch gleich bedenken können:

Code: Alles auswählen

ip route
default via 78.6.75.155 dev enp1s0 onlink 
78.6.75.155 dev enp1s0 proto kernel scope link src 176.59.170.143 
192.168.1.0/24 dev enp7s0 proto kernel scope link src 192.168.1.143

[mat6937]

Code: Alles auswählen

default via 78.6.75.155 dev enp1s0 onlink 

Weil die default route über das enp1s0-Interface geht.

Versuch doch mal mit "auto enp1s0" auf dem anderen Server.

[bluestar]

Stimmt, hätte ich auch gleich bedenken können:

Code: Alles auswählen

ip route
default via 78.6.75.155 dev enp1s0 onlink 
78.6.75.155 dev enp1s0 proto kernel scope link src 176.59.170.143 
192.168.1.0/24 dev enp7s0 proto kernel scope link src 192.168.1.143

Damit hast du doch die Erklärung für dein Problem geliefert, du brauchst auf keinem deiner Systeme die Angabe gateway 192.168.1.1 nimm sie am besten in allen VMs raus und du bist deine Probleme los und auch redundante Parameter solltest du dabei direkt entfernen:

Code: Alles auswählen

cat /etc/network/interfaces 
source /etc/network/interfaces.d/* 

# The loopback network interface 
auto lo 
iface lo inet loopback 

# The primary network interface 
allow-hotplug enp1s0 
iface enp1s0 inet static 
       address 176.59.170.141 
       netmask 255.255.255.255 
       pointopoint 78.6.75.155 
       gateway 78.6.75.155 
       dns-nameservers 213.133.100.100 9.9.9.9 
       dns-search example.com 

# The intern network interface 
allow-hotplug enp7s0 
iface enp7s0 inet static 
       address 192.168.1.141/24
       dns-nameservers 192.168.1.1 

[Mpenzi]

Vielen Dank für die rege Beteiligung an der Problemlösung. Ich wollte jetzt die angebotenen Lösungen ausprobieren, nachdem ich ein weiteres Problem - einen Bug in Bookworm - gelöst hatte, als dann eben besagte Netzwerkkonfiguration wieder ohne Änderung funktionierte.

Der Reihe nach:

• Gestern, als ich eine funktionierende Config auf die Problem-VM einspielte und nur die IP-Adressen angepasst hatte, ging nach einem Reboot nichts mehr von außen und vom privaten Netzwerk.
  Also habe ich versucht mittels Virt-Manager vom Host aus zu dieser VM über VNC zu kommen. Das ging nicht, weil Bookworm bei diesem Paket https://packages.debian.org/bookworm/am ... m/filelist einen Bug hat. Im Gegensatz zu Buster fehlt hier die Datei /var/lib/polkit-1/localauthority/10-vendor.d/60-libvirt.pkla. Erst als das geflickt war und der Libvirtd neugestartet war, funktionierte virt-manager wieder und ich konnte auf die Problem-VM.
  Jetzt habe ich die Original-interfaces wieder zurückkopiert und einen Reboot gemacht.
  Fazit, ab jetzt läuft dieser DNS-Server wieder komplett normal.

Ich verstehe das immer noch nicht, was da los war. Denn diese VM ist wieder unter ihrer externe IP im Internet erreichbar und somit auch DNS. Ich brauchte Eure Vorschläge erst gar nicht ausprobieren.
Im Übrigen, weil hier auch die Argumente zusammen mit Thomas-Kremm kamen, die Config wäre falsch. Sie wird für die dezidierten Server bei Hetzner-Online https://docs.hetzner.com/de/robot/dedic ... ian-ubuntu selber empfohlen. Und ich weiß, das war vor zwei Jahren ein mächtiges Gefrickel, weshalb ich froh bin, dass es läuft.
Aber wenn jemand eine Verbesserung der Hetzner-Version hat, nur her damit.

Viele Grüße
MPenzi

[mat6937]

... Erst als das geflickt war und der Libvirtd neugestartet war ...
Jetzt habe ich die Original-interfaces wieder zurückkopiert und einen Reboot gemacht.
Fazit, ab jetzt läuft dieser DNS-Server wieder komplett normal.
...Ich brauchte Eure Vorschläge erst gar nicht ausprobieren....

Dann weißt Du auch nicht, ob der (DNS-)Server nicht auch _nur_ mit den Vorschlägen und _ohne_ " ... Erst als das geflickt war und der Libvirtd neugestartet war ..." , normal gelaufen wäre, oder?
Wie ist jetzt die Ausgabe von:

Code: Alles auswählen

ip r

auf diesem (DNS-)Server?

[Mpenzi]

Code: Alles auswählen

default via 78.6.75.155 dev enp1s0 onlink 
78.6.75.155 dev enp1s0 proto kernel scope link src 176.59.170.141 
192.168.1.0/24 dev enp7s0 proto kernel scope link src 192.168.1.141

Das ist alles so, wie ich bereits gepostet hatte.

[mat6937]

Das ist alles so, wie ich bereits gepostet hatte.

Ja, so wie es sein soll.
Aber trotzdem ist der Erkennstnisgewinn aus deinem diesem Thread, ziemlich gering. Denn:

Das ging nicht, weil Bookworm bei diesem Paket https://packages.debian.org/bookworm/am ... m/filelist einen Bug hat. Im Gegensatz zu Buster fehlt hier die Datei /var/lib/polkit-1/localauthority/10-vendor.d/60-libvirt.pkla. Erst als das geflickt war und der Libvirtd neugestartet war, funktionierte virt-manager wieder und ich konnte auf die Problem-VM.

Du hast auf den anderen doch auch Bookworm und dort gab es dieses Problem nicht, oder?

[bluestar]

Ich brauchte Eure Vorschläge erst gar nicht ausprobieren.

Schade das du deine Netzwerkprobleme nicht wirklich reparieren möchtest.

Im Übrigen, weil hier auch die Argumente zusammen mit Thomas-Kremm kamen, die Config wäre falsch. Sie wird für die dezidierten Server bei Hetzner-Online https://docs.hetzner.com/de/robot/dedic ... ian-ubuntu selber empfohlen.

Die Konfiguration seitens Hetzner ist korrekt, im Gegensatz zu deiner und das ist leider Fakt.

[Mpenzi]

Das ist alles so, wie ich bereits gepostet hatte.

Ja, so wie es sein soll.
Aber trotzdem ist der Erkennstnisgewinn aus deinem diesem Thread, ziemlich gering. Denn:

Das ging nicht, weil Bookworm bei diesem Paket https://packages.debian.org/bookworm/am ... m/filelist einen Bug hat. Im Gegensatz zu Buster fehlt hier die Datei /var/lib/polkit-1/localauthority/10-vendor.d/60-libvirt.pkla. Erst als das geflickt war und der Libvirtd neugestartet war, funktionierte virt-manager wieder und ich konnte auf die Problem-VM.

Du hast auf den anderen doch auch Bookworm und dort gab es dieses Problem nicht, oder?

Warum sollte der virt-manager auf den VM's ("den anderen") installiert sein? Das ist sinnlos.
Noch einmal in Kurzform:
KVM-Host beinhaltet mehrere VM's
KVM-Host verfügt über den virt-manager für Erstinstallationen und Notfallzugriff via VNC => kaputtes Paket in Bookworm verhindert eben VNC-Zugriff.
Login an DNS-VM war aus dem Internet und eben auch nicht mehr aus 192.168.1.0er Netz nach Reboot der VM möglich.
Login an DNS-VM via VNC von KVM-Host war erst möglich nach Reparatur des Libvirts auf KVM-Host.

Also wieso jetzt diese Frage?

[Mpenzi]

Schade das du deine Netzwerkprobleme nicht wirklich reparieren möchtest.

Die Konfiguration seitens Hetzner ist korrekt, im Gegensatz zu deiner und das ist leider Fakt.

Das ist nicht richtig. Ich habe sehr wohl Interesse Netzwerkprobleme zu lösen. Ich hatte nur anhand der Tatsache, dass der DNS-Server plötzlich wieder lauffähig am Netz war, ohne Änderungen, mich dahin geäußert, dass dann die Analysen nicht notwendig seien.

Jetzt sagst Du die Hetzner-Konfiguration sei korrekt, ich sehe jedoch keinen Unterschied zu meiner. Wärst Du bereit mir zu sagen, wo meine nicht korrekt gegenüber der von Hetzner ist?

[bluestar]

Jetzt sagst Du die Hetzner-Konfiguration sei korrekt, ich sehe jedoch keinen Unterschied zu meiner. Wärst Du bereit mir zu sagen, wo meine nicht korrekt gegenüber der von Hetzner ist?

In deiner /etc/network/interfaces deiner Systeme darf auf dem privaten Interface kein Default-Gateway hinterlegt sein. Es darf nur Das Default-Gateway gibt es ausschließlich auf dem Interface mit der öffentlichen IP.

[Mpenzi]

In deiner /etc/network/interfaces deiner Systeme darf auf dem privaten Interface kein Default-Gateway hinterlegt sein. Es darf nur Das Default-Gateway gibt es ausschließlich auf dem Interface mit der öffentlichen IP.

Nun, das ist ja auch auf allen VM's der Fall. Dann war offensichtlich exakt das der Fall bei der DNS-VM, aber auch die hat das Defaultgateway in Richtung externe Schnittstelle des KVM-Host.

Vielen Dank
Mpenzi