Asymmetrisches Routing – Fluch und Segen

Im Internet, das aus Autonomen Systemen (AS) und innerhalb deren IGPs und zu Verbindung der einzelnen AS EGPs nutzt, ist asymmetrischen alltäglich. Hier ist es der angesprochene „Segen“. Wenn ein Knoten ausgelastet ist, können die Protokolle eine andere Route wählen. Bei Verbindungen im Internet ist es daher normal, dass der Hinweg und der Rückweg nicht identisch sind. Dies ist auch die Definition von „Asymmetrischen Routings“: Hinweg und Rückweg unterscheiden sich.

Im LAN kann asymmetrisches Routing bei Multi-Homed-Hosts auftreten und zum „Fluch“ werden. Näher beleuchten möchte ich hier die Microsoft und Linux Implementierungen. Auf die diversen, teils proprietären, Verhaltensweisen von Firewalls, Routern, UTMs… gehe ich nicht weiter ein.

 

Microsoft Windows (ab Vista/Server 2008) und viele Linux (Enterprise) Distributionen verhalten sich ähnlich, auch wenn sie unterschiedliche Standards implementiert haben. Man kann grob unterscheiden:

• Microsoft (ab Next Generation TCP/IP Stack): RFC 1122 -> implementiert als „Strong Host Model“
  • Strong Host Model: Kein asymmetrisches Routing erlaubt!
  • Weak Host Model: Asymmetrisches Routing erlaubt.

 

• Linux (Enterprise Distributionen, Red Hat, CentOS…): RFC 3704 -> implementiert als „Reverse Path Forwarding“
  • Mode 0 (No Source Validation): Asymmetrisches Routing erlaubt, da keine Prüfung.
  • Mode 1 (Strict Mode): Kein asymmetrisches Routing erlaubt!
  • Mode 2 (Loose Mode): Asymmetrisches Routing u. U. erlaubt.
  • Die weiteren in der RFC definierten Modi sind weniger oft implementiert.

 

Definitionen:

Microsoft:
On Windows Vista and later versions of the Windows operating systems, by default, a strong host model is used. Quelle

Weak Host Model:
In the weak host model, an IP host (either IPv4 or IPv6) can send packets on an interface that is not assigned the source IP address of the packet being sent. This is known as weak host send behavior. An IP host can also receive packets on an interface that is not assigned the destination IP address of the packet being received. This is known as weak host receive behavior.

Strong Host Model:
In the strong host model, the send and receive behaviors are different. With strong host sends, the host can only send packets on an interface if the interface is assigned the source IP address of the packet being sent. With strong host receives, the host can only receive packets on an interface if the interface is assigned the destination IP address of the packet being received.
Quelle

 

Linux:
Red Hat Enterprise Linux 6 (unlike Red Hat Enterprise Linux 5) defaults to using Strict Reverse Path Forwarding.

0 – No source validation.
1 – Strict mode:
Each incoming packet is tested against the FIB and if the interface is not the best reverse path the packet check will fail. By default failed packets are discarded.
2 – Loose mode:
Each incoming packet’s source address is also tested against the FIB and if the source address is not reachable via any interface the packet check will fail.
Quelle

 

Beispiel (Theorie)

PC1 möchte eine Ressource auf SRV1 via 10.20.0.10 aufrufen – mit Weak Host Model / RPF-Mode 0 oder 2:

Die Antwort von SRV1 zurück an PC1 erfolgt über I/F1 (Default Gateway), jedoch mit der IP von I/F2 als Quell-IP.
Dieses Verhalten ist standardmäßig seit Vista/Server 2008 nicht mehr möglich! Ebenso bei Linux-Servern mit RPF-Mode 1!

 

Wie wird die Verbindung trotzdem möglich?

Es gibt mehrere Ansätze:

• Der Router, der hier das Paket von VLAN50 in VLAN20 routet, könnte ein SNAT durchführen. Der Server würde das Paket über I/F2 (mit der Quell-IP des Routers) erhalten und folglich die Antwort auch über I/F2 zurück an den Router senden (der das SNAT [als DNAT] rückgängig macht) und das Antwort-Paket an PC1 / VLAN50 zurücksendet.
• Das Weak Host Model / RPF-Mode 2 (oder 0) verwenden. In diesem Fall würde die Verbindung, wie im Beispiel geschildert, funktionieren. Das Paket trifft in I/F2 von SRV1 ein und wird über I/F1 mit der Quell-IP (= Ziel-IP des initialen Pakets von PC1) von I/F2 zurückgesendet.
• Ein dediziertes VLAN-Interface auf dem PC und dem Server verwenden, so wird das Paket nie geroutet. Im Beispiel bräuchte der Server ein weiteres Interface in VLAN50. Allerdings gibt es Anwendungen, die nur an ein Interface gebunden werden können. In solchen Fällen scheidet diese Methode aus.

 

Beispiel (Praxis)

Die Paketmitschnitte sind aus Sicht des Routers zu sehen.

