Bündelung mehrerer Internet-Zugänge zur Steigerung der Geschwindigkeit

Author: RcRaCk2k
Dieses Tutorial soll Ihnen dabei helfen, mehrere am Standort zur Verfügung stehende DSL-Anschlüsse gleicher Geschwindigkeit zu bündeln, damit am Endpunkt Ihres Home-Routers eine schnellere Verbindung ins Internet realisieret werden kann.

Dieses Tutorial bassiert auf einer Idee von VIPRINET, welche ein Produkt auf den Markt gebracht haben, das bis zu 6 DSL-Anschlüsse bündelt und dem dahinter betriebenem Netzwerk zur Verfügung stellen kann.

Quelle: Statt Standleitung: VPN-Router bündelt 6 DSL-Anschlüsse

Zielsetzung

Am Ende des Tutorials sollte Ihr Home-Router über eine feste IP-Adresse verfügen und gegebenfalls komplette IP-Adressen-Bereiche über ein dynamisches Routing-Protokoll zugeführt bekommen. Die Bündelung der DSL-Verbindungen ermöglicht den im LAN-Segment angeschlossenen Endgeräten einzelne Dateien bei nur einer Socket-Verbindung schnell herunterladen zu können.
  • Vervielfachung der Download-Geschwindigkeit
  • Vervielfachung der Upload-Geschwindigkeit
  • Steigerung der Verfügbarkeit der Datenleitung
  • Betrieb einer festen IP-Adresse
  • Zuführung von ganzen IP-Adressen-Bereichen

Voraussetzungen

Für den Betrieb benötigen wir ein Linux-System mit Funktionalität zum Übersetzen von Quellcode in Binary-Code wie z.B. GCC, Autoconf, GNU Make. Bei Linux-Distributionen welche APT-GET zur Verfügung stellen geht dies recht einfach mit dem Befehl:

apt-get update
apt-get install build-essential

Während meiner Beschreibung gehe ich von einem aktuellen Linux-Kernel aus, sowie davon, dass wir alle Programme direkt vom Quelltext übersetzen werden. Ich verwende ein Gentoo 2008.1 System ohne EMERGE-Funktionalität - dadurch kann dieses Tutorial auf jedem Linux-Rechener angewendet werden. Eine Deinstallation der Programme ist im Nachhinein jedoch nicht mehr möglich! Es bleibt Ihnen selbst überlassen, Pakete für Ihre Distribution aus den Sourcen zu erstellen, welche installiert und deinstalliert werden können.

Folgende Voraussetzungen müssen erfüllt sein:

  • Kernel-Version >= 2.6.18 und den dazu benötigten Source-Code
  • GCC und GNU Make in der Version verfügbar, mit welcher der Kernel übersetzt wurde
  • Administratorische Rechte auf allen Linux-Systemen
  • Grundverständnis für Netzwerkkommunikation
  • Root-Server in einem Rechenzentrum
  • minimal vier nacheinanderfolgende freie, und durch Ihr Rechenzentrum öffentlich geroutete IP-Adressen (wenn sie öffentliche IP-Adressen Ihrem Home-Router zuführen möchten). Sollten Ihnen keine öffentlichen IP-Adressen zur Verfügung stehen, so verwenden Sie private IP-Adressen und stellen Sie den Zugang zum Internet an Ihrem Root-Server im Rechenzentrum mittels SOURCE-NAT (Masquerading) sicher. In diesem Beispiel werden wir private IP-Adressen verwenden und das SOURCE-NAT durchführen.
Folgende IP-Netze werden benötigt:
  • IP-Netz /30 (255.255.255.252) für die Verbindung der beiden VPN-Endpunkte (1 Netzwerk-Adresse, 2 Host-Adressen, 1 Broadcast-Adresse)
  • jeweils ein IP-Netz /30 (255.255.255.252) pro DSL-Anbindung (1 Netzwerk-Adresse, 2 Host-Adressen, 1 Broadcast-Adresse)
  • IP-Netz /29 (255.255.255.248), /28 (255.255.255.240) oder größeres IP-Netz zum routen kompletter IP-Adressen-Bereiche
