[gelöst] Kernel-IP-Routentabelle nach Neustart wieder verhunzt

[debianfanboy]

Hallo Forum,

auf meiner QNAP läuft Debian 10 und ich habe darauf pihole installiert. Dabei bin ich auf einige Probleme gestoßen, die ich alle samt lösen konnte, worüber ich sehr froh bin. Allerdings verbleibt noch eine kleine Schwierigkeit, die mein Verständnis übersteigt. Nach der Installation konnte ich aus einem anderen Subnetz heraus die Nextcloud nicht mehr erreichen, ssh ging auch nicht und anpingen blieb hängen. Aus dem gleichen Subnetz gab es keine Probleme. Stundenlange Recherche hat es dann auch gebracht:

Code: Alles auswählen

# ip route show
default via 192.168.100.1 dev eth0 src 192.168.100.2 metric 202 
192.0.0.0/8 dev eth0 proto dhcp scope link src 192.168.100.2 metric 202

Die Lösung ging so:

Code: Alles auswählen

# ip route add 192.168.100.0/24 dev eth0 proto dhcp scope link src 192.168.100.2 metric 202

Code: Alles auswählen

# ip route delete 192.0.0.0/8 dev eth0 proto dhcp scope link src 192.168.100.2 metric 202

Ich habe jetzt nicht vor, das Gerät ständig zu rebooten, aber nach einem Neustart ist die Routentabelle wieder verhunzt.

1. Woran liegt das und ist es möglich, das zu beheben?

In einem anderen Beitrag habe ich vor geraumer Zeit versucht rauszufinden, warum die QNAP nicht auf systemctl suspend reagiert. Den werde ich jetzt auch mal wieder aufgreifen und da kommt natürlich die Frage auf:

2. Wird die Routentabelle auch nach dem Aufwachen aus der Bereitschaft wieder zurückgesetzt?

[eggy]

Zum selbst finden: Für jede "Hin-Route" muss es auch eine "Zurück-Route" geben.
Angenommen A und B sind in zwei unterschiedlichen Subnetzen (SubA, SubB):
auf A: Route hinzufügen: (Host-Route) "das ist der Weg auf dem Du B erreichst" oder (Netz-Route) "das ist der Weg auf dem Du Rechner in SubB erreichst"
und auf B: Route hinzufügen: (Host-Route) "das ist der Weg auf dem Du A erreicht" oder (Netz-Route) "das ist Weg auf dem Du Rechner in SubA erreichst"
Auf die Metriken achten: falls mehrere Wege zum Ziel führen, welcher wird genommen?

Reboote die Kisten und zeig mal ip a und ip r in unverändertem Zustand.

[mat6937]

Code: Alles auswählen

# ip route show
default via 192.168.100.1 dev eth0 src 192.168.100.2 metric 202 
192.0.0.0/8 dev eth0 proto dhcp scope link src 192.168.100.2 metric 202

Die Lösung ging so:

Code: Alles auswählen

# ip route add 192.168.100.0/24 dev eth0 proto dhcp scope link src 192.168.100.2 metric 202

Code: Alles auswählen

# ip route delete 192.0.0.0/8 dev eth0 proto dhcp scope link src 192.168.100.2 metric 202

Welche netmask hast Du ursprünlich für das eth0-Interface konfiguriert bzw. wie wird dem eth0-Interface seine IPv4-Adresse zugewiesen?

[debianfanboy]

Danke für die Erklärung, dass zu einer Hin-Route eine Rück-Route gehört! Damit muss ich mich mal tiefer gehend beschäftigen.

Reboote die Kisten und zeig mal ip a und ip r in unverändertem Zustand.

Code: Alles auswählen

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:08:9b:de:e8:67 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.2/8 brd 192.255.255.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::56cc:303f:3a2e:f53f/64 scope link 
       valid_lft forever preferred_lft forever

Code: Alles auswählen

# ip r
default via 192.168.100.1 dev eth0 src 192.168.100.2 metric 202 
192.0.0.0/8 dev eth0 proto dhcp scope link src 192.168.100.2 metric 202 

Welche netmask hast Du ursprünlich für das eth0-Interface konfiguriert bzw. wie wird dem eth0-Interface seine IPv4-Adresse zugewiesen?

Ich sehe grad, dass ich 255.0.0.0 in /etc/network/interfaces.d/eth0 stehen habe. Die habe ich aber erst angelegt, nach dem das Problem auftrat, vorher war das Verzeichnis leer. Der Router verteilt die IPv4-Adressen per DHCP, das Gerät kriegt aber immer die gleiche.

