HA und VPN behindern sich: Die Verschlüsselung und Signatur von IPsec unterbindet viele der Tricks, die High-Availability-Produkte üblicherweise anwenden. Unter bestimmten Voraussetzungen gelingt der Spagat dennoch, ohne die Sicherheit des VPN auszuhebeln.
Der Wunsch nach einem Failover für die Datenleitung zwischen zwei Standorten besteht, seit es Datenleitungen gibt. Fällt eine Anbindung aus, soll möglichst unbemerkt die Reserveleitung übernehmen. Wenn die Daten VPN-typisch per IPsec durch das Internet laufen, ist eine Backup-Verbindung nur mit viel Aufwand herzustellen. Unübersehbar viele Geräte und administrative Zuständigkeiten sind unter einen Hut zu bringen.
Das Border Gateway Protocol (BGP,[1]) wäre eine zuverlässige Technik, um mit mehreren Providern gleichzeitig IP-Adressen hochverfügbar vorzuhalten. Besonders praktisch: Diese Vorgehensweise hat keine negativen Folgen für die Verschlüsselung mit IPsec ([2],[3]), da sich die IP-Adressen der Tunnel-Endpunkte nicht ändern. Dummerweise verhindern es oft die Verträge mit dem Provider, diese Methode am bestehenden Internetanschluss einzusetzen.
Als Ausweg verzichten viele Admins auf jede Automatik und schalten im Ernstfall selbst zwischen Standard- und Backup-Leitung um, oft sogar durch manuelles Umstöpseln der Interfaces. Dazu müssen sich die Zuständigen auf beiden Seiten der Leitung telefonisch absprechen. In Zeiten der modernen IT ist das sehr unbefriedigend. Die Netzwerkgeräte sollten selbst bemerken, wenn eine Leitung ausfällt, und automatisch umschalten. Ideal wäre ein System, das die Einstellungen für beide Endpunkte aus einer zentralen Konfiguration generiert.
Für Firewalls und IPsec-Gateways ist die zentrale Konfiguration heute Stand der Technik; unter Linux erfüllt beispielsweise SSPE diese Aufgabe (Simple Security Policy Editor,[4]). Eine Integration der in diesem Artikel vorgestellten HA-Lösung in SSPE steht allerdings noch an.
Linux hoch verfügbar
Der Hochverfügbarkeit von Linux-Servern hat sich das Linux-HA-Projekt verschrieben ([5],[6],[7]). Mit dieser Software gelingt auch ein hochverfügbares VPN, das ohne BGP auskommt und möglicherweise sogar schneller zwischen Normal- und Backup-Betrieb umschaltet: Es setzt zwei unabhängige Tunnel parallel ein, benutzt zu jedem Zeitpunkt aber nur einen der beiden. Jeder Tunnel hat in jedem Netz einen eigenen Endpunkt auf einem eigenen Rechner, der als Gateway für das lokale Netz dient. Linux-HA enthält dazu bereits das gegenseitige Übernehmen von IP-Adressen als fertige Lösung.
Zwei HA-Knoten besitzen je eine eigene sowie eine gemeinsame IP-Adresse. Die gemeinsame Adresse verwendet zu jedem Zeitpunkt nur eine der beiden Maschinen. Gedacht ist der Mechanismus dafür, auf der gemeinsamen IP einen Server (Web, E-Mail …) zu betreiben. Dieser Dienst ist auf beiden Maschinen aktiv und lauscht auf jede Adresse (er ist an 0.0.0.0 gebunden), allerdings kommen Anfragen nur auf die gemeinsame IP. Damit kann Linux-HA die von außen benutzte Adresse im Bedarfsfall auf den zweiten Rechner übertragen, der Anwender sollte von einem Ausfall des ersten Rechners wenig bemerken.
Ein serielles Kabel sorgt für den so genannten Heartbeat zwischen den beiden Maschinen. Heartbeat ist ein Bestandteil von Linux-HA, die beteiligten Rechner überwachen so ihre Verfügbarkeit gegenseitig. Beim Ausfall übernimmt der zweite Rechner die IP-Adresse vom ersten: Er schickt ARP-Broadcasts mit der gemeinsamen IP und seiner eigenen MAC-Adresse ins LAN (betreibt damit legales ARP-Spoofing,[8]) und fährt ein Interface-Alias hoch.
Wenn der erste Knoten wieder verfügbar ist, stellt das Heartbeat-Protokoll sicher, dass der zweite das Interface-Alias wieder herunterfährt, während der erste es hochfährt und seinerseits ARP-Broadcasts ins LAN sendet.
Zwei parallele Linux-HA-Installationen
Das in Abbildung 1 gezeigte Beispiel stellt links Firma A und rechts Firma B dar. Je ein IPsec-Gateway bei A (links, »gw-aa«) und B (rechts, »gw-ba«) befördert die Pakete per ESP durch den Tunnel (Encapsulating Security Payload, ein IPsec-Protokoll). Der Ersatztunnel 2 ist auf den oberen beiden Backup-Routern (»gw-ab«, »gw-bb«) ähnlich konfiguriert wie der Tunnel 1 auf den beiden unteren, im normalen Betrieb benutzten Gateways.