Für unsere DSL-Anbindungen verwenden wir folgende IP-Netze:
  • 192.168.1.0/30 für unsere 1. DSL-Anbindung (immer private IP-Adressen verwenden)
  • 192.168.1.4/30 für unsere 2. DSL-Anbindung (immer private IP-Adressen verwenden)
  • 192.168.1.8/30 für unsere 3. DSL-Anbindung (immer private IP-Adressen verwenden)
  • usw.
Wir verwenden für unser VPN folgendes IP-Netz:
  • 192.168.10.0/30 für die Verbindung beider VPN-Endpunkte (öffentlich routbares IP-Netz, oder privates IP-Netz)
Folgende IP-Netze werden wir uns in diesem Beispiel dynamisch zuführen:
  • 192.168.20.0/25 Zuführung des IP-Adressen-Breichs (öffentlich routbares IP-Netz, oder privates IP-Netz)
  • 192.168.20.128/25 Zuführung des IP-Adressen-Breichs (öffentlich routbares IP-Netz, oder privates IP-Netz)
Wenn Sie öffentlich geroutete Netzwerk-Adressen verwenden, dann sind diese adäquat in allen Beispielen anzuwenden.

HINWEIS: Wenn Sie sich öffentliche IP-Adressen-Bereiche auf Ihren Home-Router zuführen, muss Ihr VPN-Tunnel ebenfalls ein öffentliches IP-Netz benutzen, damit das Routing im Internet bei Routen-Verfolgungen richtig funktioniert. Private IP-Adressen-Räume zwischen öffentlich gerouteten Netzen sind laut RIPE nicht erlaubt!

Eingesetzte Software

Für den Betrieb unseres Multi-VPN-Routers benötigen wir eine Hand voll Software, welche die Verbindung zwischen dem Root-Server im Rechenzentrum und dem Home-Router zuhause herstellt. Damit unser System komplett autonom funktioniert, richten wir zudem ein dynamisches Routing-Protokoll ein, welches automatisch ein alternatives Routing konfigurieren kann.

Folgende Software wird in diesem Projekt verwendet:
  • Standard Linux System
  • Kernel-Version >= 2.6.18
  • Linux-Bonding
  • iproute2
  • vTUN v3.0.2
  • OLSR v0.5.5
Wir benötigen von Ihrer aktuellen Linux-Distribution die verwendeten Kernel-Sourcen, damit wir noch ein paar benötigte Module nachinstallieren können. Je nach eingesetzter Distribution können diese Sourcen bereits unter /usr/src/linux vorliegen, oder müssen erst noch mittels Paket-Managers nachgeladen werden. Schlagen Sie dafür im Kapitel "Nachladen der Kernel-Sourcen" in der Dokumentation Ihrer Distribution nach bzw. bemühen Sie eine Suchmaschine.

Im ersten Schritt werden wir folgende Module im Kernel aktivieren:
  • Networking > Networking options > IP: advanced router
  • Networking > Networking options > IP: policy routing
  • Networking > Networking options > Network packet filtering framework (Netfilter)
  • Device Drivers > Network device support > Universal TUN/TAP device driver support (als Module übersetzen)
  • Device Drivers > Network device support > Bonding driver support (als Module übersetzen)
Führen Sie nun die Übersetzung der Kernel-Sourcen wie gewohnt aus und starten Sie Ihren Rechner neu.

Wenn Ihr Rechner ohne Probleme neu gestartet hat, sollten die Befehle modinfo tun und modinfo bonding Daten zum angegebenem Modul ausgeben. Sollte das System jedoch erwähnen, dass die angegebenen Module nicht gefunden wurden, dann ist bei Ihrer Kernel-Konfiguration / Übersetzung etwas schief gelaufen.

Übersetzen des Userspace-Programms ifenslave

Damit wir mehrere VPN-Tunnel zu einem einzigen Port-Channel zusammenfassen können, benötigen wir das Userspace-Programm ifenslave, welches den Kernel-Sourcen im Verzeichnis ./Documentation/network beiliegt.