Code: Alles auswählen

cat /etc/network/interfaces.d/eth0 
iface eth0 inet static
	address 192.168.100.2
	netmask 255.0.0.0
	gateway 192.168.100.1
	network 192.168.100.0
	broadcast 192.168.100.255
	dns-nameservers 127.0.0.1
/sbin/ethtool -s eth0 wol g

Nachdem ich die netmask auf 255.255.255.0 gestellt habe, bleibt das Problem bestehen.

[mat6937]

Ich sehe grad, dass ich 255.0.0.0 in /etc/network/interfaces.d/eth0 stehen habe. Die habe ich aber erst angelegt, nach dem das Problem auftrat, vorher war das Verzeichnis leer. Der Router verteilt die IPv4-Adressen per DHCP, das Gerät kriegt aber immer die gleiche.

Code: Alles auswählen

cat /etc/network/interfaces.d/eth0 
iface eth0 inet static
	address 192.168.100.2
	netmask 255.0.0.0
	gateway 192.168.100.1
	network 192.168.100.0
	broadcast 192.168.100.255
	dns-nameservers 127.0.0.1
/sbin/ethtool -s eth0 wol g

Nachdem ich die netmask auf 255.255.255.0 gestellt habe, bleibt das Problem bestehen.

BTW: Ergänze die Datei "/etc/network/interfaces.d/eth0", mit "auto eth0" als 1. Zeile. Evtl. als letzte Zeile mit "post-up":

Code: Alles auswählen

post-up /sbin/ethtool -s eth0 wol g

statt nur "/sbin/ethtool -s eth0 wol g".
Hast Du nach der Änderung in der Datei "/etc/network/interfaces.d/eth0", dein Gerät rebootet? Ist die IP-Adresse 192.168.100.2 von außerhalb des DHCP-Pools des Routers? Hast Du z. Zt. auf diesem Gerät, evtl. noch einen aktiven dhcp-Client?

[debianfanboy]

BTW: Ergänze die Datei "/etc/network/interfaces.d/eth0", mit "auto eth0" als 1. Zeile. Evtl. als letzte Zeile mit "post-up":

Code: Alles auswählen

post-up /sbin/ethtool -s eth0 wol g

statt nur "/sbin/ethtool -s eth0 wol g".
Hast Du nach der Änderung in der Datei "/etc/network/interfaces.d/eth0", dein Gerät rebootet? Ist die IP-Adresse 192.168.100.2 von außerhalb des DHCP-Pools des Routers? Hast Du z. Zt. auf diesem Gerät, evtl. noch einen aktiven dhcp-Client?

Die Änderungen in interfaces.d/eth0 habe ich vorgenommen und nach einem systemctl restart networking war die Routentabelle wieder hin. Gerebootet habe ich nicht.
Die IP-Adresse ist tatsächlich außerhalb des DHCP-Pools des Routers, der fängt erst bei 20 an. In dem anderen Subnetz, das fast genauso strukturiert ist, macht das aber auch kein Problem. Am Router habe ich 'diesem Gerät immer diese IP-Adresse vergeben' angewählt.

Die letzte Frage verstehe ich nicht ganz. Mit "auf diesem Gerät" ist das gemeint, worauf das Pihole läuft? Es kann doch jedes Gerät nur ein dhcp-Client sein oder verstehe ich was falsch?

Aktuell sehen die Ausgaben so aus, ich habe die Routentabelle wieder manuell angepasst:

Code: Alles auswählen

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:08:9b:de:e8:67 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.2/8 brd 192.255.255.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::56cc:303f:3a2e:f53f/64 scope link 
       valid_lft forever preferred_lft forever

Code: Alles auswählen

# ip r
default via 192.168.100.1 dev eth0 src 192.168.100.2 metric 202 
192.168.100.0/24 dev eth0 proto dhcp scope link src 192.168.100.2 metric 202 
192.168.100.1 dev eth0 scope link 

Was mich wundert, ist, dass bei 'ip a' auch die Netzmaske /8 angezeigt wird und das auch nach dem Neustart mit 'netmask 255.255.255.0' in der interfaces.d/eth0. Ist die Netzwerkkonfiguration eventuell noch irgendwo anders hinterlegt und die kommen sich ins Gehege? Wie gesagt, das Verzeichnis interfaces.d war ursprünglich auch leer.

[mat6937]

Es kann doch jedes Gerät nur ein dhcp-Client sein oder verstehe ich was falsch?

Ja, so sollte es sein, oder gar kein dhcp-Client wenn man DHCP für die Zuweisung nicht benutzt.
Aber es gibt user die wissen nicht wie bzw. was auf ihrem Gerät konfiguriert ist. Lt. deiner Frage:

