© Dmitriy Karelin, 123RF.com

Nicht nur im Rechenzentrum kann eine ausfallsichere Verbindung nicht schaden. Mit Hilfe von Bonding, Hostapd und Dnsmasq lässt sich ein Laptop auch in einen Accesspoint verwandeln, der redundant über mehrere Fäden im Internet hängt.

Bonding, also die Möglichkeit, mehrere Netzwerkgeräte in einem Interface zu bündeln, ist vor allem in Rechenzentren beliebt. Die Bonding-Technologie steckte bereits im Kernel 2.0.30 von 1997 und wurde im Laufe der Zeit sukzessive ausgebaut. Das neueste Stück Dokumentation stammt von 2011 und steht unter [1] zur Ansicht bereit.

Dank sieben verschiedener Bonding-Varianten (siehe Kasten “Die sieben Bonding-Modi”) können Admins wahlweise Load Balancing betreiben oder für ihre Netze eine höhere Ausfalltoleranz erreichen: Stolpert ein Techniker im Data Center über ein Netzwerkkabel, läuft der Traffic über ein anderes Kabel im Bonding weiter.

Doch es gibt auch andere Szenarien, in denen Bonding nützlich wäre. Auf Konferenzen mit notorisch anfälligen WLAN-Netzwerken ließen sich die Laptops der Redner per Bonding zuverlässiger ans Internet binden. Veranstalter in einer Gegend mit eingeschränktem Internetempfang können UMTS-Verbindungen auf einem Rechner bündeln, der dann als Accesspoint (AP) zum Einsatz kommt.

Ein Bond fürs Leben

Im vorgestellten Bonding-Setup besteht der erste Schritt darin, ein Bündel aus zwei WLAN- und einem Ethernet-Client zu schnüren. Dabei hilft das zu installierende Paket »ifenslave-2.6« , das ein »sudo apt-get ifenslave-2.6« auf dem eingesetzten Lubuntu installiert. Dann bearbeitet der Netzwerker die Datei »/etc/network/interfaces« , wie es Listing 1 zeigt, wobei er am besten erst ein Backup der Originaldatei anlegt.

01 auto eth0
02 iface eth0 inet dhcp
03    bond-master bond0
04    bond-primary wlan0
05    bond-mode active-backup
06
07 auto wlan0
08 iface wlan0 inet dhcp
09    wpa-conf /etc/network/wpa1.conf
10    bond-master bond0
11    bond-primary wlan0
12    bond-mode active-backup
13
14 auto wlan1
15 iface wlan1 inet dhcp
16    wpa-conf /etc/network/wpa1.conf
17    bond-master bond0
18    bond-primary wlan0
19    bond-mode active-backup
20
21 auto bond0
22 iface bond0 inet dhcp
23    bond-slaves none
24    bond-give-a-chance 20
25    bond-mode active-backup
26    bond-miimon 100

Die Einträge sind recht simpel gestrickt, Bonding funktioniert nach dem Master-Slave-Prinzip: Die Datei ordnet die Netzwerkgeräte dem »bond-master bond0« zu. Als Bonding-Modus kommt Modus 1 (»active-backup« ) zum Einsatz. Die WLAN-Clients holen sich die Zugangsdaten für den Accesspoint aus den Dateien »/etc/network/wpa1.conf« (Listing 2) und »/etc/network/wpa2 .conf« . Die Option »bond-slaves none« ist etwas kontra-intuitiv: Es geht darum, die Slaves nicht erneut zu starten, während das Gesamtgebilde »bond0« aktiviert wird. Der Parameter »bond-give-a-chance 20« lässt den WLAN-Geräten ein wenig Zeit, um sich mit den Accesspoints zu verbinden.

01 network={
02         ssid="SSID"
03         proto=RSN
04         key_mgmt=WPA-PSK
05         pairwise=CCMP TKIP
06         group=CCMP TKIP
07         psk="Passwort"
08         }

