Was ist ARP? ARP-Tabelle, Broadcast-Domäne und Spoofing

Stellen Sie sich einen vollen Besprechungsraum vor. Sie haben einen Namen, wissen aber nicht, zu welchem Gesicht er gehört. Also fragen Sie laut in den Raum: „Ist Frau Becker hier?“ Jemand hebt die Hand, Sie ordnen Gesicht und Namen zu und beginnen das Gespräch.

Zwei Geräte im Netz tun genau das. Die IP-Adresse ist der Name; die MAC-Adresse, die man braucht, um einen Frame auf die Leitung zu legen, ist das Gesicht. Das Protokoll dazwischen heißt ARP, und dieser Artikel verfolgt die Frage anhand echter Mitschnitte: wie sie auf der Leitung aussieht, wie die Antwort gespeichert wird und was schiefgeht, wenn niemand prüft, wer antwortet.

ARP ist der Grund, warum eine VLAN-Grenze in der Praxis zählt. Der Artikel über VLANs hat die ARP-Tabelle immer wieder als ersten Prüfpunkt genannt; hier steht, warum. Beide gehören zum Leitfaden Netzwerksegmentierung.

Jede Ausgabe unten wurde auf echten Labormaschinen mit tcpdump aufgezeichnet, nichts nachgestellt; Adressen sind so belassen, wie sie gemessen wurden. Wenn Sie gerade eine Störung beheben müssen, springen Sie zu welche Ausgabe was bedeutet.

Was ist ARP? Von der IP-Adresse zur MAC-Adresse

ARP (Address Resolution Protocol) findet heraus, welche MAC-Adresse zu einer IP-Adresse im selben lokalen Netz gehört. Ein Gerät fragt das Netz „wer hat diese IP?“, und der Besitzer antwortet „ich, und das ist meine Hardware-Adresse“. Mehr ist es nicht.

Bemerkenswert ist, wie leise ARP arbeitet. Es hat keine Einstellungsseite, schreibt in kein Protokoll und taucht in keinem Dashboard auf. Ein Netz kann jahrelang laufen, ohne dass jemand ARP bemerkt, bis zu dem Tag, an dem zwei Geräte einander nicht finden.

Warum zwei Adressen? Arbeitsteilung von MAC und IP

Es gibt zwei Adressen, weil sie zwei Fragen beantworten: Die MAC-Adresse sagt, wer an diesem Kabel hängt; die IP-Adresse, wohin in der Welt das Paket soll. Die eine ist lokal und in die Hardware geschrieben, die andere logisch und vergeben.

Am deutlichsten wird das auf einer langen Strecke: Reist ein Paket über Kontinente, bleibt seine IP-Adresse gleich, die MAC-Adresse wird an jedem Router neu geschrieben. Eine MAC-Adresse gilt nur bis zum nächsten Halt.

Mit nur MAC-Adressen bräche das Routing zusammen. MAC-Adressen haben keine Geografie: Zwei Rechner nebeneinander haben völlig unterschiedliche Adressen, vergeben nach Hersteller und Produktionsreihenfolge. Man kann sie nicht zusammenfassen. Ein Router fasst heute Millionen Adressen in einer Zeile zusammen („alles mit diesem Präfix dorthin“); mit MAC-Adressen müsste er jede Netzwerkkarte der Welt einzeln kennen.

Mit nur IP-Adressen käme kein Gerät in Gang. Ein frisch gestarteter Rechner hat keine IP-Adresse; er fragt das Netz danach. Fragen heißt aber senden, und zum Senden braucht man eine Adresse. Den Kreis durchbricht die MAC-Adresse: Sie wird ab Werk geschrieben, braucht keine Konfiguration und ist da, bevor die Maschine irgendetwas weiß. Darauf baut DHCP auf: Der Server erkennt die Maschine ohne Adresse an ihrer MAC und bindet die Lease daran.

Der Beweis steht im gleich folgenden Mitschnitt und ist leicht zu übersehen: Die ARP-Zeile sagt ethertype ARP (0x0806), nicht IPv4 (0x0800). In diesem Frame gibt es überhaupt keinen IP-Header. ARP läuft neben IP, nicht darauf; anders ginge es nicht, denn seine Aufgabe ist, etwas zu finden, das IP noch nicht weiß.

Wie ARP funktioniert: eine Anfrage, eine Antwort

ARP ist eine Frage und eine Antwort: Die who-has-Anfrage geht als Broadcast hinaus, die is-at-Antwort kommt nur zum Fragenden zurück. Beide Wörter stehen wörtlich im Mitschnitt.

Der Aufbau: Auf ntp01 (192.168.1.15) habe ich den Cache-Eintrag für ldap01 (192.168.1.25) gelöscht, einen einzigen Ping geschickt und gleichzeitig mitgeschnitten. Erwartet war ein ARP-Austausch vor dem Ping.

sudo ip neigh flush dev ens33
ping -c 1 192.168.1.25