Anfrage: Router an Server

Ziel-IP: 10.10.4.41 –  Ziel-MAC endet auf „3B:3F“.

VLAN324-Interface des Servers:

 

 

---

 

Antwort: Server an Router

Quell-IP: 10.10.4.41 (obwohl auf dem Interface die 10.10.10.5 konfiguriert ist) – Quell-MAC endet auf „3B:41“.

VLAN879-Interface des Servers:

 

Request: Die Anfrage wurde vom Router in VLAN324 geroutet, die Ziel-IP ist 10.10.4.41 (VLAN324-Interface des Servers).
Reply: Die Antwort wurde vom Server über VLAN879 gesendet (in diesem VLAN befindet sich das Default Gateway), jedoch mit der Quell-IP (Ziel-IP der initialen Anfrage) des VLAN324-Interfaces.

Auf diesem Server ist asymmetrisches Routing erlaubt, RPF-Mode 0 ist auf allen Schnittstellen gesetzt.

 

Dieses Verhalten wäre so normalerweise nicht möglich. Ebenso kann es Router/Firewalls/UTMs geben, die das Paket nicht weiterleiten, wenn eine Quell-IP-Adressprüfung (IP-Spoofing) stattfindet. In diesem Fall würde die Quell-IP der Antwort (10.10.4.41) nicht zur IP des VLAN879-Interfaces des Routers passen und der Router das Paket verwerfen.

Die Ziel-IP der Anfrage muss übrigens als Quell-IP der Antwort genutzt werden, da sonst in letzter Instanz der Client (der die Verbindung initial initiiert hat) das Paket verwerfen würde, wenn er als Quell-IP die „richtige“ IP des VLAN879-Interfaces des Servers sehen würde. Da er ein solches Paket nie angefordert hat.

 

Status prüfen

Auf Windows-Systemen:

netsh interface ipv4 show interface l=verbose

Weak Host Model „Schwacher Host“ disabled (asymmetrisches Routing nicht möglich; Windows-Standard)

Windows-Einstellungen ändern (administrative Eingabeaufforderung):

netsh interface ipv4 set interface "NIC-A" weakhostsend=enabled
netsh interface ipv4 set interface "NIC-A" weakhostreceive=enabled

Im Beispiel von oben würde es reichen, auf dem Sendeinterface (I/F1) weakhostsend=enabled zu setzen. Auf dem Empfangsinterface (I/F2) liegt keine Asymmetrie vor.

 

---

 

Auf Linux-Systemen:

sysctl -a 2>/dev/null | grep "\.rp_filter"

RPF-Mode 1 (Strict) auf allen Interfaces eingestellt (asymmetrisches Routing nicht möglich; Linux-Enterprise-Standard)
Der höchste Einstellungswert überschreibt die niedrigeren Werte! net.ipv4.conf.all.rp_filter = 1 ist für alle Schnittstellen gesetzt, da Rest = 0:

As of Kernel version 2.6.31 the highest value set in either the interface specific subtree or the all subtree will be effective setting. If we needed to disable rp_filtering, which uses a value of 0, then we would need to do this in the both in the interface specific key and the all key to ensure that there is not a higher value in any configuration key effecting the interface.

The highest value becomes the effective value! Quelle

 

Linux-Einstellungen ändern (in diesem Fall auf den Loose-Mode 2):

sysctl -w "net.ipv4.conf.default.rp_filter=2" 
sysctl -w "net.ipv4.conf.all.rp_filter=2"

Zur Diskussion steht, ob der Loose-Mode 2 überhaupt eine Funktion in Bezug auf asymmetrisches Routing hat, falls eine Default-Route vorhanden ist, wenn Diese berücksichtigt wird. Diese Frage wird in der RFC auch selbst gestellt:

Loose Reverse Path Forwarding (Loose RPF) is algorithmically similar to strict RPF, but differs in that it checks only for the existence of a route (even a default route, if applicable), not where the route points to. Practically, this could be considered as a „route presence check“ („loose RPF is a misnomer in a sense because there is no „reverse path“ check in the first place). Quelle

 

Schlussgedanken

Wie man sieht, ist die Thematik asymmetrisches Routing unter Umständen komplex und erfordert je nach Situation individuelle Lösungsansätze.

Ich würde zuerst immer versuchen ein dediziertes VLAN-Interface auf der Ressource anzulegen. Dies entzerrt und nimmt Komplexität aus dem System. Sollte das nicht möglich sein, kann man immer noch mit SNAT oder letztlich mit dem „Weak Host Model“ bzw. dem RPF-Mode 0 oder 2 arbeiten.

Es ist auch möglich über Firewall-Filter direkt auf einem Router/Server… die Funktionalität nachzubauen. Ein Quell- und Ziel-IP-Adresscheck gegen das ein- und ausgehende Interface. Entsprechende Regeln sollten sich sowohl in Windows (Firewall) als auch in Linux (iptables) erstellen lassen.