☰

iptables: unterschiedliche Regeln für unterschiedliche aktuelle Gateway-IPs

tag-icon • tag-icon linux networking iptables
iptables: unterschiedliche Regeln für unterschiedliche aktuelle Gateway-IPs

Angenommen, ich habe Maschine A als Gateway. Maschine A hat eine Schnittstelle mit 2 IPs.

Die Netplan-Konfiguration für Maschine A sieht folgendermaßen aus:

  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
      addresses:
        - 192.168.1.1/24
        - 192.168.1.2/24

Jetzt möchte ich, dass sich die REDIRECT-Regeln von iptables unterschiedlich verhalten, je nachdem, ob Maschine B ihr Gateway auf 192.168.1.1 oder 192.168.1.2 einstellt

Dies ist der iptables-Befehl, den ich auf Maschine A ausführen möchte:

iptables --table nat --append PREROUTING --some-parameter 192.168.1.1 --protocol tcp  --jump REDIRECT --to-ports 9991
iptables --table nat --append PREROUTING --some-parameter 192.168.1.2 --protocol tcp  --jump REDIRECT --to-ports 9992

Können Sie mir bitte sagen, wie der --some-parameter oben genannte Name korrekt lautet?

Antwort1

Dies ist nicht möglich, wenn 192.168.1.1 und 192.168.1.2 auf derselben Netzwerkschnittstelle des Gateways liegen und somit dieselbe MAC-Adresse ergeben. Es handelt sich nicht um eine Funktion, die nicht iniptablesdas könnte zwar implementiert werden, es handelt sich jedoch um eine Funktion, die aufgrund der Funktionsweise von IP-Netzwerken nicht implementiert werden kann.

Ein Client, der 192.168.1.1 oder 192.168.1.2 als Gateway verwendet, wird beim Senden von Paketen ins Internet niemals ein einzelnes IPv4-Paket mit 192.168.1.1 oder 192.168.1.2 darin senden. Er wird:

  • die Routing-Tabelle für ein bestimmtes Ziel konsultieren
  • finde heraus, dass es ein Gateway für dieses Ziel gibt
  • VerwendenARPoder ein zwischengespeicherter Eintrag zum Auflösen der L2-Adresse (Ethernet-MAC-Adresse), die zum Erreichen des Gateways erforderlich ist.

Der letzte Schritt hat nur ein Ethernet-Ziel: die eindeutige MAC-Adresse der Netzwerkkarte des Gateways: dasselbe gilt für einen Client mit Gateway 192.168.1.1 oder einen anderen Client mit Gateway 192.168.1.2.

Daher sendet nun jeder Client ein Paket mit seiner IPv4-Quelladresse an das Gateway, wobei das beabsichtigte IPv4-Ziel in einem Ethernet-Frame in beiden Fällen dieselbe Ethernet-MAC-Zieladresse hat. 192.168.1.1/192.168.1.2 ist nicht in der Schleife.

Das Gateway sieht nun zwei Pakete, die weitergeleitet werden müssen. In keinem Fall geben diese Pakete mehr Aufschluss darüber, ob sie das Gateway verwenden 192.168.1.1oder 192.168.1.2als Gateway fungieren: Die Information erscheint nicht auf dem Kabel und kann daher vom Gateway nirgendwo erkannt werden. Wenn das System keine Informationen hat, um die Fälle zu unterscheiden, danniptableskann diese nicht vorhandenen Informationen auch nicht haben.

Vorschlag zur Problemumgehung:

Man kann einMACVLANSchnittstelle, um eine zweite Netzwerkkarte mit eigener separater MAC-Adresse zu haben und dieser stattdessen 192.168.1.2/24 zuzuweisen, wodurch Pakete von Clients, die 192.168.1.2 als Gateway verwenden, stattdessen auf dieser Netzwerkkarte ankommen. Dieser Fall lässt sich leicht unterscheiden mitiptables: ein anderer -i NICFilter.

Dadurch entsteht jedoch das Routingproblem, das entsteht, wenn sich mehrere Netzwerkkarten im selben LAN befinden, und es ist entweder Folgendes erforderlich:

  • Erweiterte Policy-Routing-Regeln, um diesen Fall richtig zu behandeln

    Damit werden Antworten nicht über die falsche Netzwerkkarte gesendet, was möglicherweise das Routingverhalten oder die Firewall-Regeln beeinträchtigen könnte.

    • und außerdem muss jeder UDP-Dienst, der unter 192.168.1.2 abgefragt wird (wenn 192.168.1.1 die Standardadresse ist), wissen, wie er mit der korrekten Quelladresse 192.168.1.2 (anstelle der Standardadresse 192.168.1.1) antwortet: Er muss Multi-Homed-fähig sein. TCP erfordert keine besondere Sorgfalt.

  • oder ein zusätzlicher Netzwerk-Namespace, um die hinzugefügte Schnittstelle zu trennen. Aber mit einer REDIRECT-Regel bedeutet das, dass der Dienst auf Port 9992 stattdessen im zusätzlichen Netzwerk-Namespace laufen muss. Und dieser Netzwerk-Namespace muss wahrscheinlich immer noch über den anfänglichen Netzwerk-Namespace mit dem Internet kommunizieren: auch mehr Konfiguration, die an verschiedenen Stellen geplant werden muss.

verwandte Informationen