Achten Sie auf die Ziel-MAC am Anfang jeder Zeile, auf die Richtung von Frage und Antwort und auf die Zeitabstände:

20:29:59.271996 00:0c:29:a0:71:9a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806): Request who-has 192.168.1.25 tell 192.168.1.15
20:29:59.272559 00:0c:29:7c:79:af > 00:0c:29:a0:71:9a, ethertype ARP (0x0806): Reply 192.168.1.25 is-at 00:0c:29:7c:79:af
20:29:59.272572 00:0c:29:a0:71:9a > 00:0c:29:7c:79:af, ethertype IPv4 (0x0800): 192.168.1.15 > 192.168.1.25: ICMP echo request
20:29:59.273029 00:0c:29:7c:79:af > 00:0c:29:a0:71:9a, ethertype IPv4 (0x0800): 192.168.1.25 > 192.168.1.15: ICMP echo reply

Am häufigsten falsch gelesen wird tell: Es ist kein Befehl, es nennt den Absender. Die erste Zeile sagt genau: „Wer hat 192.168.1.25? Es fragt 192.168.1.15.“ Die zweite antwortet: „192.168.1.25 ist bei 00:0c:29:7c:79:af.“

1. Ziel der ersten Zeile ist ff:ff:ff:ff:ff:ff, also „alle“. Die Frage geht an jedes Gerät der Broadcast-Domäne.
2. Ziel der zweiten Zeile ist 00:0c:29:a0:71:9a. Die Antwort ist kein Broadcast; sie geht direkt an den Fragenden. Alle hören die Frage, nur der Fragende bekommt die Antwort.
3. Zwischen Zeile eins und zwei liegen 563 µs. Der Ping ist noch nicht einmal unterwegs.
4. Das ICMP-Paket in Zeile drei geht an die gerade gelernte MAC. Erst das Gesicht lernen, dann sprechen.

Fünf Sekunden später zeigte derselbe Mitschnitt noch einen Austausch:

20:30:04.627661 00:0c:29:7c:79:af > 00:0c:29:a0:71:9a: Request who-has 192.168.1.15 tell 192.168.1.25
20:30:04.627682 00:0c:29:a0:71:9a > 00:0c:29:7c:79:af: Reply 192.168.1.15 is-at 00:0c:29:a0:71:9a

Diesmal fragt die Gegenseite, aber anders als es zunächst aussieht. Das Ziel ist nicht ff:ff:ff:ff:ff:ff, sondern direkt 00:0c:29:a0:71:9a. ldap01 kannte die MAC von ntp01 bereits, denn eine ARP-Anfrage fragt nicht nur, sie trägt auch das eigene Adresspaar des Fragenden. Jede Maschine, die sie empfängt, kann es speichern, und ldap01 tat das: Es beantwortete den Ping im ersten Mitschnitt in 457 µs, ohne selbst zu fragen.

Was ist also der Austausch fünf Sekunden später? Kein Lernen, sondern eine Prüfung. Ein Betriebssystem traut einem mitgehörten Eintrag nicht ganz; wenn es sich zum ersten Mal wirklich darauf verlässt, prüft es einmal, ob die Gegenseite noch da ist. Unter Linux heißt die Wartezeit davor delay_first_probe_time und betrug auf ntp01 gemessen 5 Sekunden; der Abstand der beiden Austausche war 5,36 Sekunden. Die Prüfung selbst ist schnell: 21 µs zwischen Frage und Antwort.

Zwei Regeln folgen daraus. Erstens: Die Auflösung läuft in eine Richtung, die Information aber in beide; die Frage geht in eine Richtung, das Adresspaar landet auf beiden Seiten. Zweitens, im Feld nützlicher: Kennt die Gegenseite Sie nicht, lautet der Grund selten „sie hat nie gefragt“, sondern „Ihre Frage hat sie nie erreicht“. Dort sucht man bei Einbahnstörungen.

Der ARP-Cache und seine Zustände

Die Auflösung dauerte eine halbe Millisekunde. Billig, bis man sie sich für jedes Paket vorstellt: Jede Frage ist ein Broadcast, und ein Broadcast unterbricht alle im Raum. Deshalb speichert die Maschine, was sie lernt, im ARP-Cache.

Unter Linux gibt es zwei Befehle zum Lesen: arp -a ist der alte, ip neigh show sein moderner Ersatz. Beide lesen dieselbe Tabelle, sagen aber nicht dasselbe. Hintereinander auf derselben Maschine:

arp -a

? (192.168.1.25) at 00:0c:29:7c:79:af [ether] on ens33
? (192.168.1.1) at 60:d8:a4:a7:2e:99 [ether] on ens33
? (192.168.1.10) at <incomplete> on ens33
? (192.168.1.115) at ec:75:0c:9f:45:ea [ether] on ens33

ip neigh show