Abbildung 1: In diesem Szenario sind die beiden Netze der Firmen A und B per VPN verbunden. Die Anbindung läuft über zwei alternative Strecken, bei Bedarf übernimmt Tunnel 2 die Aufgabe von Tunnel 1. Zusätzlich ist ein externer Dienstleister ohne HA-Funktion angebunden.
Linux-HA läuft zwischen »gw-aa« und »gw-ab« ebenso wie zwischen »gw-ba« und »gw-bb«. Der Heartbeat verwendet die sonst überflüssige serielle Schnittstelle und arbeitet damit losgelöst von Netzwerk, IPsec und IPtables. Beide HA-Installationen funktionieren separat und voneinander unabhängig. Im Normalfall besitzen »gw-aa« und »gw-ba« die jeweilige lokale Router-IP (links 10.1.255.254 und rechts 10.31.0.254). Im Backup-Fall wechseln diese Adressen zu »gw-ab« und »gw-bb«. Damit der Administrator beide Rechner eines HA-Verbunds auch gezielt erreichen kann, haben sie zusätzlich je eine eigene feste Adresse im jeweiligen LAN, bei »gw-bb« zum Beispiel 10.31.0.252.
Wer für einzelne Teilnehmer diesen Aufwand scheut, kann sie auch ohne HA in das Konzept einbinden. Tunnel 3 in Abbildung 1 zeigt das anhand eines Service-Providers. Er ist nur mit dem normalen Gateway »gw-ba« der Firma B verbunden. Im Backup-Fall bleibt er eventuell unerreichbar. Solange jedoch der zum Backup führende Fehler außerhalb des ISP am »gw-ba« geschieht, sollte auch der Service-Provider nichts vom Ausfall bemerken. Nur bei Fehlern im Bereich von ISP 4, ISP 5 oder des Service-Providers geht nichts mehr.
Mit Skripting zum HA-VPN
Auf den per Default genutzten Gateways »gw-aa« und »gw-ba« läuft je ein Shellskript wie in Listing 1. Es wird von einem »inittab«-Eintrag gestartet und überwacht die Erreichbarkeit des anderen Endes unabhängig vom IPsec-Tunnel. Dazu nutzt es kurze UDP-Pakete auf dem Echo-Port. Das so genannte Echoping ist Bestandteil normaler Linux-Distributionen und verwendet bei geeigneten Optionen das UDP-Protokoll. Damit umgeht es Probleme mit übereifrigen Firewalls, die sämtliche ICMP-Nachrichten wegfangen und damit auch normale Pings blockieren.
|
Listing 1: |
|---|
01 #!/bin/bash
02 # HA-VPN-Supervisor auf gw-aa
03
04 # Das andere Tunnel-Ende
05 TARGET="gw-ba"
06
07 # Anzahl Sekunden zwischen den Pings
08 TIMEOUT=1
09
10 # Das Skript wartet MAXFAIL * TIMEOUT Sekunden, bevor das Backup übernimmt
11 MAXFAIL=5
12
13 # Das Skript wartet HYSTERE * TIMEOUT Sekunden nach dem Ende eines Fehlers,
14 # bevor es wieder auf den Normalbetrieb zurückschaltet
15 HYSTERE=180
16
17 # Annahme: Beim Start liegt kein Fehler vor
18 FAIL=0
19
20 VERBOSE=""
21
22 ACTION_FAIL_START="/root/bin/HA-VPN-action-script start"
23 ACTION_OK_AGAIN="/root/bin/HA-VPN-action-script stop"
24
25 PING=/usr/bin/echoping
26 LOG="/usr/bin/logger -t HA-VPN"
27
28 math () {
29 eval echo "$(($*))"
30 }
31
32 echo "`date +%Y%m%d%H%M%S` `basename $0` starting" | $LOG
33
34 while :
35 do
36 VAL=`$PING ${VERBOSE} -u -t $TIMEOUT -s 5 ${TARGET} 2>&1`
37 ERROR=$?
38 if [ $ERROR -gt 0 ] ; then
39 echo "$DAT $ERROR $FAIL $VAL" | $LOG
40 # Timeout eingetreten
41 if [ $FAIL -lt 0 ] ; then
42 # Erneuter Fehler während der Erholungsphase aufgetreten
43 FAIL=`math $MAXFAIL + 1`
44 fi
45 if [ $FAIL -eq $MAXFAIL ] ; then
46 # Backup starten
47 :
48 FAIL=`math $FAIL + 1`
49 echo "$DAT starting backup now: ${ACTION_FAIL_START}" | $LOG
50 ${ACTION_FAIL_START}
51 else
52 if [ $FAIL -lt $MAXFAIL ] ; then
53 FAIL=`math $FAIL + 1`
54 fi
55 fi
56 else
57 # Ping war erfolgreich
58 if [ $FAIL -gt $MAXFAIL ] ; then
59 FAIL=`math 0 - $HYSTERE `
60 fi
61 if [ $FAIL -le $MAXFAIL -a $FAIL -ge 0 ] ; then
62 FAIL=0
63 fi
64 if [ $FAIL -lt 0 ] ; then
65 # Warte die Hysterese-Zeit ab vor einem Neustart
66 echo "$DAT $ERROR $FAIL $VAL" | $LOG
67 FAIL=`math $FAIL + 1`
68 if [ $FAIL -eq 0 ] ; then
69 # Normalbetrieb wiederherstellen
70 :
71 echo "$DAT normal again now: ${ACTION_OK_AGAIN}" | $LOG
72 ${ACTION_OK_AGAIN}
73 fi
74 fi
75 fi
76 #echo "$DAT $ERROR $FAIL $VAL" | $LOG
77 sleep $TIMEOUT
78 done
79 # wird nie erreicht:
80 exit 0
|
Wenn die Verbindung zwischen »gw-aa« und »gw-ba« in Ordnung ist, bleibt der Zähler »FAIL« auf null. Bleibt ein Ping ohne Antwort, erhöht das Skript in Zeile 53 die Variable »FAIL« um eins, wenn der Wert unterhalb von »MAXFAIL« bleibt. Ist das nächste Ping okay, setzt es »FAIL« wieder auf null zurück (Zeile 62). Erreicht der Wert jedoch »MAXFAIL«, ruft Zeile 50 das Programm »ACTION _FAIL_START« auf (Listing 2 mit Parameter »start«). Dieses fährt den Heartbeat lokal herunter, wodurch automatisch das Backup-Gateway die lokale Router-IP übernimmt.
Warten auf den Normalbetrieb
Die Endlosschleife läuft weiter, irgendwann wird die Leitung wieder ihre Funktion aufnehmen und Echoping wieder mit Rückgabewert 0 beendet. Mit dem ersten Antwortpaket nach einem lang andauernden Fehler steht die Leitung eventuell noch nicht stabil, daher wartet das Skript noch etwas, bis das Gateway wieder in Betrieb geht. Es setzt dazu »FAIL« auf den negierten Wert von »HYSTERE« (Zeile 59). Mit jedem weiteren erfolgreichen Ping erhöht es »FAIL« um eins (Zeile 67).
Beim ersten Fehlschlag während der Erholungsphase setzt Zeile 43 die Variable »FAIL« sofort auf einen Wert größer als »MAXFAIL« – so bleibt es bei der Backup-Variante. Erst wenn »FAIL« bei null ankommt, ist wieder alles okay und das Skript ruft »ACTION_OK_AGAIN« auf (Listing 2, Zeile 71, Parameter »stop«). Dieses Programm erledigt den Restart des Heartbeat und damit die erneute Übernahme der lokalen Router-IP.
Das mehrstufige Verfahren vermeidet so genannte Routing-Flipflops, bei denen die Gateways ständig zwischen beiden Tunneln umschalten. Kurzfristige Ausfälle und ebenso kurzfristiges Wieder-online-Gehen ist bei Internetverbindungen häufiger zu beobachten. Die Logdateien sprechen für sich. Drei Minuten haben sich bewährt, um trotz wackelnder Verbindungen einen stabilen Betrieb zu ermöglichen.
|
Listing 2: |
|---|
01 #!/bin/bash
02 # HA-VPN-Aktionsskript
03
04 #VERBOSE=-v
05 VERBOSE=""
06
07 NAME=`basename $0`
08 LOG="/usr/bin/logger -t HA-VPN"
09
10 PARAMETER_FAULT=0
11
12 if [ $# -ne 1 ] ; then
13 PARAMETER_FAULT=1
14 else
15 PARAMETER=$1
16 case $PARAMETER in
17 start) ;;
18 stop) ;;
19 *) PARAMETER_FAULT=1 ;;
20 esac
21 fi
22
23 if [ $PARAMETER_FAULT -ne 0 ] ; then
24 $LOG " ${NAME}: called with :$*: ==> parameter error, abort"
25 echo "`date +%Y%m%d%H%M%S` ${NAME}: parameter error, abort"
26 exit 1
27 fi
28
29 ACTION_FAIL_START="/etc/init.d/heartbeat stop"
30 ACTION_OK_AGAIN="/etc/init.d/heartbeat start"
31
32 case $PARAMETER in
33 start) $LOG ${ACTION_FAIL_START} ;
34 ${ACTION_FAIL_START} ;;
35 stop) $LOG ${ACTION_OK_AGAIN} ;
36 ${ACTION_OK_AGAIN} ;;
37 esac
38
39 # Ohne Fehlercode beenden
40 exit 0
|
Die Erfahrung im Betrieb eines solchen Setups beim Autor zeigt, dass die Ausfälle stets symmetrisch verliefen. Fährt der Heartbeat auf einer Seite des Tunnels das Gateway herunter, folgt das andere Ende mit einer maximalen Abweichung von einer Sekunde. Die Logdatei-Analyse setzt dafür allerdings synchronisierte Systemuhren voraus.
Zufriedenheit als Maßstab
Die beschriebene Lösung ist seit Anfang 2004 im Einsatz und hat mehrfach gezeigt, dass die Benutzer Ausfälle von Routern der Provider nicht bemerkten. Die zehn Sekunden Wartezeit, bis nach einem Totalausfall das Backup den Tunnel übernimmt, überbrücken die TCP/IP-Stacks der Applikationsserver und Client-PCs durch ihre normalen Retry-Mechanismen. Die in diesem Umfeld früher zu beklagenden Abbrüche gehören der Vergangenheit an.
Die Backup-Verbindung arbeitet im beschriebenen Setup ohne Überwachung. Wenn sie über andere Provider realisiert ist als die Standardleitung, sollte ein gleichzeitiger Ausfall relativ unwahrscheinlich sein. Selbst BGP würde dabei nicht helfen. Nach der Feuertaufe steht der Verbreitung des Konzepts dank Open Source nichts im Wege. (fjl)
|
Infos |
|---|
|
[1] RFC 1745, “BGP4/IDRP for IP-OSPF Interaction”: [http://www.ietf.org/rfc/rfc1745.txt] [2] RFC 2401, “Security Architecture for IP”: [http://www.ietf.org/rfc/rfc2401.txt] [3] Freeswan: [http://www.freeswan.ca/code/super-freeswan/] [4] SSPE: [http://sspe.sourceforge.net] [5] Linux-HA: [http://www.linux-ha.org] [6] Andreas Sebald, “Linux HA-Cluster mit Heartbeat und DRBD”: Linux-Magazin 07/04, S. 60 [7] André Bonhôte, “Hochverfügbarer NFS-Server mit Linux-Heartbeat”: Linux-Magazin 07/03, S. 46 [8] Thomas Demuth und Achim Leitner, “ARP-Spoofing und -Poisoning”: Linux-Magazin 06/04, S. 34 |
|
Der Autor |
|---|
|
Johannes Hubertz verwendet Linux seit 0.99.2, vor allem weil er dort jedes Detail genau analysieren kann. Professionell administriert er Linux-Systeme seit 1996 bei einer großen europäischen IT-Firma auf einigen dutzend Maschinen. |