Übersetzen des Programms:

cd /usr/src/linux/Documentation/network/
gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave
cp ifenslave /sbin/ifenslave

Nun sollte das Programm ifenslave Systemweit für Administratoren zur Verfügung stehen. Bei Aufruf des Befehls sollte eine kleine Hilfe (auch als Usage bekannt) zu sehen sein. Sollte der Befehl im System nicht gefunden werden, so wird es wohl während dem Übersetzen des Quellcodes / bzw. beim Kopieren der Binary zu einem Problem gekommen sein.

Laden der benötigten Kernel-Module

Für den reibungslosen Betrieb unseres VPN-Tunnel benötigen wir die zuvor übersetzten Kernel-Module. Stellen Sie sicher, dass nach jedem Neustart des Systems die notwendigen Module ordnungsgemäß geladen werden, bevor eine der Server-Software - welche wir hier verwenden werden - gestartet wird.

Folgende Module müssen geladen werden:

modprobe tun
modprobe bonding mode=0 miimon=100 downdelay=500 updelay=900

Informationen zum Module "bonding" finden Sie unter:
http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/networking/bonding.txt

Konfigurieren der Netzwerk-Schnittstelle

Nachdem die Module ordnungsgemäß geladen wurden und der Befehl lsmod beide Module in der Ausgabe aufweist, können wir die notwendigen Netzwerk-Skripts anlegen. Je nach Distribution unterscheidet sich die Konfiguration der Netzwerk-Schnittstellen.

In diesem Abschnitt werden wir die Konfiguration der Schnittstelle selbst vornehmen. Wie Sie die Netzwerkparameter automatisch bei Systemstart eintragen lassen, lesen Sie bitte in der Dokumentation Ihrer Distribution nach.

Nun legen wir manuell die Daten der Netzwerk-Schnittstelle von "bond0" auf dem ROOT-SERVER fest:

/sbin/ifconfig bond0 192.168.10.1 netmask 255.255.255.252 broadcast 192.168.10.3 up

Nun legen wir manuell die Daten der Netzwerk-Schnittstelle von "bond0" auf dem HOME-ROUTER fest:

/sbin/ifconfig bond0 192.168.10.2 netmask 255.255.255.252 broadcast 192.168.10.3 up

Für den VPN-Tunnel verwenden wir ein /30 Netzwerk, welches uns eine Netzwerk-Adresse, 2 Host-Adressen und eine Broadcast-Adresse zur Verfügung stellt. Als Netzwerk verwenden wir hier in unserem Beispiel 192.168.10.0/30. Rein theoretisch wäre es hier auch möglich, reine Host-Adressen /32 zu verwenden und hinterher mittels des dynamischen Routings und der Broadcast-Adresse 255.255.255.255 sich zwei IP-Adressen zu sparen.

Übersetzen des Userspace-Programms ip aus dem IPROUTE2-Paket

Für die Einrichtung unserer IP-Adressen verwenden wir das Userspace-Programm ip - aus dem IPROUTE2-Paket. Das Userspace-Programm ip bietet uns einen besseren Konfigurations-Komfort als wie das veraltete ifconfig Userspace-Programm, welches den meisten Distributionen bereits beiliegt.

Seite zum Projekt IPROUTE2: http://www.linuxfoundation.org/en/Net:Iproute2 Download der aktuellen Version: http://developer.osdl.org/dev/iproute2/download/iproute2-latest (BZIP2 kompremiertes Datenarchiv)

Nun werden wir den Source herunterladen und den Quellcode auf unser Host-System zu Binary-Code übersetzen:

wget http://developer.osdl.org/dev/iproute2/download/iproute2-latest
tar xjf iproute2-latest
cd iproute2-latest
./configure
make
make install
ln -s /usr/sbin/ip /sbin/ip

Einige Distributionen wie z.B. Gentoo erwarten das Userspace-Programm ip im Ordner /sbin/ . Aus diesem Grund erstellen wir in dieses Verzeichnis einen symbolischen Link.