192.168.1.25 dev ens33 lladdr 00:0c:29:7c:79:af REACHABLE
192.168.1.1 dev ens33 lladdr 60:d8:a4:a7:2e:99 STALE
192.168.1.10 dev ens33 INCOMPLETE
192.168.1.115 dev ens33 lladdr ec:75:0c:9f:45:ea REACHABLE
fe80::1 dev ens33 lladdr 60:d8:a4:a7:2e:99 router STALE

Zwei Unterschiede, beide diagnostisch wichtig: Jede Zeile trägt jetzt einen Zustand, und es gibt eine Zeile mehr, fe80::1, einen IPv6-Nachbarn, den der alte Befehl nie zeigt. arp stammt aus dem alten Paket net-tools, kennt keine Zustände und nur IPv4; verwenden Sie ip neigh. Unter Windows bleibt es bei arp -a (mit dynamic/static statt Zustand) oder Get-NetNeighbor, das Zustände zeigt.

Die Zustände beschreiben, wie sehr die Maschine ihrem Wissen über den Nachbarn traut:

Der normale Kreislauf: Ein REACHABLE-Eintrag wird nach etwa 30 Sekunden STALE, bei Bedarf DELAY, wird bestätigt und ist wieder REACHABLE. FAILED ist die einzige Sackgasse, und dorthin führt nur eine unbeantwortete Frage.

Am häufigsten falsch gelesen wird STALE. Ein STALE-Eintrag ist nicht kaputt; die Maschine sagt nur, dass sie ihn länger nicht aufgefrischt hat. Sobald Verkehr fließt, wird er still bestätigt. Der Router (192.168.1.1) oben ist genau in diesem Zustand, und es fehlt nichts.

Eine zweite Momentaufnahme derselben Maschine, einige Minuten früher aufgenommen, zeigt auch den letzten Zustand der Tabelle:

192.168.1.1 dev ens33 lladdr 60:d8:a4:a7:2e:99 STALE
192.168.1.20 dev ens33 FAILED
192.168.1.10 dev ens33 FAILED
192.168.1.115 dev ens33 lladdr ec:75:0c:9f:45:ea REACHABLE
fe80::1 dev ens33 lladdr 60:d8:a4:a7:2e:99 router STALE

Der Unterschied zwischen INCOMPLETE und FAILED spart Zeit: INCOMPLETE heißt, die Maschine fragt noch; FAILED, sie hat aufgehört. Beides sagt „Gerät antwortet nicht“, aber das eine zeigt eine laufende Störung, das andere eine vergangene. Bei FAILED ist der Versuch längst vorbei, und der Eintrag bleibt einfach stehen, bis neuer Verkehr kommt.

Labor: drei Maschinen, drei verschiedene Arten zu schweigen

Seinen Wert zeigt der Cache bei einer Störung. Eine der verbreitetsten Annahmen lautet: „Ich pinge, keine Antwort, also ist das Gerät aus.“ Oft falsch, und ich habe gemessen, warum. Drei Maschinen im selben Netz, alle drei schwiegen, aber nicht aus demselben Grund.

Maschine eins, 192.168.1.25: die gesunde Referenz. Ping antwortet, Eintrag REACHABLE.

Maschine zwei, 192.168.1.10: ein ausgeschalteter Server.

PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
From 192.168.1.15 icmp_seq=1 Destination Host Unreachable
From 192.168.1.15 icmp_seq=2 Destination Host Unreachable

2 packets transmitted, 0 received, +2 errors, 100% packet loss

20:27:11.143707 00:0c:29:a0:71:9a > ff:ff:ff:ff:ff:ff: Request who-has 192.168.1.10 tell 192.168.1.15
20:27:12.167705 00:0c:29:a0:71:9a > ff:ff:ff:ff:ff:ff: Request who-has 192.168.1.10 tell 192.168.1.15

1. Destination Host Unreachable kommt von 192.168.1.15, der pingenden Maschine selbst. Kein Router meldet etwas; Ihr eigener Kernel sagt „ich bekomme dieses Paket nicht auf die Leitung, weil ich die MAC des Ziels nicht finde“. Wer das für eine Router-Meldung hält, sucht von Anfang an am falschen Ort.
2. Die Broadcast-Frage bleibt unbeantwortet und wiederholt sich jede Sekunde. Im Cache: INCOMPLETE, dann FAILED.

Maschine drei, 192.168.1.115: Hier bricht die Erwartung. Das Ping-Ergebnis sieht fast gleich aus:

PING 192.168.1.115 (192.168.1.115) 56(84) bytes of data.

3 packets transmitted, 0 received, 100% packet loss

Der Mitschnitt zeigt aber etwas ganz anderes:

20:28:43.518120 00:0c:29:a0:71:9a > ec:75:0c:9f:45:ea, ethertype IPv4: 192.168.1.15 > 192.168.1.115: ICMP echo request
20:28:44.519826 00:0c:29:a0:71:9a > ec:75:0c:9f:45:ea, ethertype IPv4: 192.168.1.15 > 192.168.1.115: ICMP echo request

192.168.1.115 dev ens33 lladdr ec:75:0c:9f:45:ea REACHABLE

