Zwei ISPs und Multipath-Gateway-Konfiguration

Zwei ISPs und Multipath-Gateway-Konfiguration

Ich habe zwei verschiedene ISPs. Ich möchte eine Art Lastenausgleich einrichten, der Pakete an diese Anbieter verteilt. Ich weiß, dass dies mit verschiedenen Routing-Tabellen möglich ist, aber ich wollte etwas namens „Multipath Gateway“ verwenden.

Ich habe beide Schnittstellen in der /etc/network/interfacesDatei konfiguriert. Beide Verbindungen funktionieren separat. Die Standardgateways habe ich durch das folgende ersetzt:

# ip route add default \
    nexthop via 192.168.1.1 dev bond0 weight 1 \
    nexthop via 10.143.105.17 dev wwan0 weight 1

iptablesIch habe in beiden Schnittstellen Maskeradeziele hinzugefügt :

iptables -t nat -A POSTROUTING -o wwan0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o bond0 -j MASQUERADE

Außerdem habe ich die (teilweise) umgekehrte Pfadfilterung aktiviert über sysctl:

net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2

Dieses Setup funktioniert. Pakete (Verbindungen) werden über beide Schnittstellen gesendet. Es gibt nur ein Problem, das ich nicht verstehe.

Wenn ich meine IP-Adresse überprüfen möchte, verwende ich die folgenden Befehle:

$ curl text.whatisyourip.org
$ curl eko.one.pl/host.php

Die IP-Adresse ist in beiden Fällen unterschiedlich, was bedeutet, dass der Mechanismus gut funktioniert. Ich kann mir auch vorstellen, dass er in funktioniert wireshark. Aber wenn ich beispielsweise versuche, mehrere Anfragen an die erste der oben genannten Domänen zu senden, erhalte ich als Antwort immer dieselbe IP-Adresse. Es sieht also so aus, als würden Pakete, die an die bestimmte IP-Adresse gerichtet sind, immer über dieselbe Schnittstelle gehen. Ich frage mich nur, warum. Gibt es einen Mechanismus, der sich die Ziel-IP-Adressen der vorherigen Anfragen merkt und die nächsten Anfragen an dieselben Adressen über dieselbe Schnittstelle laufen lässt?

Antwort1

Ich habe es geschafft, das Problem zu lösen.dieser Linkkann man folgendes lesen:

IPv4: Hash-basiertes Multipath-Routing. Als der Routing-Cache in 3.6 entfernt wurde, änderte sich der IPv4-Multipath-Algorithmus von mehr oder weniger zielbasiertem zu quasi-zufälligem Planen pro Paket. Dies erhöhte das Risiko von Paketen in falscher Reihenfolge und machte es unmöglich, Multipath zusammen mit Anycast-Diensten zu verwenden. In dieser Version wird die Multipath-Routing-Implementierung durch ein flussbasiertes Lastenausgleichs-System ersetzt, das auf einem Hash über die Quell- und Zieladressen basiert. Merge Commit

Obwohl der Cache in Kernel 3.6 entfernt wurde, werden die Anfragen immer noch zwischengespeichert. Jetzt sind die Quell- und Zieladressen wichtig. Deshalb gehen die Pakete immer über dieselbe Schnittstelle.

verwandte Informationen