Da unser Home-Router durch verschiedene Internet-Anbindungen mehrere Ausgänge und somit mehrere IP-Adressen besitzt, müssen wir dem Linux-Kernel beibringen, jede Verbindung einzeln zu behandeln und als Upstream- und Downstream zu verwenden. Der Linux-Kernel kennt normalerweise von Standard aus nur einen einzigen Standardweg (Default-Route / Upstream) für Pakete, die er lokal keiner Schnittstelle zuordnen kann und verschickt diese über diesen bekannten Standard-Weg (Default-Route).

Definieren der Routing-Tabellen-Namen

Der Linux-Kernel (kompiliert mit der Option "advanced router") bietet mit Hilfe des Userspace-Programms ip den nötigen Konfigurations-Mechanismus, um dem Linux-Kernel mit mehreren Upstreams / Wegen bekannt zu machen. Zuerst definieren wir für alle Schnittstellen zu unseren DSL-Anbindungen die notwendigen Tabellennamen, um die einzelnen Routeninformationen zu einem späteren Zeitpunkt wieder konkret nachvollziehen zu können.

Wir bearbeiten nun die Datei /etc/iproute2/rt_tables :
#
# reserved values # 255 local 254 main 253 default 0 unspec # # Direct Upstreams # 101 dsl-connection-001 102 dsl-connection-002 103 dsl-connection-003
Wir fügen unserer bereits bestehenden Konfiguration einfach nur den Teil von "Direct Upstreams" hinzu. Für jeden Upstream / jede Anbindung definieren wir hier unsere Routing-Tabellen-Namen, welche die Zuordnung von Name und ID ermöglicht. Man könnte diesen Schirtt auch überspringen, müsste sich dann aber umständlich die einzelnen IDs merken (101, 102, ...).

Schnittstellen einrichten

Nun definieren wir die einzelnen Anbindungen. Für unser Beispiel habe ich mir folgendes gedacht: Wir verwenden für jede DSL-Anbindung einen eigenen DSL Hardware-Router, wie z.B. eine AVM!FritzBox, ZyXEL oder sonstigen Hardware-Router mit integrieter ADSL2+ Unterstützung und füttern diese mit den Zugangsdaten des Internet-Service-Providers (ISP).

Im LAN-Segment der einzelnen Router vergeben wir folgende IP-Adressen:
Router 001: 192.168.1.1 netmask 255.255.255.252 broadcast 192.168.1.3
Router 002: 192.168.1.5 netmask 255.255.255.252 broadcast 192.168.1.7
Router 003: 192.168.1.9 netmask 255.255.255.252 broadcast 192.168.1.11
usw.

Im LAN-Segment des HOME-Routers vergeben wir folgende IP-Adressen:
eth0: 192.168.1.2 netmask 255.255.255.252 broadcast 192.168.1.3
eth1: 192.168.1.6 netmask 255.255.255.252 broadcast 192.168.1.7
eth2: 192.168.1.10 netmask 255.255.255.252 broadcast 192.168.1.11
usw.

eth0 ist dabei logisch mit Router 001 verbunden, sowie eth1 logisch mit Router 002 usw.

WICHTIG: Definieren sie keine DEFAULT-GATEWAYS, außer Sie wissen was Sie tun! Wenn Sie DEFAULT-GATEWAYS verwenden, stellen Sie sicher, dass Ihre Linux-Distribution diese Routen mit dem Userspace-Programm ip einrichtet. Definieren Sie dann die DEFAULT-ROUTE so, dass diese Information in der Routing-Tabelle default gespeichert wird, sowie eine metric >= 10 besitzt! Zudem ist die selbe DEFAULT-ROUTE auch der jeweiligen verknüpften Routing-Tabelle dsl-connection-xxx hinzuzufügen.