Die ICMP-Pakete gehen an die richtige MAC, an ein einziges Ziel. ARP hat funktioniert. Unbeantwortet bleibt nicht ARP, sondern der Ping: Die Firewall dieser Maschine verwirft ICMP.

Die mittlere Spalte ist die These dieses Artikels: Ping kann schweigen, ARP nicht. Ping unterliegt einer Anwendung, einer Richtlinie und einer Firewall-Regel; ARP ist Pflicht, damit ein Frame überhaupt auf die Leitung kommt. Ein Gerät, das läuft und in derselben Broadcast-Domäne ist, muss ARP beantworten, sonst empfängt es nichts. Die praktische Folge dreht die übliche Reihenfolge um: Wenn „Ping geht nicht“, zuerst ip neigh, nicht die oberen Schichten.

Eine Frage, zwei Antworten: Linux antwortet für Adressen, die dort nicht liegen

Dieser Befund steht nicht im türkischen Original, und er entstand aus einer Messung, die zuerst schiefging.

Um zu testen, was passiert, wenn eine IP-Adresse auf eine neue MAC umzieht, bekam ntp01 eine zweite virtuelle Schnittstelle mit eigener MAC, und die Testadresse 192.168.1.99 wurde darauf gelegt. Der erste Durchlauf sah perfekt aus: Die Adresse zog um, der Beobachter verlor null Pakete. Zu perfekt. Der Mitschnitt einer einzigen Frage erklärte es:

ARP, Request who-has 192.168.1.99 tell 192.168.1.115
ARP, Reply 192.168.1.99 is-at 00:0c:29:a0:71:9a
ARP, Reply 192.168.1.99 is-at d6:76:8d:f7:d1:fb

Eine Frage, zwei Antworten, von zwei verschiedenen MAC-Adressen derselben Maschine. Die zweite kam von der Schnittstelle, die 192.168.1.99 tatsächlich trug. Die erste kam von ens33, der Hauptschnittstelle, die diese Adresse gar nicht hatte.

Das ist die Linux-Voreinstellung, das Weak-Host-Modell: Eine IP-Adresse gehört der Maschine, nicht einer Schnittstelle, also beantwortet der Kernel ARP für jede eigene Adresse auf jeder Schnittstelle, die die Frage hört. Dahinter steht arp_ignore mit dem Standardwert 0: „für jede lokale Adresse antworten“. Das Null-Verlust-Ergebnis war ein Artefakt; der Beobachter erreichte die Maschine immer über die Antwort, der er gerade glaubte. Mit arp_ignore=1 (nur antworten, wenn die Adresse auf der empfangenden Schnittstelle konfiguriert ist) verschwand die doppelte Antwort, und erst danach bedeutete die Messung etwas. Der erste Durchlauf wurde verworfen.

Warum das außerhalb des Labors zählt:

• Doppelte Antworten sind nicht automatisch ein Angriff. Ein Linux-Server mit zwei Schnittstellen im selben Segment kann dieselbe Frage zweimal beantworten, und die Tabellen im Spoofing-Abschnitt würden ihn als verdächtig markieren. Prüfen Sie arp_ignore, bevor Sie eskalieren.
• Verkehr kann über die „falsche“ Schnittstelle kommen. Welche Antwort ein Nachbar zuletzt glaubt, bestimmt, welches Kabel sein Verkehr nimmt.
• Ihr Test kann lügen. Wer unter Linux mit Standardeinstellungen einen Failover misst, riskiert, dass eine zweite Schnittstelle für die Adresse weiter antwortet und genau den Ausfall verdeckt, den er messen will.

Wer merkt sich wie lange? Drei Zähler auf einem Weg

Die im Feld meistgenannte Zahl ist fünf Minuten. Sie stimmt, wird aber meist der falschen Tabelle zugeschrieben. Auf dem Weg eines Frames liegen drei getrennte Zähler auf drei Geräten mit drei Laufzeiten:

Die erste Zeile heißt unter Linux base_reachable_time_ms, unter Windows BaseReachableTime; auf beiden habe ich 30000 gemessen. Die beiden anderen stammen vom Laborswitch:

console#show mac address-table

Aging time is 300 Sec

Vlan     Mac Address           Type        Port
-------- --------------------- ----------- ---------------------
1        F48E.381B.184D        Management  Vl1
5        5811.22B1.0E54        Dynamic     Gi1/0/1
5        F48E.381B.184D        Management  Vl5

Total MAC Addresses in use: 3

console#show arp

Age Time (seconds)............................. 1200
Response Time (seconds)........................ 1
Retries........................................ 4
Cache Size..................................... 1000
Dynamic Renew Mode ............................ Enable
Total Entry Count Current / Peak .............. 2 / 2

IP Address       MAC Address        Interface       Type      Age
---------------  -----------------  --------------  --------  -----------
192.168.1.2      F48E.381B.184D     Vl5             Local         n/a
192.168.1.224    5811.22B1.0E54     Vl5             Dynamic    0h  0m  0s

