Linux mehrere Internetverbindungen Lastausgleich mit Fehlerbehandlung

Ich habe zwei ISP-Verbindungen und benötige einen automatischen Lastausgleich zwischen ihnen. Ich muss auch fehlgeschlagene Verbindungen behandeln (keine verwenden, die nicht funktioniert).

Die erste Verbindung ist eine PPTP-Verbindung ( ppp0), die zweite ist normales Ethernet. Das System ist Gentoo Linux.

Derzeit habe ich ein grundlegendes Balancing erreicht ip route, aber es sieht so aus, als ob es nicht sehr gut funktioniert. Folgendes habe ich verwendet:

ip rule $ADD from $IP1 table rt_link1
ip rule $ADD fwmark 1 lookup rt_link1
ip rule $ADD from $IP2 table rt_link2
ip rule $ADD fwmark 2 lookup rt_link2
$NET2 dev eth2 src $IP2 table rt_link2
default via GW2 table rt_link2
$NET2 dev eth2 src $IP2
$NET1 dev ppp0 src $IP1 table rt_link1
default via GW1 table rt_link1
$NET1 dev ppp0 src $IP1
default scope global nexthop via $GW1 weight 1 nexthop via $GW2 dev eth2 weight 1

Als ehemaliges Mitglied des Kernteams des LVS-Projekts würde ich dringend davon abraten, diese Technologie zum Ausgleich mehrerer Internetverbindungen zu verwenden. Tatsächlich kann ich Ihnen fast garantieren, dass es nicht wie erwartet funktioniert.

Heutzutage wird die Behandlung fehlgeschlagener Anbieterverbindungen häufig als Dead Gateway Detection (DGD) und manchmal auch als NUD (Neighbour Unreachability Detection) bezeichnet. Laut RFC816 und RFC1122 gibt es mehrere Möglichkeiten, DGD durchzuführen. Ich habe jedoch nur etwa drei davon in freier Wildbahn gesehen (von einem alten Beitrag von mir bis zur LVS-Mailingliste):

• Link-Layer-Informationen, die Hostfehler zuverlässig erkennen und melden (z. B. ARPANET Destination Dead-Nachrichten), sollten als negative Hinweise verwendet werden.
• Eine ICMP-Umleitungsnachricht von einem bestimmten Gateway sollte als positiver Hinweis zu diesem Gateway verwendet werden.
• Pakete, die von einer bestimmten Verbindungsschichtadresse ankommen, sind ein Beweis dafür, dass das System an dieser Adresse aktiv ist. Um diese Informationen jedoch in Hinweise zu Gateways umzuwandeln, müssen Sie die Adresse der Verbindungsschicht einer IP-Adresse zuordnen und diese IP-Adresse dann mit den Gateways vergleichen, auf die der Routen-Cache verweist. Dies ist wahrscheinlich unerschwinglich ineffizient.

Als ich 2006 die aktive Linux-Kernel-Netzwerkentwicklung verließ, gab es noch keine endgültige Entscheidung darüber, wie NUD-Statusänderungen implementiert werden sollen. Ein Freund von mir und Hauptentwickler von LVS, Julian Anastasov, musste Ihre Herausforderung bereits 2002 lösen. Eines Abends setzte er sich hin und schrieb eine funktionierende Version der DGD für statisches Routing, indem er der FIB den NUD-Status hinzufügte (Forward Information) Base). Den Patch finden Sie hier und die Dokumentation hier , hier und hier . Dies sollte Ihnen viele Informationen über Ihre weitere Suche nach dieser nicht trivialen Aufgabe geben. Ich sehe, dass die Patches immer noch wild verwendet werden und daher mit den neuesten Kerneln auf dem neuesten Stand gehalten werden. Möglicherweise möchten Sie mit einem Skript wie dem folgenden beginnen (geschrieben vonRobert Kurjata ):

#!/bin/bash
# This script is done by : Robert Kurjata Sep, 2003.
# feel free to use it in any useful way

# CONFIGURATION
IP=/sbin/ip
PING=/bin/ping

#--------------- LINK PART -----------------
# EXTIFn - interface name
# EXTIPn - outgoing IP
# EXTMn  - netmask length (bits)
# EXTGWn - outgoing gateway
#-------------------------------------------

# LINK 1
EXTIF1=eth2
EXTIP1=
EXTM1=
EXTGW1=

# LINK 2
EXTIF2=eth1
EXTIP2=
EXTM2=
EXTGW2=

#ROUTING PART
# removing old rules and routes

echo "removing old rules"
${IP} rule del prio 50 table main
${IP} rule del prio 201 from ${EXTIP1}/${EXTM1} table 201
${IP} rule del prio 202 from ${EXTIP2}/${EXTM2} table 202
${IP} rule del prio 221 table 221
echo "flushing tables"
${IP} route flush table 201
${IP} route flush table 202
${IP} route flush table 221
echo "removing tables"
${IP} route del table 201
${IP} route del table 202
${IP} route del table 221

# setting new rules
echo "Setting new routing rules"

# main table w/o default gateway here
${IP} rule add prio 50 table main
${IP} route del default table main

# identified routes here
${IP} rule add prio 201 from ${EXTIP1}/${EXTM1} table 201
${IP} rule add prio 202 from ${EXTIP2}/${EXTM2} table 202

${IP} route add default via ${EXTGW1} dev ${EXTIF1} src ${EXTIP1} proto static table 201
${IP} route append prohibit default table 201 metric 1 proto static

${IP} route add default via ${EXTGW2} dev ${EXTIF2} src ${EXTIP2} proto static table 202
${IP} route append prohibit default table 202 metric 1 proto static

# mutipath
${IP} rule add prio 221 table 221

${IP} route add default table 221 proto static \
            nexthop via ${EXTGW1} dev ${EXTIF1} weight 2\
            nexthop via ${EXTGW2} dev ${EXTIF2} weight 3

${IP} route flush cache

while : ; do
  ${PING} -c 1 ${EXTGW1}
  ${PING} -c 1 ${EXTGW2}
  sleep 60
done

Außerdem können Sie die Option zum Ausführen dynamischer Routing-Protokolle prüfen.

Verwenden Sie LVS in Verbindung mit lvs-kiss. Oder etwas ähnliches.

LVS ist im Grunde der ìpvsadmBefehl. Der einzige Nachteil dieses Load-Balancers besteht darin, dass er nicht überwacht. Sie benötigen also ein Programm, das dies für Sie erledigt und den toten Link aus Ihrer Konfiguration entfernt (und ihn wieder lebend hinzufügt).

ldirectord Aus dem Heartbeat-Stack könnte sich eine weitere Lvs-Addition ergeben (anstelle von Lvs-Kiss).