Schaut sich der Netzwerker nach einem Reboot über »/sbin/ifconfig« die vorhandenen Devices an, sollte der Anblick Abbildung 1 ähneln. Es fällt schnell auf, dass »bond0« , »eth0« , »wlan0« sowie »wlan1« die gleiche MAC-Adresse aufweisen. Ob diese Geräte online sind, verrät ein einfaches »cat /proc/net/bonding/bind0« . Die Ausgabe »MII Status = up« zeigt jeweils, ob ein Gerät aktiv ist. Pingt ein Admin nun eine beliebige Webadresse an, sollten auch dann weiterhin Antworten eintrudeln, wenn er das Ethernet-Kabel entfernt oder ein WLAN-Kernelmodul deaktiviert.

Abbildung 1: Nach dem Bonding-Prozess existiert nicht nur ein neues Device namens »bond0«, alle Netzwerk-Clients besitzen auch identische MAC-Adressen.

Im Testaufbau verfügt der Rechner über zwei WLAN-Clients und einen Ethernet-Zugang. Anstelle der WLAN-Clients lassen sich auch ein oder mehrere UMTS-Geräte einsetzen, falls keine Accesspoints zur Verfügung stehen und jemand zum Beispiel in einer schlecht angebundenen Gegend eine halbwegs zuverlässige Internetanbindung benötigt. Beispiele für Ubuntu und Debian gibt es etwa unter [2].

Selfmade AP

Im vorliegenden Szenario soll der Rechner mehrere Internetzugänge bündeln und zugleich als Accesspoint dienen. Um das zu erreichen, installiert der Anwender die Pakete »hostapd« , »dnsmasq« und »iw« . Dann wendet er sich zunächst der Datei »/etc/network/interfaces« zu. Hier gilt es, den WLAN-Client, der die AP-Funktionen übernehmen soll, aus dem Bonding herauszunehmen.

Dazu wird in Listing 1 der mit »auto wlan0« beginnende Abschnitt gemäß Listing 3 geändert. Das WLAN-Device »wlan0« erhält eine feste IP-Adresse aus einem anderen Subnetz, während »wlan1« im Verbund mit »eth0« die Verbindung ins Internet hält.

01 # Update zu Listing 2
02 auto wlan0
03 iface wlan0 inet static
04    address 10.10.0.1
05    netmask 255.255.255.0

Die Authentifizierungssoftware Hostapd [3] ermöglicht es, »wlan0« als Accesspoint zu konfigurieren, der auch verschlüsselte Anmeldungen über WPA 2 Personal erlaubt. Über den »nl80211« -Treiber unterstützt Hostapd eine Reihe neuerer WLAN-Chips, für ältere stehen lediglich »HostAP« , »madwifi« und »prism54« als Treiber bereit.

Generell ist es für den Einsatz als Accesspoint von Vorteil, wenn Hardware mit stabilen und gut unterstützten Treibern zum Zuge kommt. Andernfalls treten bei den Zugriffen verschiedener Clients auf den Accesspoint Probleme auf. Troubleshooting erlaubt der Befehl:

tcpdump -nn -i wlanX

Er hilft dem Admin den Netzwerk-Traffic, der über das Device »wlanX« läuft, im Auge zu behalten und eventuelle Fehler zu analysieren.

Nach der Installation von »hostapd« legt der Anwender zunächst die WLAN-Karte fest, die als Accesspoint auftreten soll, im Beispiel »wlan0« . Wer sich für die Bedeutung der einzelnen Optionen interessiert, kann diese unter [4] nachlesen. Kurz gesagt wird hier »wlan0« zum Accesspoint mit dem Namen »SSID« gemacht. Rechner, die sich mit dem AP verbinden möchten, brauchen ein entsprechendes »Passwort« und nutzen eine sichere WPA-PSK-Verschlüsselung.

Verwendet der AP-Betreiber nur eine Ethernet-Karte für den Internetzugang, kann er in der Datei »/etc/network/interfaces« auch eine Bridge (»br0« ) anlegen. Die ergänzt er ebenfalls in Listing 4, indem er die Zeile »bridge=br0« nach »interface=wlan0« einträgt.

01 interface=wlan0
02 driver=nl80211
03 ssid=SSID
04 hw_mode=g
05 channel=1
06 macaddr_acl=0
07 auth_algs=1
08 ignore_broadcast_ssid=0
09 wpa=3
10 wpa_passphrase=Passwort
11 wpa_key_mgmt=WPA-PSK
12 wpa_pairwise=TKIP
13 rsn_pairwise=CCMP