Die zweite Tabelle unterscheidet einen Switch von einem Hub: Der Switch lernt, welche MAC hinter welchem Port sitzt, indem er die Quelladresse durchlaufender Frames liest, und schickt jeden Frame nur über diesen Port hinaus. Den Dynamic-Eintrag oben hat niemand geschrieben. (Dieselbe Tabelle heißt auch CAM-Tabelle.)

Diese Zahlen sind Untergrenzen, keine Fristen. Ich habe die MAC-Tabelle gemessen: Nachdem eine Adresse vollständig aus dem Netz verschwunden war, stand ihr Eintrag in Sekunde 373 noch da und war in Sekunde 439 weg, trotz eingestellter 300. Switches durchlaufen die Tabelle periodisch und löschen einen Eintrag erst nach einem vollen ungenutzten Durchlauf; das tatsächliche Löschen liegt zwischen dem Ein- und Zweifachen des eingestellten Werts.

Labor: gleiche IP, neues Gerät. Wer merkt es wann?

Die Zähler schmerzen in einem häufigen Fall: Ein Gerät fällt aus, Sie bauen Ersatz ein und geben ihm dieselbe IP-Adresse. Die Adresse bleibt, die Hardware dahinter ändert sich. Jeder, der sich die Adresse gemerkt hat, hält jetzt einen falschen Eintrag, und niemand hat es ihm gesagt.

Genau das habe ich nachgebaut: 192.168.1.99 fest, MAC dahinter getauscht, die alte vollständig entfernt. Das neue Gerät kündigte sich nicht an, weil diese Runde den Fall ohne Ankündigung maß. Dann beobachtete ich zwei Geräte, die die Adresse suchten.

Der Arbeitsplatz erholte sich in etwa fünf Sekunden:

17:24:13  OK     D6-76-8D-F7-D1-FB  Probe
17:24:18  KAYIP  D6-76-8D-F7-D1-FB  Unreachable
17:24:23  OK     52-57-6E-C6-D0-81  Reachable

(KAYIP ist türkisch für „verloren“; das Überwachungsskript war auf Türkisch geschrieben.) Der Eintrag fiel auf Probe, dann Unreachable; die Maschine fragte per Broadcast neu, lernte die richtige MAC und machte weiter. Verlust: ein Paket.

Der Switch brauchte einundzwanzig Minuten. Sechs Minuten nach dem Tausch:

console#ping 192.168.1.99
 Pinging 192.168.1.99 with 0 bytes of data:

----192.168.1.99 PING statistics----
4 packets transmitted, 0 packets received, 100% packet loss

console#show arp
IP Address       MAC Address        Interface       Type      Age
---------------  -----------------  --------------  --------  -----------
192.168.1.99     1A4A.ED68.B905     Vl5             Dynamic    0h  6m 15s

Der Eintrag fiel genau mit Ablauf von Age Time, keine Sekunde früher. Über vier Runden ohne Antwort fragte der Switch kein einziges Mal neu; Dynamic Renew Mode war an und änderte nichts, denn es löst beim Ablauf des Zählers neu auf, nicht beim Ausbleiben von Antworten.

Die praktische Übersetzung: Ziehen Sie eine Kamera oder einen Access Point auf eine neue Adresse um, erreicht Ihr Laptop ihn sofort, ein anderes Gerät im Netz findet ihn womöglich zwanzig Minuten lang nicht. Beide arbeiten wie vorgesehen; das eine fragt neu, das andere nicht. Denken Sie daran, wenn jemand sagt „bei mir geht’s“.

Die Broadcast-Domäne: wo ARPs Wand endet

Alles Bisherige hängt an einer Bedingung: derselben Broadcast-Domäne. Erreicht die ARP-Anfrage das Ziel nicht, wird keine MAC gelernt und kein Frame gebaut. Eine Broadcast-Domäne ist der größte Bereich, den ein Broadcast erreicht, und damit genau ARPs Reichweite. In den meisten Firmennetzen ist die Wand kein Kabel, sondern ein Tag an den Frames: das Thema des VLAN-Artikels.

Wie real das ist, zeigt ein 30 Sekunden langer Mitschnitt auf ntp01, ohne selbst etwas zu tun:

sudo tcpdump -i ens33 -n "arp"

20:25:30.133858 ARP, Request who-has 192.168.1.158 tell 192.168.1.115
20:25:38.766755 ARP, Request who-has 192.168.1.15 tell 192.168.1.1
20:25:38.869127 ARP, Request who-has 192.168.1.25 tell 192.168.1.1
20:25:38.971489 ARP, Request who-has 192.168.1.30 tell 192.168.1.1

Nichts davon stammt von mir. Wir hören alles, weil wir im selben Raum sind. Eine Broadcast-Domäne ist keine Abstraktion; sie ist das Rauschen, das Sie hören, wenn Sie zuhören.

Labor: zwei Geräte „im selben Netz“, zwei Broadcast-Domänen

