weidner/computer/netz/

Du sollst kein anderes Gateway haben

Ich bin der Router, dein Gateway. Du sollst keine anderen Gateways haben neben mir.

Während das erste christliche Gebot mit einem eifersüchtigen Gott begründet wird, über den ich nicht spekulieren will, weiß ich einige handfeste Gründe, warum in einem Rechnernetz mit mehreren Endgeräten nicht mehr als ein Gateway die Verbindung zu anderen Netzwerken herstellen sollte.

Natürlich geht es auch mit mehreren Gateways und man kann es auch hinbekommen, dass es für alle Geräte funktioniert. Oft steht der Aufwand, den man dafür treiben muss, jedoch in keinem angemessenen Verhältnis zum Nutzen.

Der Hauptgrund dafür liegt in der Anzahl der Endgeräte und der gestiegenen Komplexität, mit der Routing-Entscheidungen getroffen werden, sowie in dem Misstrauen, dass moderne Endgeräte heutzutage selbst wohlmeinenden Hinweisen ihres Gateways entgegenbringen, beziehungsweise dem Unverständnis älterer Geräte.

Doch der Reihe nach. Ich bin schon etliche Jahre als Administrator in IP-Netzwerken unterwegs und habe vieles gesehen und mir über einiges eine Meinung gebildet. In der Firma, in der ich vor mehr als 20 Jahren mit System- und Netzwerk-Administration anfing, übernahm ich ein zentrales Netz mit Clients und Servern, in dem mehrere Router Verbindungen zu verschiedenen Kundennetzen aufbauten.

An dieses zentrale Netz war damals auch die Firewall angeschlossen, über die es in das Internet ging. Unsere Kunden nutzten Serverdienste aus unserem Netz und den Internetzugang über unsere Firewall. Einer der Router zu unseren Kunden war der Default-Router für das zentrale Netz, in das Internet ging es nur via Proxy, dafür war keine Route notwendig.

Der Default-Router musste hin und wieder neu gestartet werden, und genau dann konnten auch die Kunden, die über andere Router angebunden waren, nicht mehr auf unsere Server zugreifen. Der Internetzugang funktionierte hingegen weiter.

Natürlich kamen die Kollegen zu mir und fragten, ob ich etwas am Netz gemacht hätte, weil kein Kundennetz erreichbar war.

Ich sagte "Nein, habe ich nicht" und fragte "Funktioniert denn der Internetzugang noch bei den Kunden?", "Ja" sagten die Kollegen, "das funktioniert noch".

Also war das Netz nicht kaputt. Später erfuhr ich, dass ein Kollege den Default-Router neu gestartet hatte, weil die Verbindung zum Kunden dahinter schlecht geworden war.

Da diese Verbindung häufig schlecht wurde, mit nachfolgenden Neustarts dieses Routers, kamen wir überein, ein separates Gerät als Default-Router zu verwenden. Das funktionierte oberflächlich ganz gut, die Komplettausfälle der Verbindungen zu den Kunden verschwanden.

Unter der Oberfläche konnte ich beim Default-Router sehen, dass sehr viele Datagramme doppelt vorkamen und zwar solche, die von den Clients oder Servern aus unserem Netz an die Kunden gesendet wurden. Diese sendeten alles an das Default-Gateway, der die Datagramme zu den richtigen Routern weiterleitete und ICMP-Redirects an den Sender verschickte. Diese Redirects ignorierten die meisten Clients und Server.

Die ganze Situation gefiel mir nicht, aber so lange es funktionierte, hatte ich keine Handhabe, etwas zu ändern.

Erst als jemand den Default-Router ausschaltete - weil der ja sowieso nichts macht - und wieder ein Großteil der Netzressourcen nicht erreichbar war, bekam ich freie Hand, etwas zu ändern - aber ohne weitere Unterbrechungen und schnell bitte.

Mittlerweile hatte ich mich in eine Reihe von Netzwerkthemen eingelesen und auch schon eine Idee, wie ich beide Probleme - den Ausfall des Default-Routers und die Duplikate im zentralen Netz - auf einmal lösen konnte.