Damit der Hostapd-Daemon nach dem Start des Systems auch gleich automatisch losrennt, benötigt er noch eine entsprechende Anweisung in der Datei »/etc/default/hostapd« . Hier entfernt der Netzwerker das Kommentarzeichen vor der Zeile »DAEMON_CONF=”/etc/hostapd/hostapd.conf”« .

Dnsmasq

Dnsmasq ist nicht nur DNS-, sondern auch DHCP-Server, seine zahlreichen Funktionen und die möglichen Optionen für die Konfigurationsdatei beschreibt [5] ausführlich. Das ist hilfreich, weil der Accesspoint nach dem Neustart des Rechners zwar zu sehen ist, aber zunächst keine IP-Adressen verteilt. Über

sudo cp /etc/dnsmasq.conf /etc/dnsmasq. conf.BACKUP

legt der User ein Backup der Default-Konfiguration für Dnsmasq an und erstellt dann eine eigene Datei, wie sie Listing 5 zeigt. Dnsmasq wird an das Interface »wlan0« gebunden, soll aber nicht die Datei »/etc/hosts« lesen, sondern die selbst angelegte »/etc/hosts.ap« . In dieser sollen der Pfad zum Gateway von »wlan0« sowie der Name des Rechners stehen, auf dem der Accesspoint läuft:

10.10.0.1 Rechnername

Die Datei »resolv.conf« ignoriert Dnsmasq dank des Eintrags. Bei Problemen mit der DNS-Auflösung lassen sich hier auch eigene DNS-Server eintragen, etwa die von Google, die Listing 5 auskommentiert. Der Parameter »dhcp-range« legt den Bereich an IP-Adressen fest, die »/etc/dnsmasq.conf« verteilt, gefolgt von der Subnetzmaske und der Lease-Time, die hier auf unendlich (»infinite« ) steht. Der Eintrag »dhcp-option« setzt die Standardroute (»3« ) auf »10.10.0.1« .

01 bind-interfaces
02 interface=wlan0
03
04 no-resolv
05 no-hosts
06 addn-hosts=/etc/hosts.ap
07
08 # server=8.8.8.8
09 # server=8.8.4.4
10
11 dhcp-range=10.10.0.2,10.10.0.20,255.255.255.0,infinite
12 dhcp-option=3,10.10.0.1

Vorwärts Pakete!

Noch ist nicht alles in Butter, denn das System soll die Pakete von »bond0« an »wlan0« weiterreichen, damit die Clients über den Accesspoint auch Internetzugang erhalten. Dazu ändert der Admin zunächst die Datei »/etc/sysctl.conf« und kommentiert die Zeile

net.ipv4.ip_forward=1

aus. Dann kümmern sich die folgenden IPtables-Befehle um das Forwarding und Masquerading. Hier gilt es, in den ersten beiden Schritten die Forwarding-Regeln zu löschen und neue zu erstellen. Der dritte Befehl leitet schließlich Pakete, die aus dem Subnetz »10.10.0.0« kommen, an »bond0« weiter:

iptables -F FORWARD
iptables -P FORWARD ACCEPT
iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -o bond0 -j MASQUERADE

Die Befehle kann der Admin in der Datei »/etc/rc.local« unterbringen, so werden sie beim Systemstart geladen.

Fazit

Gänzlich stabil lief der selbst gebastelte Accesspoint im Test noch nicht, was auch an der Hardware gelegen haben mag. Gerade die sollte der Admin vor einem dauerhaften Einsatz ausführlich testen, damit sie möglichst stabil läuft. Wurden beim Browsen viele URLs aufgerufen, kam es nach einiger Zeit zu DNS-Ausfällen. Dienste ohne große DNS-Anfragen liefen hingegen deutlich länger stabil, der Accesspoint und die Bonding-Gemeinschaft ebenfalls. Insgesamt erwies sich Bonding als eine recht schnell einzurichtende Möglichkeit, um ausfallsicher und redundant ins Internet zu kommen – auf Wunsch auch drahtlos.