Hier kommt im Feld ein berechtigter Einwand: Hat der Switch 192.168.1.2/24, ist er doch im selben Netz; wie kann er unerreichbar sein? Die Antwort liegt woanders als erwartet. Alle fünf beteiligten Adressen lagen in 192.168.1.0/24:

Unter Windows zeigt dieser Befehl die Nachbartabelle samt Schnittstelle, auf der aufgelöst wurde:

Get-NetNeighbor -IPAddress 192.168.1.2, 192.168.1.1

InterfaceAlias IPAddress   LinkLayerAddress        State
-------------- ---------   ----------------        -----
Wi-Fi          192.168.1.2 00-00-00-00-00-00 Unreachable
Wi-Fi          192.168.1.1 60-D8-A4-A7-2E-99   Reachable
Ethernet       192.168.1.2 F4-8E-38-1B-18-4D   Reachable
Ethernet       192.168.1.1 00-00-00-00-00-00  Incomplete

00-00-00-00-00-00 ist keine MAC-Adresse, sondern ein leeres Feld. Die Antworten liegen über Kreuz: Der Router antwortet nur auf der WLAN-Seite, der Switch nur am Kabel. Zwei Adressen, eine Ziffer auseinander, dieselbe Maske, verschiedene Leitungen. Vom Arbeitsplatz aus gehen beide Pings, weil er in beiden Domänen einen Fuß hat. Auf ntp01 mit nur einer Schnittstelle:

sudo ip neigh flush dev ens33
ssh ilker@192.168.1.2

ssh: connect to host 192.168.1.2 port 22: No route to host

Dann die Nachbartabelle:

ip neigh show dev ens33

192.168.1.1    lladdr 60:d8:a4:a7:2e:99 REACHABLE
192.168.1.115  lladdr ec:75:0c:9f:45:ea REACHABLE
192.168.1.2                             FAILED
192.168.1.224                           INCOMPLETE

Vier Adressen, alle vier im selben /24, zwei gefunden, zwei nicht. Router und WLAN-Schnittstelle des Arbeitsplatzes sind REACHABLE; der Switch ist FAILED, die Ethernet-Schnittstelle des Arbeitsplatzes INCOMPLETE. Die beiden fehlenden Adressen haben nur eines gemeinsam: Sie liegen am anderen Ende des Kabels.

Das ist die Antwort auf den Einwand. ntp01 hält 192.168.1.2 wegen seiner Maske für das eigene Netz, gibt das Paket also nicht dem Router, sondern fragt direkt per ARP und wartet. Es kommt keine Antwort. Läge der Switch in einem anderen Block, etwa 192.168.99.2, hätte ntp01 das Paket ans Gateway gegeben. „Im selben Netz“ ist hier keine Garantie, sondern die Ursache der Störung. Die Maske sagt „Nachbar“, das Kabel sagt „nein“, und ARP glaubt dem Kabel.

Die Tabelle hat noch eine Zeile, und sie allein trägt die These dieses Artikels. Von derselben Maschine habe ich die WLAN-Adresse des Arbeitsplatzes angepingt:

ping -c 2 192.168.1.115

2 packets transmitted, 0 received, 100% packet loss, time 1031ms

Der Ping bleibt völlig stumm, doch der Nachbareintrag derselben Adresse ist REACHABLE, mit der richtigen MAC-Adresse. Das Gerät ist da; die Windows-Firewall verwirft ICMP: Das Paket wird stillschweigend weggeworfen, nicht einmal eine Fehlermeldung kommt zurück. Ping kann schweigen, ARP nicht. In dieser Tabelle stehen beide nebeneinander.

Topologie: ARPs verborgene Rechnung

Ein Router beendet eine Broadcast-Domäne; ein Switch erweitert sie standardmäßig. Wer die Grenze auf einem Switch ziehen will, nimmt ein VLAN. ARPs Reichweite legt also nicht das Protokoll fest, sondern Sie, durch Verkabelung und Gerätewahl.

Hintereinander gesteckte Switches. Eine der schwierigsten Topologien meiner Laufbahn: Switches in Reihe, jeder neue Bedarf in den freien Port des vorigen gesteckt, bis die Leistung des ganzen Standorts litt. Solche Ketten sammeln drei Kosten an. Die Bandbreite: Der Verkehr aller Geräte am letzten Switch muss durch jeden Uplink. Eine einzige Broadcast-Domäne: Jedes who-has durchquert jeden Switch und erreicht jede Netzwerkkarte. Und Druck in den Switches: Jeder muss jede Adresse lernen; ist die MAC-Tabelle voll, flutet er Frames für unbekannte Ziele aus allen Ports und verhält sich für diese Frames wie ein Hub.