Beispiel-Konfiguartion unter Gentoo 2008.1:
modules=( "iproute2" )
config_eth0=( "192.168.1.2/30 brd 192.168.1.3" ) config_eth1=( "192.168.1.6/30 brd 192.168.1.7" ) config_eth2=( "192.168.1.10/30 brd 192.168.1.11" ) config_bond0=( "192.168.10.2/30 brd 192.168.10.3" ) routes_eth0=( "default via 192.168.1.1 table default metric 10" "default via 192.168.1.1 table dsl-connection-001" ) routes_eth1=( "default via 192.168.1.5 table default metric 10" "default via 192.168.1.5 table dsl-connection-002" ) routes_eth2=( "default via 192.168.1.9 table default metric 10" "default via 192.168.1.9 table dsl-connection-003" )

Linux-Kernel mit den verschiedenen Wegen bekannt machen

Die meisten Internet-Service-Providers erlauben es nicht, Pakete über deren Internet-Leitung zu verschicken, die nicht der originalen IP-Adresse entstammen. Wenn z.B. eine Anfrage auf dem zweiten Internet-Anschluss ankommt, aber über den ersten Internet-Anschluss beantwortet wird, dann würde der ISP diese Antwort verwerfen, wodurch diese am Ziel niemals ankommen würde.

In diesem Schritt bringen wir dem Linux-Kernel bei, dass er je nach SOURCE-IP-Adresse der eigenen Maschine das Paket über die jeweilige Schnittstelle - die dafür vorgesehen ist - verschicken muss.

/sbin/ip rule add from 192.168.1.2 lookup dsl-connection-001
/sbin/ip rule add from 192.168.1.6 lookup dsl-connection-002
/sbin/ip rule add from 192.168.1.10 lookup dsl-connection-003
...

HINWEIS: Stellen Sie sicher, dass diese Kommandos nach jedem Systemstart ausgeführt werden. Unter Gentoo ist dies über die Datei /etc/conf.d/local.start möglich.

Testen können wir unsere Anbindungen, indem wir einen PING mit jeweils der SOURCE-IP-Adresse der verschiendenen Schnittstellen ausprobieren.

ping -I 192.168.1.2 194.145.226.26
ping -I 192.168.1.6 194.145.226.26
ping -I 192.168.1.10 194.145.226.26

Wenn alles richtig konfiguriert wurde, müssten wir bei jeder PING-Anfrage auch die beabsichtigten Antworten erhalten haben. Zudem können wir während den laufenden PING-Anfragen die Konfiguration über die Beobachtung der Aktivitäts-LEDs am Router des jeweiligen Anschlusses prüfen. Je nach verwendeter IP-Adresse, müssen die LEDs des entsprechenden Routers aktiv werden.

Wenn wir die Default-Route auch in der Routing-Tabelle default eingetragen haben, dann müsste es möglich sein, auch ohne Angabe der SOURCE-IP den Host 194.145.226.26 (www.powerns.de Frankfurt am Main) zu erreichen. Linux entscheidet dabei selbst, über welche Schnittstelle es die Anfrage verschicken soll.

Durch die Angabe verschiedener METRICS kann die automatische Auswahl der Schnittstelle beeinflusst werden. Schnittstellen mit niedriger Metric haben hier Vorrang!

Informationen zum allgemeinen Routing findet man bei Wikipedia unter folgendem Artikel:
http://de.wikipedia.org/wiki/Routing
vTUN wurde von Maxim Krasnyansky entwickelt und wird nunher von Bishop Clark gewartet. Bei vTUN hanelt es sich um eine Netzwerk-Anwendung, um virtuelle Tunnel (VPN) über TCP/IP Netzwerke aufzubauen. vTun unterstützt dabei das Internet Protocol (IP), Point-to-Point Protocol (PPP) und SLIP-Protokoll. Zudem verfügt vTUN über eine Schnittstelle zum Tunnel-Treiber Tun/Tap, welcher bereits im Kernel ab Version 2.4 zur Grundausstattung gehört.

Quelle: Wikipedia: vTUN

Übersetzen des vTUN Source-Codes

Auf beiden Rechnern installieren wir nun anhand des Source-Codes den VPN-Tunnel Server und Client.

