Ethernet-Bridge als Sniffer-Quelle
Protokollanalysatoren wie Wireshark und tcpdump helfen dem Admin bei Netzwerkproblemen sehr. Doch an die zu analysierenden Daten muss er erst mal herankommen. Die liefert eine Soft-Bridge auf dem Analyse-PC.
Die klassische Lösung zur Protokollanalyse ist das Einschleifen eines Hubs. Er gibt die auf einem Anschluss hereingekommenen Daten an allen anderen Ports wieder aus (Shared Medium). Hier kommt der Admin mit seinem Analyse-PC an die unterste Protokollschicht (Layer 2, MAC-Layer) heran und kann von dort aus alle darin steckenden, höheren Ebenen untersuchen – Layer 3: IP, Layer 4: TCP, UDP, darüber: SMB, CIFS, HTTP, und so weiter.
Allerdings zwingt man mit einem Hub die daran hängenden Rechner auf langsame 10 MBit/s herunter, was oft eine zu große Einschränkung darstellt. Außerdem sind Hubs mittlerweile schwer zu finden. Gewöhnliche Switches eignen sich nicht, denn sie schalten für jedes Datenpaket eine Verbindung zwischen den beteiligten Ports, die anderen bekommen nichts mit.
Auch mit der bei vielen Switches für den Unternehmenseinsatz vorhandenen Monitoring-Funktion ist man nicht immer aus dem Schneider. Denn bei manchen Modellen gibt der Monitoring-Port nur den Verkehr von einer Datenrichtung (Senden oder Empfangen) aus. Das liegt daran, dass der zu beobachtende Port und der, an dem der Monitor-PC hängt, typischerweise gleich schnell sind, also beispielsweise 100 MBit/s in eine Richtung übertragen. Über den beobachteten Port können aber maximal 200 MBit/s im Voll-Duplex-Betrieb fließen, sodass man sich für eine Richtung und damit unbrauchbare, weil unvollständige Mitschnitte entscheiden muss.
Eine Alternative wäre der Einsatz eines Ethernet-Taps. Solch einen protokollmäßig transparenten Messkoppler schleift man in den zu beobachtenden Link ein und verbindet seine zwei Ausgänge mit dem Test-PC. Allerdings kostet eine Fast-Ethernet-Ausführung rund 350 Euro, ein Gigabit-Modell kommt ohne weiteres auf das Zehnfache.
Im Internet finden sich zwar Anleitungen, um mit Kabelbrücken zwischen vier Ethernetbuchsen selbst einen Tap zu löten. Der funktioniert jedoch mit Gigabit-Ethernet gar nicht und bei Fast-Ethernet nicht zuverlässig, da eine solche elektrische Abzweigung nicht vorgesehen ist. Besonders auf langen Leitungen kann die Bastelvariante dazu führen, dass keine Verbindung mehr zu Stande kommt.
Zum Abgreifen der Datenströme in beiden Richtungen braucht man ohnehin zwei Netzwerkkarten im Analyse-Rechner. Die sinnvollere Lösung ist, die beiden Ports unter Linux als Software-Bridge zu konfigurieren. Sie reicht auf einem Anschluss hereinkommende Ethernet-Pakete mit geringer Verzögerung an einen anderen Port weiter. Anders als der Tap lässt die Bridge aber keine fehlerhaften Pakete durch.
Wenn der PC genug freie PCI-Slots besitzt, steckt man einfach eine preiswerte Netzwerkkarte dazu. Eine dritte ermöglicht, den Rechner per LAN fernzubedienen, etwa wenn man ihn über längere Zeit im Server-Raum aufstellen muss. Sind die Steckplätze knapp, hilft eine Multi-Port-Karte weiter. Im Gebrauchthandel findet man oft ältere Server-Modelle ab rund 70 Euro, einfache Neuware kostet nur wenig mehr.
Die Server-Karten sind oft sehr groß, daher sollte man vor dem Kauf den im PC-Gehäuse vorhandenen Platz überprüfen. Linux-Treiber gibt es für Karten aus dem Gebrauchthandel in der Regel auch. Denn im Bereich der Server-Netzwerke ist das Open-Source-System traditionell stark bestückt.
Gegenüber dem Rechner verhält sich eine Multi-Port-Karte wie mehrere einzelne. Die Pakete nehmen bei der hier geschilderten Konfiguration auch keine Abkürzung von Port zu Port auf der Karte, sondern laufen über den jeweiligen Bus zur CPU und zurück. Wenn sonst keine Geräte am PCI-Bus arbeiten, reicht die Geschwindigkeit zum Beobachten einer Fast-Ethernet-Verbindung aus. Eine Gigabit-Karte im PCI-Slot wird also gehörig ausgebremst, sodass schneller angebundene PCIe- oder PCI-X-Karten vorzuziehen sind.
Vor Überraschungen ist man dennoch nicht gefeit: In unseren Versuchen funktionierte eine Zwei-Port-Karte ANA-6922 zwar im LAN einwandfrei, mochte aber zwischen DSL-Modem und Router keine Pakete weiterreichen. Anscheinend lag das an den verwendeten Tulip-Chips (DEC 2114x), denn auch mit so bestückten regulären Netzwerkkarten gab es Paketverluste. Abhilfe brachte das Ausweichen auf ein Dual-Port-Modell von Intel.
