Wow. Also das Linux manchmal bizarr broken ist, ist ja eigentlich bekannt, aber heute habe ich eine ganz neue Dimension kennengelernt.

Es geht um eine Box mit einem physikalischen Interface und einem virtuellen (für OpenVPN). Das Ethernet hat IP 10.1.1.1/24, das OpenVPN-Interface 192.168.1.1/28. Nun hat Linux die bescheuerte Eigenschaft, auf jedem Interface ARP-Requests für alle IPs auf allen Interfaces zu beantworten. Was für ein Quark.

Im aktuellen Fall ist in dem Ethernet halt parallel noch ein zweites Netz mit einer Kiste auf 192.168.1.1 - Über den Sinn von zwei verschiedenen Netzen auf einem Ethernet kann man sich streiten, nur entzieht sich dieser Aspekt leider derzeit der Kontrolle (blöder ISP). Und da ist es natürlich eher kontraproduktiv, daß die Linux-Kiste unpassende ARPs verschickt.

Andere OSe (FreeBSD, *BSD, SunOS ...) machen es natürlich richtig, und schicken ARPs nur auf dem jeweils dazu passenden Interface raus.

Aber wartet, es kommt noch besser. :-)

Linux-Benutzer leben ja nicht hinter dem Mond, und drum ist das auch schon ein paar mal aufgefallen. In Google finden sich auch lauter Mails, besonders um 2003 rum, die das diskutieren. Fazit ist, daß TPTB das nicht ändern wollen und zwar weil, haltet euch fest:

• Blocking ARP responses in this way is putting filtering decisions at the wrong layer of the networking code. This sort of action belongs at the netfilter level, rather than down at the device level.
• Linux's approach to ARP responses is fully compliant with all applicable RFCs.
• In some situations, responding out of all interfaces is the only way to successfully get communication established.
• For situations where the default ARP behavior causes problems, the arp_filter sysctl knob can be used to change things.

Zusammengefasst also etwa: Unser Code ist scheiße, da kriegen wir das nicht sauber hin, es gibt auch Fälle da will man so ein kaputtes Verhalten, und außerdem erlaubt uns die RFC das. Achja, und arp_filter: Na gut, na gut, ihr habt so geschrieen, also haben wir es doch noch reingehackt.

Nur das arp_filter was ganz anderes tut, und komplett unbrauchbar ist. Es filtert eingehende ARP Anfragen. Kommt die Anfrage nach 192.168.1.1 auf dem Ethernet an und hat eine Source-IP von 192.168.1.2, wird sie nicht beantwortet, weil das Netz dazu ja auf das OpenVPN Interface geroutet wird. Kommt das Paket allerdings von 10.1.1.2, wird es beantwortet. Denn dann kommt es ja laut routing-Tabelle von der richtigen IP.

Häh? Was haben die denn da geraucht? Das hilft genau garnix. Nehmen wir an, die fremde Kiste mit der IP 192.168.1.1 hat als Netz ein /24 – Wir hatten (siehe oben) ja nur ein /28. Kommt die Anfrage nun von 192.168.1.250, beantworten wir sie plötzlich. Warum? Wir haben ja eine defaultroute auf dem Ethernet!

GnaGnaGnaGnaGna!

Und was freut man sich beim Googlen über all die Leute, die mit dem Verhalten auch ein Problem haben. Man findet FAQs zu dem Thema die dann auf lauter Patches verweisen, die es da dann brav für alle erdenklichen Kernelversionen gibt.

Hallo, ist euch das nicht peinlich?

– Sec