Source-Files des vTUN Daemon: http://vtun.sourceforge.net/download.html http://sourceforge.net/project/showfiles.php?group_id=2947&package_id=2900&release_id=574828 (v3.0.2)

Während der Beschreibung war die Versionsnummer 3.0.2 vom 08.02.2008 verfügbar. Es gilt grundsätzlich immer die neueste Software zu verwenden - dadurch können sich jedoch unterschiede zu dieser Dokummentation ergeben.

Nun laden und entpacken wir den Source-Code. Danach übersetzen wir ihn zu Binary-Code:

wget "http://downloads.sourceforge.net/vtun/vtun-3.0.2.tar.gz?modtime=1202460110&big_mirror=0"
tar xzf vtun-3.0.2.tar.gz
cd vtun-3.0.2
./configure --prefix=/usr --sysconfdir=/etc --mandir=/usr/local/share/man --disable-shaper --disable-ssl --disable-zlib --disable-lzo
make
make install

Achtung: Diese Übersetzung des Quelltextes schaltet die Datenverschlüsslung, sowie die Datenkompremierung ab. Je nach Szenario könnte eine verschlüsselte Datenübertragung notwendig / sinvoll sein. Es bleibt jedem selbst überlassen, wie er seinen vTUN-Server / Client zu Binary-Code übersetzt. Der Author übernimmt keine Haftung, wenn die Daten unverschlüsselt übertragen und von Dritten abgehorcht werden.

Konfiguration des vTUN-Servers am ROOT-SERVER

Nun machen wir uns an die Konfiguration des Servers. Wir schalten in diesem Beispiel die Verschlüsslung, sowie die Kompremierung der Daten ab, um einen schnelleren Datendurchsatz gewährleisten zu können. Je nach verwendeter Hardware kann die Verschlüsslung, sowie die Kompremierung sehr viel Zeit in Anspruch nehmen. Mit einer 686er Host-Maschine und einem 2.6GHz Intel P4 erreichen wir ca. 100 MBit Datendurchsatz ohne Verschlüsslung und ohne Kompremierung.

