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/interfaces
Datei 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
iptables
Ich 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.