Antwortpaket auf derselben Schnittstelle wie eingehend im LAN

Question

Derzeit kämpfe ich mit dem folgenden Szenario:

• Ich habe einen Server mit 2 Schnittstellen in 2 separaten LAN-Subnetzen. IF1, IF2
• Ich habe einen Laptop, der eine IP-Adresse aus dem ersten Subnetz hat
• Wenn ich versuche, von diesem bestimmten Laptop aus eine Verbindung zur zweiten IP-Adresse des Servers herzustellen, erhalte ich überhaupt keine Antwort.

Wenn ich beispielsweise versuche, vom Laptop mit der IP 172.31.190.129 aus einen Ping an 172.31.196.185 zu senden, kann ich eingehende Anfragen im TCPdump auf der Schnittstelle ens224 sehen, danach gibt es aber auf keiner anderen Schnittstelle eine Antwortanforderung.

Hier ist mein Netzwerkdiagramm:

       +-------------------------+
       |                         |
       |  Laptop 172.31.190.129  +---------+
       |                         |         |
       +-------------------------+         |
                                           |                 +-------------------------+
                                           |                 |                         |
                               +-----------+---------+       |       Linux Server      |
                          +----+                     |       |                         |
                          |    | LAN 172.31.190.0/23 +-------+ IF1  -  default gw      |
                   +------+--+ |                     |       | 172.31.190.63           |
    +----------+   |         | +---------------------+       |                         |
    | Internet +---+ Gateway |                               |                         |
    +----------+   |         | +---------------------+       |                         |
                   +------+--+ |                     |       |                         |
                          |    | LAN 172.31.196.0/23 +-------+ IF2                     |
                          +----+                     |       | 172.31.196.185          |
                               +---------------------+       |                         |
                                                             |                         |
                                                             |                         |
                                                             +-------------------------+

Außerdem habe ich dieses Skript:

IF1=ens160
IF2=ens224

P1_NET=172.31.190.0/23
P2_NET=172.31.196.0/23

IP1=172.31.190.63
IP2=172.31.196.185

P1=172.31.190.1
P2=172.31.196.1

ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2

ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2

ip rule add from $P1_NET dev $IF1 table T1
ip rule add from $P2_NET dev $IF2 table T2

Was gemäß diesem Link geschrieben steht:https://lartc.org/howto/lartc.rpdb.multiple-links.html

Ich habe viele verschiedene Möglichkeiten ausprobiert, um in meinem Fall ein richtlinienbasiertes Routing zu erstellen, aber keine davon war erfolgreich ...

Answer 1

Kurz zusammengefasst

Es besteht keine Notwendigkeitiptables, Markierungen, noch zu entspannenReverse Path Forwarding/Filter. Anstelle der ip rulevon Ihnen verwendeten s, die für ausgehende Pakete nicht übereinstimmen, verwenden Sie die Befehle wie in derLARTCs DokumentationLink, den Sie angegeben haben:

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

dann klappt alles prima.

---

Lange Version

Auch wenn es immer möglich ist, die Dinge durch Entspannung wirken zu lassenReverse Path Forwarding/FilterVerwenden Sie zum Beispielsysctl -w net.ipv4.conf.all.rp_filter=2usw., wodurch asymmetrisches Routing möglich ist, sollte asymmetrisches Routing immer vermieden werden. Insbesondere wenn man bedenkt, dass dieTor(bei Einsatz als strikte Stateful Firewall) oder dieLaptopaus ähnlichen Gründen möglicherweise auch nicht zulassen.iptablesund Markierungen zur Korrektur eines Fehlverhaltens werden sicherlich nicht dabei helfen zu verstehen, wie sich das bereits komplexe Routing-Setup verhalten wird.

Während die verlinkte Dokumentation die IP des Servers als Quelle verwendet (für $IF2/ens224: 172.31.196.185)ohne Schnittstellefür die IP-Regel geben Sie die eingehende Schnittstelle in der Regel an ( devbedeutet iifhier). Das ist das Problem: Dies hat nicht den erwarteten Effekt. Siehe die Beschreibung iifinip rule:

iifNAME