Wir bearbeiten die Datei /etc/vtund.conf:
options {
port 5000; # Listen on this port. bindaddr { iface eth0; # Listen only on ETH0 device only }; # Syslog facility syslog daemon; # Path to various programs firewall /sbin/iptables; ip /sbin/ip; } # Default session options default { compress no; # Compression is off by default speed 0; # By default maximum speed, NO shaping encrypt no; # Disable SSL-Encryption keepalive yes; # Enable KeepAlive proto udp; # Use UDP as Data-Protocoll multi killold; # Allow new connection and kill old one } # First Interface Profile dsl-bonding-if-001 { passwd my_secreat_password; # Change password to your liking type ether; # Use Universal TUN / TAP Driver up { ip "link set up %% multicast off mtu 1460"; # Use your current MTU on your ISP - 40 Bytes for your tunnel's MTU program "/sbin/ifenslave bond0 %%"; # Attach TUN / TAP Device to port-channel }; } # Second Interface Profile dsl-bonding-if-002 { passwd my_secreat_password; # Change password to your liking type ether; # Use Universal TUN / TAP Driver up { ip "link set up %% multicast off mtu 1460"; # Use your current MTU on your ISP - 40 Bytes for your tunnel's MTU program "/sbin/ifenslave bond0 %%"; # Attach TUN / TAP Device to port-channel }; } ### REPEAT THIS PROFILE MANY TIMES AS YOUR NEED ### YOU NEED ONE PROFILE FOR EACH CONNECTION
Den Abschnitt dsl-bonding-if-001, dsl-bonding-if-002, .... benötigen wir für jede einzelne Verbindung, welche wir Bündeln möchten. Sprich, wenn wir 6 DSL-Anschlüsse haben, benötigen wir 6 Profile 001, 002, 003 .... 006! In diesem Profil definieren wir das Passwort, sowie was nach dem Verbindungsaufbau geschehen soll.

In vTUN kann noch vieles mehr eingestellt werden. Für unser Beispiel jedoch ist diese Konfiguration vollkommen ausreichend. Weitere Konfigurationsparameter und die Bedeutung der in dieser Konfiguration verwendeten Befehle, finden Sie in der MAN-Page der Konfigurations-Datei, welche der Source-Distribution beiliegt, oder im Internet unter der URL: http://vtun.sourceforge.net/conf.man.html

Konfiguration des vTUN-Clients am HOME-ROUTER

Die Konfiguration des Clients ist wesentlich einfacher, da die meisten Konfigurations-Eigenschaften nach der Verbindung direkt mit dem Server abgeglichen werden. vTUN initialisiert die Verbindung über einen TCP-Port und schaltet nach der erfolgreichen Authentifizierung erst auf das in der Server-Konfiguration angegebenes Übertragungs-Protokoll um. In unserem Fall muss eine Firewall den Port 5000 sowohl auf TCP wie auch UDP freigeben.
options {
port 5000; # Listen on this port. timeout 5; # Connection-Timeout in seconds # Syslog facility syslog daemon; # Path to various programs firewall /sbin/iptables; ip /sbin/ip; } dsl-bonding-if-001 { passwd my_secreat_password; persist yes; srcaddr { iface eth0; # Use first up-/ downstream-device }; up { ip "link set %% up multicast off mtu 1460"; program "/sbin/ifenslave bond0 %%"; }; } dsl-bonding-if-002 { passwd my_secreat_password; persist yes; srcaddr { iface eth1; # Use second up-/ downstream-device }; up { ip "link set %% up multicast off mtu 1460"; program "/sbin/ifenslave bond0 %%"; }; } ### REPEAT THIS PROFILE MANY TIMES AS YOUR NEED ### YOU NEED ONE PROFILE FOR EACH CONNECTION
Auch hier kopieren wir das Profil für jede Anbindung, welche wir bündeln möchten. Der Profilname muss 1 zu 1 dem entsprechen, wie er in der Server-Konfiguration angegeben wurde. In vTUN kann noch vieles mehr eingestellt werden. Für unser Beispiel jedoch ist diese Konfiguration vollkommen ausreichend. Weitere Konfigurationsparameter und die Bedeutung der in dieser Konfiguration verwendeten Befehle, finden Sie in der MAN-Page der Konfigurations-Datei, welche der Source-Distribution beiliegt, oder im Internet unter der URL: http://vtun.sourceforge.net/conf.man.html

Starten von vTUN

Nun kommt der Augenblick der Wahrheit. Nun starten wir unseren Server und den Client und bauen somit die verschiedenen VPN-Tunnel auf. Ganz gespannt dürfen wir dann beobachten, ob unsere Konfiguration ein voller Erfolg gewesen ist.

So starten wir den Server auf dem ROOT-SERVER:

/usr/sbin/vtund -s -f /etc/vtund.conf

und so starten wir die Client-Verbindungen auf unserem HOME-ROUTER:

/usr/sbin/vtund -f /etc/vtund.conf dsl-bonding-if-001 [SERVER-IP-ADRESSE]
/usr/sbin/vtund -f /etc/vtund.conf dsl-bonding-if-002 [SERVER-IP-ADRESSE]
...

Wiederholen Sie den Startvorgang der einzelnen Client-Verbindung für jedes einzelne Profil und ersetzen Sie [SERVER-IP-ADRESSE] gegen die IP-Adresse Ihres VTUN-SERVERs.

Danach sollte eine Prozess-Ausgabe auf dem HOME-ROUTER

ps aux | grep 'vtun' | grep -v 'grep'

folgendes anzeigen:
root  1550  0.0  0.0  1572  520 ?  S<s   2008  1:27 vtund[c]: dsl-bonding-if-001 ether tap0
root 1553 0.0 0.0 1572 616 ? S<s 2008 1:27 vtund[c]: dsl-bonding-if-002 ether tap1
Wenn bei Ihnen der vtund-Prozess des Clients etwas wie [connecting] anzeigt, dann scheint es ein Problem mit der Verbindung ins Rechenzentrum zu geben. In solch einem Fall sollten Sie noch einmal genau alle Schritte überprüfen und eventuell mit dem Programm tcpdump den Datentransfer auf den Schnittstellen Ihrer Außen-Anbindungen überprüfen.

Wenn Sie in der oben geführten Anzeigen Ihrer laufenden Prozesse die Profile sehen können, dann versuchen wir einmal die beiden Gegenstellen erreichen zu können.

Folgendes führen wir auf dem ROOT-SERVER aus:

ping 192.168.10.2

Folgendes führen wir auf dem HOME-ROUTER aus:

ping 192.168.10.1

Beide Adressen sollten jeweils mit einer bestimmten Antwortzeit auf Ihre ICMP-Request-Anfrage antworten. Bitte stellen Sie bei Ping-Problemen zuerst fest, ob Ihre Firewall ICMP-Anfragen blockiert und erst danach prüfen Sie Ihre Server- und Client-Konfiguration von vTUN.

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.

Herunterladen und installieren von OLSR

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.

Konfiguration des ROOT-SERVERS und HOME-ROUTERS

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 }

Starten der beiden OLSR-Daemons

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
Wir sollten nun für jede Internet-Anbindung einen VPN-Tunnel laufen haben, welcher dem Port-Channel bond0 hinzugefügt wurde. Durch die Bündelung aller VPN-Tunnel erzielen wir eine höhere Geschwindigkeit gegenüber einer einzigen Leitung.

Dadurch, dass wir den kompletten Daten-Traffic über einen VPN-Tunnel zuerst in ein Rechenzentrum leiten, erhöhen wir unsere Round-Trip-Time. Je nach Anbindung des Rechenzentrums in alle Welt kann es vorkommen, dass ein Download über eine einzige DSL-Leitung schneller gehen würde, als wie über das Rechenzentrum.

Rechenzentren bemühen sich nur um Upstreams zu den Internet-Service-Providern, wie z.B. 1&1, Strato, Deutsche Telekom, Freenet, QSC usw. Verbindungen in die "Außenwelt", sowie zu den unterschiedlichen Rechenzentrum ist dabei nur zweitrangig bzw. überhaupt nur über Austauschknoten realisiert. Direkte Verbindungen zu Rechenzentren existieren meißt nicht, was dann zum Nachteil der Datenverbindungs-Geschwindigkeit werden kann.

Informieren Sie sich also im Vorhinein, über welche Anbindungen Ihr Rechenzentrum verfügt.

Internet-Server-Provider wie z.B. 1&1, Strato, Deutsche Telekom, Freenet, QSC usw. haben meißt direkte Anbindungen an alle Rechenzentren, bzw. bedienen sich Transit-Anbietern wie z.B. COLT Telecom, LEVEL3, Interroute usw. um globalen Traffic abzuhandeln und können daher eventuell schnellere Anbindungen zu verschienden Zielen anbieten.

Bekannte Probleme mit vTUN als Tunnel-Programm

Natürlich hat vTUN auch Nachteile und kann daher in manchen Installationen zu mächtig Ärger führen. Zum Glück gibt es jedoch alternative Software wie z.B. OpenVPN, IPSEC usw. das Grundprinzip bleibt jedoch immer das Selbe.

Bekannte Nachteile:
  • DSL-Verbindungen werden nach 24 Stunden automatisch getrennet, vTUN-Server bekommt von dieser Trennung nichts mit und entfernt den Port des Tunnels nicht aus der Port-Channel-Konfiguration. Alle Pakete welche an diesen Port weitergeleitet werden gehen unweigerlich verloren.

Abschluss

Hoffe euch mit meiner Beschreibung das Prinzip der Bündelung ein wenig näher gebracht zu haben. Wenn noch Fragen existieren, so könnt Ihr euch gerne im Forum dazu unterhalten. Support per eMail / PN liefere ich grundsätzlich nicht.

0 Kommentar(e)

Zum Posten von Kommentaren bitte