Proxy-ARP Daemon
Kaputtes xDSL ist ein nervendes Problem hier. Wir haben die Schmerzen gemildert, indem wir die Netzmasken verkleinerten. Während der letzten Monate verschärfte sish die Situation wieder, weil rigide Filter auf den DSLAM ausgerollt wurden und Geräte hinzu kamen, die nicht in der Lage waren mit den kleinen Netzmasken umzugehen. Wir hatten das Problem grundsätzlich zu lösen.
Problem
Große Netzwerke haben eine große Anzahl an sichtbaren MAC Adressen. Einige Geräte (z.B. DSLAMs) verhalten sich seltsam, wenn sie zuviele MACs zu sehen bekommen. Deshalb versuchen die Netzwerkbetreiber ihre Netze zu segmentieren, so dass keine Frames mehr von einer entfernten, kleinen Lokation zu eienr anderen gelangen können. Die Blockade von Quertraffic zuwischen Kunden heißt split-horizon. Kunden in verschiedenen Teilen des Netzwerkes können dabei nicht mehr miteinander kommunizieren.
Große Netzwerke sind schwer zu betreiben. Deswegen wird möglichst nahe am Endkunden, also am DSLAM gefiltert. Diese "Fist-Hop-Security" Filter sind nur für einfache Anwendungsfälle gedacht und neigen dazu Pakete in nicht-standard-Situationen zu verwerfen. Man kann dann diese Filter nur abschalten oder damit leben.
Meistens lesen diese Geräte die DHCP-Kommunikation mit und passen danach ihre Filter an. Nutzer mit statischen IP Adressen machen aber oft gar kein DHCP, so dass diese Filter nicht zu lernen haben. Andere Nutzer haben mehr als ein Endgerät oder ganze Netzbereiche zugeteilt bekommen. In all dieses Fällen versagen die DLSAM-Filter.
Eine weitere Sicherheitsmaßnahme besteht darin, den Broadcast-Verkehr zu unterbinden, so er nicht dazu dient, die MAC Adresse zur dem Filter bekannten IP zu ermitteln. Die Idee hinter diesem Filter ist, dass jeder, der die MAC Adresse des Endgeräts kennt, dann automatisch berechtigt ist, mit diesem zu kommunizieren. Es genügt also, die Broadcasts von Endkunden zu Endkunden zu blockieren, um effektiv nur noch erlaubte Kommunikation zu haben.
Setzt man DHCP-Sniffing, Broadcast-Filter und Split-Horizon zusammen ein, erhält man ein typisches xDSL-Netzwerk, in dem die Nutzer nur mit dem zentralen Router reden können. Sämtliche darüber hinaus gehende Kommunikation ist nicht möglich.
Einfache Lösung
Gibt es nur einen einzelnen Router im Netz, so genügt es dort local-proxy-arp anzuschalten: Jede ARP-Anfrage (eines Endgeräts) wird vom Router mit der MAC-Adresse des Router-Interfaces beantwortet. Auf diese Weise können die Kunden im Umweg über den Router miteinander reden (hair pinning).
Da der Router die MAC-Adresse des Endgeräts schon bei der ARP-Anfrage dieses Geräts nach seinem Default-Router lernt, muss der Router oft gar nicht selbst ARP-Anfragen per Broadcast stellen. Einige Routermodelle erneuern die auslaufenden Cache Einträge per Unicast-Anfrage, die von den DSLAM-Filtern durchgelassen werden. Auf diese Weise kann man ein solches Netz ohne merkbare Störungen betreiben.
Gibt es allerdings mehrere Router oder Server an zentraler Stelle,. so wird es kompliziert. Local-proxy-arp kann nun nicht mehr eingesetzt werden, da die Router sonst sich gegenseitig die ARP-Anfragen beantworteten und anschließend die Pakete im Kreis laufen.
Andererseits bekommen DHCP-Server Probleme, weil sie auf den ARP-Test "Ist die IP noch frei?" Fake-Antworten vom Router bekommen. Local-proxy-arp stört alle Arten dieser Anwendungen erheblich.
Anderer Ansatz
Um unser Netz hier trotzdem am Laufen zu halten, stellt eine neue Software (parpd) die notwendigen ARP-Antworten. In Abhängigkeit von frei konfigurierbaren Regeln antwortet der Daemon auf ARP-Anfragen mit einer passenden Antwort. Dies kann die reale MAC des Endgeräts sein oder auch die MAC-Adresse eines Routers (redirect).
Die Software lernt durch passives Zuhören die realen MAC-IP Paare. Selbstverständlich ignoriert sie dabei Antworten von anderen Instanzen, beschränkt sich also auf die originalen Quellen. parpd erneuert auslaufende ARP Cache-Einträge mit Unicast-Anfragen. Nur um die Redirect-MAC zu ermitteln, darf sie auf Broadcast zurück greifen.
Antworten können aber auch verzögert werden, d.h. die ersten Anfragen eines Gerätes nach einer bestimmten IP werden innerhalb einer gewissen Zeit ignoriert. Auf diese Weise kann ein DHCP-Server seine Überprüfungen vornehmen, bekommt aber dann doch eine Antwort, wenn er auf direkter Kommunikation besteht.
Die frei konfigurierbaren Regeln gestatten die Anpassung an komplexere Aufbauten, z.B. überlappenden Netzen.
Beispiel
Wie sieht das in der Praxis aus? So:
cache timeout 302 # seconds tablesize 3499 # expecting about 10000 entries refresh 3*5 # 3 retries a 5 seconds each delay 4*3 # respond at 4th retry in 3 seconds end interface em0 timeout 1.011 # do not respond for queries to our own infrastructure rule 0.0.0.0/0 198.51.100.0/29 ignore # delay queries from the DHCP server rule 198.51.100.4/32 198.51.100.0/24 delay tell # help the routers/servers to reach the clients rule 198.51.100.0/29 198.51.100.0/24 tell # interclient communication through hairpinning at the default gateway rule 198.51.100.0/24 198.51.100.0/24 198.51.100.1 # help erroneous clients arping for everything rule 198.51.100.0/24 0.0.0.0/0 verbose 198.51.100.1 # multihomed server with weak host model rule 192.0.2.0/24 198.51.100.0/24 tell # show missing entries rule 0.0.0.0/0 0.0.0.0/0 verbose ignore end
Und ja, man kann beliebig viele davon in Betrieb nehmen. Aktuell rennen hier sechs Instanzen pro VLAN.
sehr interessante/r Artikel.
Wir betreiben ein ähnliches Netz wie du es beschreibst und stehen vor ähnlichen Problemen.
Stellt der parpd dann nicht auch wieder einen single-point-of failure dar (lässt sich der proxy redundant aufbauen)?
Wie sind deine (langzeit-)Erfahrung mit der Software?
Alle 10 Kommentare anzeigen