Warum ein „dummer Switch“ die ARP-Diagnose blind macht. Ein unmanaged Switch ist nicht dumm: Er hat eine MAC-Tabelle und leitet richtig weiter. Ihm fehlt nur die Fähigkeit, Ihnen zu antworten. Die ARP-Tabelle sagt, welche MAC geantwortet hat; welche Leitung dazu gehört, steht in der Switch-Tabelle. Ohne sie haben Sie eine MAC-Adresse und keine Ahnung, wo im Gebäude sie steckt. Finden können Sie ihn trotzdem, über den verwalteten Switch darüber: Ein Port sieht normalerweise eine MAC-Adresse; zeigt er mehrere, vervielfältigt dahinter etwas Frames.

Vlan     Mac Address           Type        Port
-------- --------------------- ----------- ---------------------
5        000C.29A0.719A        Dynamic     Gi1/0/2
5        5811.22B1.0E54        Dynamic     Gi1/0/2
5        EEA7.58A3.9726        Dynamic     Gi1/0/2

Drei Adressen an einem Port; hier war es ein Arbeitsplatz mit VMs, aber die Signatur ist dieselbe, und die Kandidaten sind wenige: ein unmanaged Switch unterm Tisch, ein Virtualisierungshost, ein IP-Telefon mit PC-Port oder ein Access Point.

Gratuitous ARP: sprechen, ohne gefragt zu sein

Bisher beantwortete jede ARP-Antwort eine Frage. Das Protokoll erlaubt auch, ungefragt zu sprechen: Gratuitous ARP. Ein Gerät kündigt seine eigene Adresse an. Das dient der Erkennung von Adresskonflikten beim Start, dem Auffrischen fremder Caches und der Übergabe, wenn in redundanten Systemen eine virtuelle Adresse die Maschine wechselt.

Die Übergabe sieht auf dem Papier sauber aus. Gemessen war sie es nicht. Die Ankündigung ging tatsächlich hinaus:

ARP, Request who-has 192.168.1.99 tell 192.168.1.99

Quelle und Ziel gleich: die Signatur eines Gratuitous ARP. Der Arbeitsplatz im selben Netz ignorierte sie aber. Die alte MAC blieb weitere 19 Sekunden im Cache und änderte sich erst, als die Maschine ihre eigene Prüfrunde beendet und selbst gefragt hatte. Das ist kein Fehler, sondern Absicht: Einen gültigen Eintrag wegen einer unaufgeforderten Ankündigung zu ersetzen, hieße, ARP-Spoofing zu verschenken. Betriebssysteme behandeln die Ankündigung als Hinweis, nicht als Befehl.

Hier stecken zwei getrennte Entscheidungen, und in der Praxis werden sie ständig verwechselt. Was passiert, wenn eine Ankündigung für eine Adresse ohne jeden Eintrag eintrifft, ist die eine Frage; unter Linux entscheidet das arp_accept, und standardmäßig wird kein neuer Eintrag angelegt. Ob ein bestehender Eintrag durch eine Ankündigung überschrieben wird, ist eine andere Frage, und genau das wurde oben gemessen: Der Eintrag existierte, die Ankündigung kam, der Eintrag blieb. Der Arbeitsplatz wartete auf seine eigene Prüfrunde, nicht auf die Ankündigung. Praktische Folge: arp_accept zu ändern verkürzt diese 19 Sekunden nicht, denn sie bestimmt der eigene Prüfzähler der Maschine, nicht diese Einstellung.

Auch auf der Senderseite gab es eine Überraschung, die im türkischen Original fehlt. Linux hat eine Einstellung, die solche Ankündigungen senden soll: arp_notify. Eingeschaltet, fügte ich einer laufenden Schnittstelle eine Zweitadresse hinzu und zählte die Gratuitous ARPs auf der Leitung: null. Die Einstellung greift, wenn eine Schnittstelle hochfährt, nicht wenn einer laufenden eine Adresse hinzugefügt wird. Verlässt sich Ihr Failover-Design darauf, dass arp_notify eine wandernde Adresse auf einer aktiven Schnittstelle ankündigt, prüfen Sie es mit einem Mitschnitt; der Name verspricht mehr, als die Einstellung hält.

Praktisch heißt das: Der Sender muss ankündigen, und prüfen Sie auf der Leitung, dass er es tut. Den Empfängern vertrauen Sie nicht blind; wer gelernt hat, zeigen nur deren Tabellen. Genau deshalb dauern Failovers redundanter Firewalls oder Load Balancer manchmal Minuten statt Sekunden: Die Ankündigung wurde nicht blockiert, ihr wurde nicht zugehört.

ARP-Spoofing: der Preis für fehlende Ausweiskontrolle

Gratuitous ARP wirft eine Frage auf: Ein Gerät kann ungefragt seine Adresse ankündigen, und andere glauben es. Woher wissen sie, dass es stimmt? Gar nicht. ARP hat keine Authentifizierung.

Angreifer lieben nicht ARP, sondern dass man es nicht abschalten kann. Abschalten heißt, das Netz steht still. Es antwortet immer, auch wenn eine Firewall ICMP verwirft. Es muss nicht auf eine Frage warten. Und es hinterlässt keine Spur. Die Kehrseite, aus der die Verteidigung entsteht: Das alles gilt nur, wenn der Angreifer bereits in der Broadcast-Domäne ist. ARP überquert keine Router. Segmentierung verhindert den ersten Schritt nicht, aber sie verkleinert den Raum, in den er führt.