Ist die Netzwerkkonfiguration eventuell noch irgendwo anders hinterlegt und die kommen sich ins Gehege?

bist Du dir auch nicht ganz sicher, oder?

[debianfanboy]

Ich bin mir nicht ganz sicher, weil ich vor der Installation von Pihole keine Probleme hatte und jetzt vermute, dass das Installationsskript irgendwo noch was angelegt hat.

[debianfanboy]

Ich hab grad das hier gefunden und versuche nochmal allein klarzukommen. Danke an alle!

Edit: Jetzt funktioniert es. Das Problem war offenbar einfach nur 'nameservers' statt 'nameserver' in der interfaces.d/eth0

Code: Alles auswählen

# cat /etc/network/interfaces.d/eth0 
auto eth0
iface eth0 inet static
	address 192.168.100.2
	netmask 255.255.255.0
	gateway 192.168.100.1
	network 192.168.100.0
	broadcast 192.168.100.255
	dns-nameserver 127.0.0.1
post-up /sbin/ethtool -s eth0 wol g

Code: Alles auswählen

# systemctl restart networking.service

Code: Alles auswählen

# ip r
default via 192.168.100.1 dev eth0 onlink 
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.2 
192.168.100.0/24 dev eth0 proto dhcp scope link src 192.168.100.2 metric 202 
192.168.100.1 dev eth0 scope link 

Code: Alles auswählen

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:08:9b:de:e8:67 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.2/24 brd 192.168.100.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.100.2/8 brd 192.255.255.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::56cc:303f:3a2e:f53f/64 scope link 
       valid_lft forever preferred_lft forever

[mat6937]

Edit: Jetzt funktioniert es. Das Problem war offenbar einfach nur 'nameservers' statt 'nameserver' in der interfaces.d/eth0

Code: Alles auswählen

# cat /etc/network/interfaces.d/eth0 
auto eth0
iface eth0 inet static
	address 192.168.100.2
	netmask 255.255.255.0
	gateway 192.168.100.1
	network 192.168.100.0
	broadcast 192.168.100.255
	dns-nameserver 127.0.0.1
post-up /sbin/ethtool -s eth0 wol g

Bist Du sicher, dass es diese Option "dns-nameserver", für die interfaces-Datei (oder gleichwertig) gibt?
Wie ist die Ausgabe von:

Code: Alles auswählen

cat /etc/resolv.conf

?

[JTH]

Bist Du sicher, dass es diese Option "dns-nameserver", für die interfaces-Datei (oder gleichwertig) gibt?

Ja, die gibt es. Erfordert allerdings (meine ich, lange nicht benutzt) resolvconf.

[guennid]

Bist Du sicher, dass es diese Option "dns-nameserver", für die interfaces-Datei (oder gleichwertig) gibt?

Ja, die gibt es.

Heißt das, dieser Eintrag ersetzt(e) den in /etc/resolv.conf?

[mat6937]

Ja, die gibt es.

Dort steht auch:

The dns-nameservers option is also accepted and, unlike dns-nameserver, can be given multiple arguments, separated by spaces.

, was beim TE aber nicht funktioniert haben soll.

[mat6937]

Heißt das, dieser Eintrag ersetzt(e) den in /etc/resolv.conf?

Ich denke, resolvconf wird diesen Eintrag in die /etc/resolv.conf schreiben.
Ich wollte aber darauf hinaus, ob beim TE, die eine Option evtl. nur ignoriert wird und die andere Option evtl. den Fehler verursacht hat (... vielleicht wegen dem 127.0.0.1?).

[debianfanboy]

Edit: Jetzt funktioniert es. Das Problem war offenbar einfach nur 'nameservers' statt 'nameserver' in der interfaces.d/eth0

Code: Alles auswählen

# cat /etc/network/interfaces.d/eth0 
auto eth0
iface eth0 inet static
	address 192.168.100.2
	netmask 255.255.255.0
	gateway 192.168.100.1
	network 192.168.100.0
	broadcast 192.168.100.255
	dns-nameserver 127.0.0.1
post-up /sbin/ethtool -s eth0 wol g

Bist Du sicher, dass es diese Option "dns-nameserver", für die interfaces-Datei (oder gleichwertig) gibt?
Wie ist die Ausgabe von:

Code: Alles auswählen

cat /etc/resolv.conf

?

Code: Alles auswählen

cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1

Ich werde in den nächsten Tage nochmal einen Neustart machen und schauen, was das Ergebnis ist und hier posten.