Wählen Sie das entsprechende eingehende Gerät aus.Wenn die Schnittstelle Loopback ist, trifft die Regel nur auf Pakete zu, die von diesem Host stammen. Das bedeutet, dass Sie separate Routing-Tabellen für weitergeleitete und lokale Pakete erstellen und diese somit vollständig trennen können.

Auch wenn es nicht klar geschrieben steht, ist das Gegenteil der Fall: PaketeUrsprungvon diesem Host wird nur mit der Loopback-Schnittstelle übereinstimmen: sie werden nicht mit iif ens160nor übereinstimmen iif ens224, sondern nur iif lo(ja iifbedeuteteingehendSchnittstelle und iif loÜbereinstimmungen lokal generiertausgehendPakete, dann bedeutet dies "vom lokalen System eingehend [in Richtung der Routing-Regeln]"). Das ist wichtig.

Was passiert dann:

1. Laptopversucht, $IP2 zu erreichen (es weiß nicht und sollte nicht wissen, dass $IP2 möglicherweise über die Server $IF1 und $IP1 im selben LAN erreicht werden kann), sendet das Paket durchTor,

2. Torleitet das Paket an die $IP2 des Servers weiter, die zu $P2_NET gehört, an seine $IF2-Schnittstelle,

3. Serverempfängt ein Paket von $P1_NET (von 172.31.190.129) auf der Schnittstelle $IF2,

4. ServerStrenger umgekehrter Pfadrp_filter=1prüft die Rückroute,

5. Wie oben zu sehen, umgekehrte Routepasst nichtanders iifals iif lo: Die beiden neuen Regeln stimmen nicht überein. Daher ist die einzige verbleibende übereinstimmende Regel die Regel für die Hauptroutingtabelle: über $IF1, wie mit folgendem überprüft:

    # ip route get 172.31.190.129 from 172.31.196.185
    172.31.190.129 from 172.31.196.185 dev ens160 uid 0 
        cache 
   

6. Der Rückpfad verwendet nicht die Schnittstelle, von der das Paket kam: Paket wird gelöscht.

Aus den gleichen Gründen wird diese aktuelle Konfiguration keinen korrekten Zugang zum Internet ermöglichen vonServerbei Verwendung von $IP2: wird es wieder nicht den neuen Regeln entsprechen und versuchen, hierfür $IF1 zu verwenden:

# ip route get 8.8.8.8 from 172.31.196.185
8.8.8.8 from 172.31.196.185 via 172.31.190.1 dev ens160 uid 0 
    cache 

Sobald die beiden Regeln entfernt und wie in LARTC dokumentiert geändert wurden, gilt:

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

Das ist:

# ip rule add from 172.31.190.63 table T1
# ip rule add from 172.31.196.185 table T2

Alles wird ordnungsgemäß funktionieren, wie eine Routensuche zeigt (jetzt mithilfe von table T2):

# ip route get 172.31.190.129 from 172.31.196.185
172.31.190.129 from 172.31.196.185 via 172.31.196.1 dev ens224 table T2 uid 0 
    cache 

# ip route get 8.8.8.8 from 172.31.196.185
8.8.8.8 from 172.31.196.185 via 172.31.196.1 dev ens224 table T2 uid 0 
    cache 

Diese 3 Varianten hätten auch funktionieren können (der Kürze halber habe ich die Regel einfach mit Tabelle T2 eingefügt):

ip rule add from 172.31.196.0/23 table T2
ip rule add from 172.31.196.185 iif lo table T2
ip rule add from 172.31.196.0/23 iif lo table T2

Beachten Sie, dass iif losich das Verhalten ändert, wennServerleitet auch andere Systeme dahinter weiter (auch hier gelten die Regeln für diese Systeme nicht): Verwenden Sie es lieber nicht, es sei denn, es ist nötig.

Es besteht keine Notwendigkeitiptablesund Markierungen dafür. Die Verwendung von Markierungen zum Ändern der Schnittstelle kann zusätzliche Probleme beim Routing, bei ARP-Anfragen und beim Reverse Path Filtering verursachen (die Verwendung von Markierungen erfordert normalerweise eine Lockerungrp_filter), verwenden Sie sie daher besser nicht, wenn es sich vermeiden lässt.