Ubuntu Linux - mehrere NICs, dasselbe LAN… ARP-Antworten gehen immer auf eine einzige NIC hinaus

Wir haben den Internetdienst AT & T U-Verse, der über ein extrem leistungsfähiges DSL-Gateway verfügt.

Wir haben 5 IPs (Netzmaske 248), aber das Gateway kann nichts anderes als eine einzelne IP -> einzelne MAC-Adressenzuordnung ausführen.

Wir haben eine einzige Firewall-Maschine und leiten verschiedene IP / Port-Kombinationen an verschiedene Stellen innerhalb einer DMZ um.

Unsere bisherige Lösung besteht darin, eine virtuelle VMWare-Maschine in der Firewall mit 4 zusätzlichen NICs zu haben, um die anderen 4 IP-Adressen abzurufen. Wir haben jedoch ein Problem.

Das Gateway führt im Grunde genommen einen ARP-Ping durch, um festzustellen, ob die IP auf dem erwarteten MAC antwortet. Mit 4 NICs im selben LAN antwortet Linux auf ARP-Anfragen für ALLE IPs über eine einzige Schnittstelle. Das erwartet das Gateway nicht und bringt die drei anderen Netzwerkkarten durcheinander. Das Gateway weigert sich, eingehenden Datenverkehr für IP-Adressen weiterzuleiten, bei denen die ARP-Ping-Ergebnisse nicht die erwarteten MAC-Adressen sind.

Wie können wir die ARP-Antworten für eth0s IP erhalten, um eth0, eth1s IP, um eth1, usw. auszugehen?

BEARBEITEN

Christopher Cashells Antwort funktioniert in dieser Situation nicht. Ich hatte große Hoffnungen, es zu lesen, aber ... nein.

BEARBEITEN 2

Gelöst! Siehe meine Antwort unten.

Die von Ihnen gewählte Lösung funktioniert, aber es gibt Alternativen, bei denen keine Arptables verwendet werden. (Christopher Cashell war ursprünglich auf dem richtigen Weg, aber er war mit einem Kuss daneben.)

Kurz gesagt, Sie möchten die folgenden Parameter festlegen:

net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

Diese sollten verfügbar sein, wenn ein moderner Linux-Kernel der 2.6-Serie ausgeführt wird. Überprüfen Sie, ob auf Ihrem System '/ proc / sys / net / ipv4 / conf / / arp_announce' und / proc / sys / net / ipv4 / conf / / arp_ignore 'vorhanden sind.

Der Parameter 'arp_filter' funktioniert nur, wenn Ihre verschiedenen IP-Adressen ein LAN-Segment gemeinsam nutzen, aber ein anderes IP-Subnetz verwenden. Wenn sie sich auch das IP-Subnetz teilen, müssen Sie 'arp_ignore' und 'arp_announce' wie oben verwenden.

(Ich glaube, Sie müssen möglicherweise auch 'arp_filter' auf '0' zurücksetzen.)

Okay, hier ist die Lösung. Zunächst eine Zusammenfassung:

Hier ist mein grundlegender Netzwerkplan:

 eth0 10.10.10.2 netmask 255.255.255.248
 eth1 10.10.10.3 netmask 255.255.255.248
 eth2 10.10.10.4 netmask 255.255.255.248
 eth3 10.10.10.5 netmask 255.255.255.248

Alle Schnittstellen überlappen sich. Das ist technisch falsch und die Ursache all meiner Leiden ... aber ich muss es tun, weil dieses dumme Tor zu Wohngebieten ist.

Erstens gehen Broadcast-ARP-Anforderungen an alle diese. Da alle 4 IPs gültige lokale Adressen sind, werden alle 4 Schnittstellen versuchen zu antworten.

1) Installieren Sie Arptables . Fügen Sie dies während des Bootens hinzu ( /etc/rc.local hier):

arptables -F INPUT
arptables -A INPUT -i eth0 --destination-ip ! 10.10.10.2 -j DROP
arptables -A INPUT -i eth1 --destination-ip ! 10.10.10.3 -j DROP
arptables -A INPUT -i eth2 --destination-ip ! 10.10.10.4 -j DROP
arptables -A INPUT -i eth3 --destination-ip ! 10.10.10.5 -j DROP

Dies verhindert, dass Broadcasts in die falsche Schnittstelle gelangen. Die richtige Schnittstelle ist nun der einzige Antwortende.

Das allein reicht nicht aus. Das nächste Bit ist ein ARP-Tabellenproblem. Der anfragende PC hat wahrscheinlich bereits einen ARP-Tabelleneintrag, und daher wird Linux die dazugehörige Schnittstelle verwenden. Bis dieser ARP-Tabelleneintrag abläuft, wird versucht, ARP-Antworten über die Schnittstelle dieses Eintrags zu senden, nicht über die der ARP-Anforderung zugeordnete.

Die sysctl-Option rp_filter scheint ausgehende ARP-Antwortpakete abzulehnen, wenn sie sich auf der falschen Schnittstelle befinden. So...

2) Deaktiviere rp_filter .

Unter Debian / Ubuntu, kommentiert diese Mittel , um die beiden aus rp_filter Linien in /etc/sysctl.d/10-network-security.conf .

Diese Option wurde aus einem bestimmten Grund aktiviert, um übergreifende Spoofing-Angriffe zu verhindern. Ich habe gelesen, dass es überprüft, ob das Paket für die Schnittstelle, an der es eingeht oder ausgeht, zulässig ist (indem ich MACs und IPs vertausche und prüfe, ob es immer noch über dieselbe Schnittstelle geleitet wird). Normalerweise wäre es also eine schlechte Idee, es auszuschalten. In meinem Fall befinden sich alle Schnittstellen im selben Netzwerk ... so dass die Überprüfung überhaupt keine Rolle spielt.

Wenn ich eine weitere Schnittstelle hinzufüge und den Spoofing-Schutz benötige, können möglicherweise einige arptables / iptables- Einträge erstellt werden, um dasselbe zu tun.

Dies hängt damit zusammen, wie Linux mit IPs und NICs umgeht. Grundsätzlich wird eine IP-Adresse so behandelt, als gehörte sie zur Box und nicht nur zur spezifischen Netzwerkkarte. Das Ergebnis ist, dass Sie ARP-Antworten von IP-Adressen auf Schnittstellen erhalten können, die Sie nicht erwarten würden.

Die Lösung ist eine Sysctl-Option. Soweit ich mich erinnere, suchen Sie:

net.ipv4.conf.default.arp_filter=1
net.ipv4.conf.all.arp_filter=1

Das wird das Problem für Sie beheben. Fügen Sie diese einfach zu /etc/sysctl.conf hinzu und führen Sie ' sysctl -p' aus (oder führen Sie jede Zeile als Argument für ' sysctl -w' aus.

Dadurch antwortet Linux nur auf ARP-Anfragen auf der Schnittstelle, der tatsächlich eine IP-Adresse zugewiesen ist.

Die akzeptierte Antwort in Kombination damit: http://www.linuxquestions.org/questions/linux-networking-3/multiple-interfaces-all-traffic-flows-through-just-one-538701/

Wo statische Routen verwendet werden, um nur mit gewünschten IPs über bestimmte Schnittstellen zu kommunizieren, entstand eine leistungsstarke und einfache Lösung für ein ähnliches Problem, das ich hatte.

Können Sie das Gateway überbrücken und die Firewall die IPs verwalten lassen?