Mit einem dynamischem Routing-Protokoll können wir mehrere Anbindungen dazu bringen, dass bei Ausfall einer Leitung die nächste verwendet wird. Wir nutzen das dynamische Routing-Protokoll in unserem Beispiel aber nur dazu, um uns dynamisch einen festen IP-Adressen-Bereich zu routen. Um den Server hinterher stabil in einem Netzwerk einzusetzen, wo mehrere Leitungen ausfallen dürfen, bedarf es noch viel Handarbeit, welche in diesem Tutorial jedoch nicht beschrieben wird.
Für das dynamische Routing verwenden wir in diesem Beispiel das Projekt OLSR. Man könnte auch BGP4, MPLS, OSPF, RIP oder jedes sonstige Routing-Protokoll verwenden, um ein dynamisches Routing realisieren zu können.
OLSR ist ein Routingprotokoll für mobile Ad-hoc-Netze, das eine an die Anforderungen eines mobilen drahtlosen LANs angepasste Version des Link State Routing darstellt. Es wurde von der IETF mit dem RFC 3626 standardisiert. Bei diesem verteilten flexiblen Routingverfahren ist allen Routern die vollständige Netztopologie bekannt, sodass sie von Fall zu Fall den kürzesten Weg zum Ziel festlegen können. Als proaktives Routingprotokoll hält es die dafür benötigten Informationen jederzeit bereit.
Quelle: Wikipedia.de: Open Link State Routing
Projekt-Seite: http://www.olsr.org/
Source-Code: http://www.olsr.org/releases/0.5/olsrd-0.5.5.tar.bz2 (Version 0.5.5)
Nun downloaden wir den Quellcode und übersetzen ihn zu Binary-Code:
wget http://www.olsr.org/releases/0.5/olsrd-0.5.5.tar.bz2
tar xjf olsrd-0.5.5.tar.bz2
cd
olsrd-a5b9cf969979
make
make install
Der Befehl make install installiert alle ausführbaren Dateien nach /usr/sbin/ . Wenn Sie das nicht wünschen, so müssen Sie die Datei Makefile.inc überarbeiten. In Zeile 43-44 ist die Rede von DESTDIR und SBINDIR - die beiden Eigenschaften sind nach belieben zu verändern.
Auf beiden Endpunkten installieren wir fast die gleiche Konfigurations-Datei. Beide Endpunkte sollten immer die selbe Version von OLSR, sowie die selbe Konfiguration verwenden. Die einzigste Ausnahme bildet der Bereich HNA4 und HNA6, welcher die Bekanntmachung (announcing) der fixen IP-Adressen und IP-Adressen-Bereiche vornimmt. Zudem müssen eventuell bei den beiden Konfigurations-Dateien jeweils die Bezeichnungen der Schnittstellen geändert werden.
Bearbeiten der Konfigurations-Datei /etc/olsrd.conf auf dem ROOT-SERVER:
# If set to 0 the daemon runs in the background
DebugLevel 0
# IP version to use (4 or 6)
IpVersion 4
# FIBMetric ("flat", "correct", or "approx")
FIBMetric "flat"
# Clear the screen each time the internal state changes
ClearScreen yes
# Should olsrd keep on running even if there are
# no interfaces available? This is a good idea
# for a PCMCIA/USB hotswap environment.
# "yes" OR "no"
AllowNoInt no
# Announce fixed ip-ranges
Hna4
{
# Push "Default-Gateway" route-information
0.0.0.0 0.0.0.0
}
# Allow processes like the GUI front-end to connect to the daemon.
IpcConnect
{
# Disable IPC
MaxConnections 0
}
# Wether to use hysteresis or not
# Hysteresis adds more robustness to the link sensing but delays neighbor registration.
UseHysteresis no
# Link quality level
# 0 = do not use link quality
# 1 = use link quality for MPR selection
# 2 = use link quality for MPR selection and routing
LinkQualityLevel 0
# Polling rate in seconds(float).
# Default value 0.05 sec
Pollrate 0.05
# Interval to poll network interfaces for configuration
# changes.
NicChgsPollInt 3.0
# Specifies how much neighbor info should be sent in TC messages
# Possible values are:
# 0 - only send MPR selectors
# 1 - send MPR selectors and MPRs
# 2 - send all neighbors
TcRedundancy 2
# Specifies how many MPRs a node should try select to reach every 2 hop neighbor
# Can be set to any integer > 0
MprCoverage 3
# !!CHANGE THE INTERFACE LABEL(s) TO MATCH YOUR INTERFACE(s)!!
# (eg. wlan0 or eth1):
Interface "bond0"
{
AutoDetectChanges yes
Ip4Broadcast 192.168.10.3
HelloInterval 2.0
HelloValidityTime 6.0
TcInterval 5.0
TcValidityTime 15.0
MidInterval 5.0
MidValidityTime 15.0
HnaInterval 5.0
HnaValidityTime 15.0
}
Bearbeiten der Konfigurations-Datei /etc/olsrd.conf auf dem HOME-ROUTER:
# If set to 0 the daemon runs in the background
DebugLevel 0
# IP version to use (4 or 6)
IpVersion 4
# FIBMetric ("flat", "correct", or "approx")
FIBMetric "flat"
# Clear the screen each time the internal state changes
ClearScreen yes
# Should olsrd keep on running even if there are
# no interfaces available? This is a good idea
# for a PCMCIA/USB hotswap environment.
# "yes" OR "no"
AllowNoInt no
# Update default-routes in routing-table default
RtTableDefault 253
# Announce fixed ip-ranges
Hna4
{
# Push "fixed ip-ranges" route-information available through this router
192.168.20.0 255.255.255.128
192.168.20.128 255.255.255.128
}
# Allow processes like the GUI front-end to connect to the daemon.
IpcConnect
{
# Disable IPC
MaxConnections 0
}
# Wether to use hysteresis or not
# Hysteresis adds more robustness to the link sensing but delays neighbor registration.
UseHysteresis no
# Link quality level
# 0 = do not use link quality
# 1 = use link quality for MPR selection
# 2 = use link quality for MPR selection and routing
LinkQualityLevel 0
# Polling rate in seconds(float).
# Default value 0.05 sec
Pollrate 0.05
# Interval to poll network interfaces for configuration
# changes.
NicChgsPollInt 3.0
# Specifies how much neighbor info should be sent in TC messages
# Possible values are:
# 0 - only send MPR selectors
# 1 - send MPR selectors and MPRs
# 2 - send all neighbors
TcRedundancy 2
# Specifies how many MPRs a node should try select to reach every 2 hop neighbor
# Can be set to any integer > 0
MprCoverage 3
# !!CHANGE THE INTERFACE LABEL(s) TO MATCH YOUR INTERFACE(s)!!
# (eg. wlan0 or eth1):
Interface "bond0"
{
AutoDetectChanges yes
Ip4Broadcast 192.168.10.3
HelloInterval 2.0
HelloValidityTime 6.0
TcInterval 5.0
TcValidityTime 15.0
MidInterval 5.0
MidValidityTime 15.0
HnaInterval 5.0
HnaValidityTime 15.0
}
Stellen Sie sicher, dass beide vTUNs (Server / Client) miteinander verbunden sind und sich gegenseitig erreichen können. Danach starten wir erst auf beiden Rechnern das dynamische Routing-Protokoll.
/usr/sbin/olsrd -f /etc/olsrd.conf
Nach dem erfolgreichem Start des OLSR-Daemons sollte der Befehl /sbin/ip route show table default auf unserem HOME-ROUTER die Default-Route zu unserem VPN-Gegenstück (default via 192.168.10.1 dev bond0) anzeigen. Sollte dies nicht der Fall sein, so warten Sie noch ein paar Sekunden, nachdem Sie beide OLSR-Daemons gesartet haben. Sollte nach einigen Sekunden immer noch kein Eintrag zu sehen sein, so muss bei der Konfiguration etwas schief gelaufen sein. Überprüfen Sie, ob die Verbindung zwischen den beiden VPN-Tunnel verfügbar ist und ob sich die beiden Enden gegenseitig mittels PING erreichen können.
OLSR verwendet den UDP-Port 698 um seine Routeninformationen unter den Prozessen austauschen zu können. Prüfen Sie Ihre Firewall, ob diese den Kommunikations-Port von OLSR blockiert.
Prüfen Sie anschließend auf dem ROOT-SERVER mit dem Befehl /sbin/ip route show table main, ob die beiden Routen, welche wir durch OLSR bekannt machen (announcing) in dieser Routing-Tabelle auftauchen. Es müssten folgende Zeilen zu erkennen sein:
192.168.20.0/25 via 192.168.10.2 dev bond0 192.168.20.128/25 via 192.168.10.2 dev bond0
Seite 1: Bündelung mehrerer Internet-Zugänge zur Steigerung der Geschwindigkeit
Seite 2: Kernel-Module aktivieren, Userspace-Programme einrichten und Grundkonfiguration vornehmen
Seite 3: Routing vorbereiten, Schnittstellen konfigurieren und Routing einrichten
Seite 4: vTUN installieren und einrichten
Seite 5: Dynamisches Routing mit OLSR einrichten
Seite 6: Abschluss