Gefahren von local-proxy-arp
Ein typisches DSL-Netzwerk verhindert am DSLAM die Querkommunikation zwischen den Teilnehmern. Allerdings wollen die Nutzer auch direkt miteinander kommunizieren können, besonders, wenn es sich um Firmen mit statischen IP Adressen handelt. Und das ist überraschend komplex. Beim Einsatz von DHCP in großen Layer2-Wolken, leidet darunter auch die Redundanz der Anbindung.
Problemstellung
In einem typischen Breitband-Anschluss-Netz werden die Endkunden mit einzelnen Leitungen an einen DLSAM geführt.
Typischerweise hat man alle diese Verbindungen per PPP an die zentralen Router geführt. Die entstehende Topologie sieht dann so aus. Die violetten Pfeile zeigen die Datenwege an. Eine Querkommunikation wird anhand des grünen Pfeils realisiert.
Auf diese Weise werden sämtliche Daten der Endkunden durch die zentrale Technik geschleift, die betreffende Technik muss dann entsprechend leistungsfähig sein.
Aus Abrechnungssicht ist dieser Aufbau vorteilhaft, weil es eine zentrale Erfassung sämtlicher Datenvolumina und Online-Zeiten ermöglicht. Damit sind die Geschäftsmodelle aus "Dial-Up"-Modem-Zeiten weiterhin umsetzbar.
Mittlerweile hat sich allerdings auch eine Anschlussart verbreitet, die wie ein großes Ethernet funktioniert. In diesem Fall werden die Kunden in eine gemeinsame große Layer2 Wolke gesetzt und können so mit der zentralen Technik kommunizieren.
Aber was ist mit dem Quertraffic? In der Regel wird dieser Quertraffic – wie bisher – durch die DSLAMs unterbunden. Ob der Quertraffic auch außerhalb der DSLAMs wirksam unterbunden wird, ist meist nicht klar und wird nicht geprüft. In diesem Fall nehmen ich an, dass die Sperre nur am DSLAM selbst umgesetzt wird. Damit gibt es verbotene (rot) und erlaubte (grün) Kommunikationswege.
Was muss nun passieren, wenn Kunden untereinander kommunizieren wollen?
Dies ist kein obskurer Anwendungsfall, denn alle Kunden nehmen am Internet teil und selbstverständlich können sie miteinander reden wollen. Besonders augenfällig ist der Fall, wenn ein Anschluss einer Firma gehört und ein anderer Anschluss einem Mitarbeiter daheim, von dem er per VPN in die Firma kommen möchte.
Tricks
Um also in einem Layer2-Netz, dass nicht komplett vermascht ist, kommuniziert werden soll, muss einer der beteiligten Systeme als Relay (Weiterleiter) agieren. Das kann uns soll sinnvollerweise nur die zentrale Routingtechnik sein.
Wie lenkt man nun im Schritt 1 den Ethernet-Frame zum zentralen Router um?
Der Client fragt nach per ARP nach der MAC des Zielsystems im gleichen logischen Netzsegment. Dieses ARP Paket kommt aber aufgrund der DSLAM-Sperre nicht beim gewünschten Ziel an. Also antwortet der zentrale Router im Namen des eigentlichen Ziels auf die ARP-Anfrage (ip local-proxy-arp). Der Client lernt nun die MAC-Adresse des zentralen Routers für diesen Kommunikationsweg und schickt alle Pakete dort hin.
Natürlich kann der Router damit nichts anfangen, aber er weiß, dass er als Stellvertreter die Pakete entgegennehmen und an das eigentliche Zielsystem weiter schicken soll. Dazu sendet er im Schritt 2 den gleichen Frame wieder aus, diesmal aber an die MAC des Zielsystems.
Problem gelöst!
Redundanz
Spannend ist die Frage, wie man mit Redundanz bzgl. des Routers umgeht. Es ist sicher keine gute Idee nur ein Stück Hardware zu haben, an der alle Kunden hängen. Also gut, GLBP an (was für Lastverteilung auf den Routern sorgt) und laufen lassen.
Anfangs geht es gut, dann kommt ein seltsamer Effekt auf. Die Clients sind von extern nicht mehr erreichbar.
Ein Traceroute offenbart eine Schleife:
... 3 router1 15ms 14ms 15ms 4 router2 15ms 15ms 15ms 5 router1 15ms 15ms 15ms 6 router2 15ms 16ms 16ms ...
Was ist denn hier passiert?
Router1 hat irgendwann einmal wissen wollen, wer denn für die Ziel-IP zuständig ist und Router2 antwortete viel schneller als das Kundengerät. So lernte Router1 die MAC von Router2 für diesen Kunden.
Irgendwann endete der ARP-Eintrag von Router2 für das Ziel und nun war Router2 an der MAC des Zielsystems interessiert. Diesmal konnte Router1 aushelfen, denn er hatte noch einen gültigen Eintrag im Cache.
Noch schlimmer wird es, wenn in diesem Netz weitere Router oder Server aktiv sein müssen. Sobald der Router, derlocal-proxy-arp aktiviert hat, einen ARP Eintrag um Cache hat, wird er diesen benutzen, um sich in den Verkehr zu drängeln. Da der Router nun selbst die gewünschten Ziele erreichen kann, schließlich ist das sein Job, entzieht er die Pakete der speziellen Verarbeitung, die von dem angeschlossenen System geleistet werden soll.
Besonders auffällig ist das, wenn bestimmte Endkunden nur lokal gültige Bereiche benutzen und die externe Kommunikation durch NAT-Gerät vermittelt werden muss. Wird derartiger Traffic dem NAT-Gerät entzogen, gehen die Datenpakete ungenattet in die weite Welt. Ergebnis: Der Kunde ist offline, da keine Antwortpakete mehr zu ihm zurück finden.
Es bleibt also vorerst dabei, die Redundanz vorzubereiten und bei Bedarf manuell zu aktivieren. Das ist kein ernsthaftes Problem, da die Zuführung ebenfalls nur über eine manuelle Redundanz verfügt und direkt auf dem Router terminiert, der das local-proxy-arp bedient.
Ausblick
Eine Lösung dieses Problems steht noch mit einem anderen Effekt in Zusammenhang. Ich stelle erst das andere Problem dar, dann komme ich zur Lösung.
darf man fragen, welche Software du zum Visualisieren der Netzwerktopologien verwendest?
BEste Grüße,
Alex
2 Kommentare