Hier bricht die Metapher: Im echten Raum kann niemand für einen anderen die Hand heben, weil man sich an Gesichtern erkennt. ARP hat keine Gesichtserkennung. ARP-Spoofing heißt, dass ein Angreifer für die IP-Adresse eines anderen antwortet, um dessen Verkehr über die eigene Maschine zu leiten: Er sagt dem Opfer „die MAC des Gateways bin ich“, dem Gateway „die MAC des Opfers bin ich“, und beide Seiten aktualisieren ihre Tabellen. Pakete kommen weiter an, also sehen beide normalen Betrieb. Es ist der billigste Weg in eine Man-in-the-Middle-Position.

Dynamic ARP Inspection kommt zuerst, weil sie den Schutz ins Netz verlegt. Aber nicht sofort erzwingen: Vertrauenswürdige Ports markieren, im Überwachungsmodus laufen lassen, Protokolle lesen, dann erzwingen. Und wie oben gemessen, kann ein Linux-Host mit zwei Schnittstellen genau so aussehen, wie DAI es fangen soll; kennen Sie Ihre mehrfach angebundenen Hosts vorher. Keine dieser Maßnahmen macht ARP sicher; die eigentliche Verteidigung ist, dass abgefangener Verkehr unlesbar ist: verschlüsselte Protokolle.

Diagnose mit ARP: welche Ausgabe was bedeutet

Alles läuft auf eine Gewohnheit hinaus: Bei Verbindungsproblemen ip neigh vor dem Ping lesen.

Die letzte Zeile steht absichtlich da. Viele leeren die Tabelle, weil sie STALE sahen, und glauben, etwas repariert zu haben. Leeren schadet nicht, repariert aber nichts.

Diese ganze Tabelle schaut auf den ARP-Eintrag. Ein Symptom fehlt, und es taucht hier nie auf: mehrere MAC-Adressen an einem Switch-Port. ip neigh kennt keine Ports, dort sehen Sie es also nicht; es erscheint nur in der Tabelle des Switches selbst und sagt, dass hinter diesem Port ein Gerät Frames vervielfacht. Was das bedeutet und wie man es eingrenzt, steht im Abschnitt über den unverwalteten Switch.

Wenn Sie leeren müssen: unter Windows (erhöhte Rechte nötig; ohne sie antwortete die Labormaschine mit türkischem Windows Erişim engellendi, also „Zugriff verweigert“; die PowerShell-Entsprechung Remove-NetNeighbor braucht dieselben Rechte) arp -d * oder arp -d 192.168.1.25, unter Linux:

sudo ip neigh flush dev ens33
sudo ip neigh del 192.168.1.25 dev ens33

In der Messung war ein gelöschter Eintrag nach einer halben Millisekunde wieder da. Riskant ist nur ein falscher statischer Eintrag: Er überlebt das Löschen. Genau das ist auch seine Signatur. Windows zeigt static statt dynamic bzw. Permanent, unter Linux endet die Zeile auf PERMANENT und übersteht flush. Auch die Befehle, die einen solchen Eintrag von Hand setzen, sind einzeilig: arp -s unter Windows, ip neigh ... nud permanent unter Linux. Statische Einträge taugen, um eine Zuordnung während der Diagnose festzunageln, nie als Dauerlösung; stehen gelassen, werden sie die Störung, deren Grund sich in sechs Monaten niemand mehr erklären kann.

Fazit: was das leiseste Protokoll verrät

ARP ist das leiseste Protokoll in Ihrem Netz. Keine Einstellungsseite, kein Protokoll, niemand bemerkt, dass es läuft. Aber wenn es ausfällt oder belogen wird, reißt es jede Schicht darüber mit.

Vier Messergebnisse zahlen sich im Feld aus:

• Ping kann schweigen, ARP nicht. Ein unbeantworteter Ping beweist nicht, dass ein Gerät aus ist; eine Zeile ip neigh sagt, was los ist.
• Derselbe Adressblock ist nicht dieselbe Broadcast-Domäne. Zwei Geräte können in einem /24 sitzen und sich nie hören.
• ARP verlangt keinen Ausweis. Es glaubt Antworten, und das ist Design, kein Fehler. Die Verteidigung liegt im Switch und in der Verschlüsselung.
• Linux antwortet standardmäßig auf jeder Schnittstelle für seine Adressen. Eine Frage kann zwei Antworten bekommen, und das kann im Test einen Ausfall verdecken oder im Betrieb wie ein Angriff aussehen.

ARP ist nicht unbekannt, es wird nur nicht angesehen. Doch wenn die Störung kommt, ordnet ein einziges Wort in der Ausgabe von ip neigh ein Problem ein, das sonst tagelang in der falschen Schicht gesucht würde.