Ich hatte herausgefunden, dass alle Gateways im zentralen Netzwerk Proxy-ARP beherrschten. Also schaltete ich das überall ein und wies die Kollegen an, die Länge der Netzmaske bei allen Clients und Server im zentralen Netz auf 0 Bit zu setzen. Bei Windows-Rechnern trug man dazu die eigene Rechner-Adresse als Gateway ein.

Das funktionierte tatsächlich sehr zuverlässig und von da an gab es keinen Default-Router mehr. Für jede IP-Adresse, egal in welchem Netz, stellten die Windows-Clients und -Server eine ARP-Anfrage, der passende Router meldete sich und die Verbindung konnte aufgebaut werden. Das lief sogar erstaunlich gut, auch wenn ich mit der Zeit Bedenken bekam, ob die ARP-Caches der Server, die von sehr vielen Clients kontaktiert wurden, nicht doch überliefen.

Einen Schönheitsfehler hatte diese Lösung: an jedem Client und an jedem Server musste die Netzmaske auf 0 Bit gesetzt werden. Das ging in unserer Firma mit weniger als 20 Clients und einer vergleichbaren Anzahl von Servern. Aber definitiv nicht bei Kunden mit Hunderten von Rechnerarbeitsplätzen.

Also hatten wir bei den Kundennetzen darauf geachtet, dass die Router stabil liefen und möglichst nur ein Gateway im lokalen Netz war. Das ging solange gut, bis einige Kunden VPN-Verbindungen zum Landesdatennetz bekamen (wir hatten fast nur Kunden der öffentlichen Hand) und die VPN-Router in ihren Netzen zwischen den Client-Rechnern platzierten.

Damit hatten wir wieder mehrere Gateways in einem Netz mit Endgeräten und wieder funktionierte nicht einmal ICMP-Redirect ohne zusätzliche Konfiguration. Jedes Mal, wenn wir uns mühsam die Konfiguration der Firewall- und Netzwerkeinstellungen erarbeitet hatten, funktionierten genau diese Einstellungen mit der nächsten Version von Windows nicht mehr.

Schließlich hatte ich nach und nach alle zusätzlichen Gateways aus den Client-Netzen entfernt, so dass diese hinter dem Default-Gateway lagen.

Später fügte ich einmal ein VPN-Gateway als Layer-2-Bridge vor einer FritzBox als Default-Gateway ein, dass den Datenverkehr für das VPN herausfischte und verschlüsselt über die FritzBox versendete. Damit umging ich die Probleme eines zweiten Gateways mit einer Lösung, die leider nicht alle meiner Kollegen nachvollziehen konnten.

Das ganze ist mittlerweile einige Jahre und ein paar Firmen her. Allerdings muss ich gestehen, dass ich selbst vor kurzem zu einem Netz, in dem bereits mehrere Gateways existierten, temporär einen weiteren Einwahl-Router "für die Messe" hinzufügte und dabei nicht beachtete, dass genau in diesem Netz auch Server angeschlossen waren, die die Leute vom Messestand erreichen wollten. Natürlich funktionierte auch das erst wieder nachdem der Serveradmin die zusätzlichen Routen eingetragen hatte. In diesem Netz kam erschwerend hinzu, das das Default-Gateway eine stateful Firewall hatte, die nie die SYN-Datagramme erhielt, welche eine TCP-Verbindung starten, und daher auch keinen passenden State bekamen, um die Verbindung zuzulassen.

Das erinnerte mich daran, das auch besseres Wissen mich nicht daran hindert, die dümmsten Fehler zu machen.

Nachtrag

Mehrere Gateways in einem Netz mit Endgeräten führen früher oder später zu asymmetrischem Routing, wenn man nicht konsequent auf allen Endgeräten und Routern die korrekten Routen setzt. Kommen dann noch mehrere Switche ins Spiel, kann es schon mal passieren, dass die Verbindung schlechter wird, weil ein oder mehrere Switche die MAC-Adresse eines Beteiligten vergessen und anfangen, die Datagramme für diesen an allen Ports des zugehörigen VLAN zu fluten.

Updates

2022-03-19: Nachtrag

Posted 2020-04-07