systemd pfuscht ins Routing
17. Mai 2019 um 19:54 Uhr von Atari-Frosch
Ich wollte nie systemd auf meinem Server (oder sonstwo drauf) haben. Nun habe ich es seit dem letzten Distri-Update (auf Stretch bzw. Debian 9) doch drauf, trotz Pinning, also gegen meinen erklärten Willen. Bisher ging das gut, aber wie ich auch von anderen immer wieder lese, ist es nur eine Frage der Zeit, bis systemd Probleme macht. Heute war ich dran. Und ich hatte mal wieder 'ne sehr flache Lernkurve …
Dieser Tage kam ein Kernel-Update und ein Update auf intel-microcode, und ich hatte auch vorher schon einige Kernel-Updates gesehen, aber immer den nötigen Reboot verpeilt. Deshalb ist es durchaus möglich, daß mir dieses Problem schon früher hätte auffallen können, wenn ich denn rebootet hätte. Die Ursache war allerdings nicht der Kernel selbst, der war quasi nur Ausführender.
Nachdem ich dann heute endlich rebootet hatte, hatte ich plötzlich scheinbar ein Problem auf meinem lokalen PC. Dieser ist zwar per OpenVPN mit dem Server verbunden, trotzdem erschien es mir erst einmal unlogisch, daß ich hier ein Problem haben sollte, nachdem der Server rebootet hat. Daher suchte ich natürlich auch erst einmal lokal nach der Ursache.
Das Problem bestand darin, daß ich keine Namensauflösung mehr bekam, und zwar unabhängig davon, welchen Nameserver ich ansprach. Die Antwort lautete immer „no servers could be reached“ – auch dann, wenn ich nicht die Nameserver von Hetzner anfragte. Egal ob 1.1.1.1, 8.8.8.8, 141.1.1.1 oder eben die Nameserver von Hetzner – es kam immer dieselbe Fehlermeldung. Es waren also nicht die Nameserver von Hetzner.
Dann probierte ich mal eine Namensauflösung vom Server direkt aus, und siehe da: Alle Nameserver antworteten prompt. An dieser Stelle fing ich an, meinen hiesigen Provider, UnityMedia, zu verdächtigen, Nameserver-Abfragen abzupassen. Um das zu überprüfen, schaltete ich das WLAN in meinem Smartphone ein und verband mich auf meinen UnityMedia-Router. Das Smartphone hatte Namensauflösung und konnte alles erreichen. Daraus schloß ich – fälschlicherweise – erst recht, daß es an meinem lokalen PC liegen müßte.
Nach etwas Grübeln kam ich auf die Idee, den VPN-Client auf dem lokalen PC mal abzuschalten. Prompt hatte ich wieder eine Namensauflösung.
Damit wurde mir so langsam klar, daß das Problem doch kein lokales ist. Beim Durchsehen von /etc auf meinem PC war mir aufgefallen, daß systemd eigene Angaben zum Routing macht. Und ja, auch auf meinem lokalen PC, der noch unter Debian Jessie läuft, hat sich systemd-Zeugs eingeschlichen, das ich da explizit nicht haben wollte.
Auf dem Server fand ich dann prompt dieselben Einträge, unabhängig von dem, was ich schon vor $ewig in die Kernel-Konfiguration eingetackert hatte: Das Routing für IPv4 war abgeschaltet (IPv6 hab ich immer noch nicht konfiguriert – man kommt ja zu nix …).
Das heißt: systemd hat sich die Freiheit genommen, meine bisherige Einstellung für das Kernel-Routing zu ignorieren und dem Kernel seinen eigenen Default reingedrückt. Es wurde also gar nichts geroutet, nicht nur Nameserver-Anfragen. Bei denen fällt es nur als erstes auf, weil man das ja üblicherweise auch zuerst braucht, um irgendwas im Netz tun zu können, bei dem man nicht alle IP-Adressen auswendig weiß. Echt mal, wer denkt sich sowas aus? 😠
So. Um nicht nochmal rebooten zu müssen, habe ich nach einer Konsultation von DuckDuckGo erstmal das Routing „on the fly“ aktiviert:
sysctl -w net.ipv4.ip_forward=1
Dann den OpenVPN-Client wieder gestartet, den ich zwischendurch ausgeschaltet hatte, und siehe da, ich bekam wieder alles aufgelöst.
Damit das auch nach dem nächsten Reboot weiterhin funktioniert, habe ich das noch fest eingetackert:
# $editor /etc/sysctl.conf:
net.ipv4.ip_forward = 1
(gefunden in How to Enable IP Forwarding in Linux)
So, und jetzt hat mir systemd genug von meiner Zeit gestohlen, und ich kann mich wieder anderen Dingen widmen. Und irgendwann sollte ich dann doch mal auf ein anderes Linux oder freies Betriebssystem umsteigen, das mir kein Zeugs mitbringt, welches ungefragt meine Einstellungen verbiegt …
18. Mai 2019 at 18:33
es gibt auch Distributiionen ohne den Quatsch, schau mal nach voidlinux, ist Linux wie es sein soll, KISS
19. Mai 2019 at 1:32
@Frosch:
Ich bin mit Sicherheit kein Freund von dem systemd, aber möglicherweise verdächtigst du hier den falschen Teil. Ich hatte vor einiger Zeit selbst ähnliche Probleme, dass das Routing nach dem Update komplett versaut war … und wie schreibst du „flache Lernkurve“ … hat mich ne ganze Menge Zeit gekostet um hinter einen Teil der Mysterien zu kommen:
Kurz vorher hatte ich am Router IPv6 frei geschaltet und auf mehreren Geräten sowohl IPv4 als auch IPv6 eingerichtet, nur eben noch nicht auf dem fraglichen PC. Beim Update hat der Debian Kram aber gemerkt dass IPv6 verfügbar ist und mir die gesamten Netzwerk Einstellungen verbogen. Nichts hat danach mehr richtig funktioniert. Wiederholbar, IPv6 am Router aus … es geht … IPv6 am Router ein … total versaute Netzwerk Konfiguration.
Das war für mich letztlich der Ausschlag mich von Debian zu verabschieden … und siehe da, Devuan ist zwar ohne den systemd macht aber ansonsten den gleichen Sch***!