|
|
|
 |
 |
 |
Hochverfügbarkeit im Serverbereich - ist dies ein nur Thema für große Unternehmen mit schwergewichtigen IT-Abteilungen und entsprechendem Etat … ? Mitnichten - nach den Vorüberlegungen der vergangenen Themen der Woche zum Thema Hochverfügbarkeit und Cluster können Sie hervorragend mitreden, wenn es um dieses brandaktuelle und immens wichtige Thema geht. Und das Beste kommt zum Schluss: im heutigen Thema der Woche wollen wir Ihnen zeigen, wie Sie mit erstaunlich überschaubaren finanziellen Mitteln eine hochverfügbare Firewall-Lösung für Ihr Unternehmen aufbauen können.
Übrigens: wenn wir in diesem Zusammenhang von Firewalls sprechen, sollen die reinen Routingfunktionalitäten und idealer Weise die Fähigkeiten, ein VPN anzubieten, damit ebenfalls abgedeckt sein. Als praktisches Beispiel dient uns eine Firewall aus mehreren Gründen: zum Einen ist es in vielen Unternehmen ohnehin bereits üblich, Firewalls auf Basis von Linux einzusetzen – und unser «Eigenbau-Cluster» beruht auf Linux. Die Systeme sind sehr stabil und ausgereift, kosten üblicherweise keine Lizenzgebühren (wenn man einmal von den Enterpriselösungen wie Suse Linux Enterprise Server und Red Hat Enterprise Linux absieht) und sind ungemein flexibel. Zum Anderen lässt sich hieran sehr gut ein Kostenvergleich mit proprietären und kommerziellen Systemen anstellen.
Ein Beispiel: ein lokales Netz mit unterschiedlichen Bereichen, für die jeweils eigene (Sub-)Netze eingerichtet werden müssen, soll durch eine Firewall abgesichert werden. Neben den verschiedenen Routingfunktionalitäten dient die Lösung auch als VPN-Gateway, um externen Mitarbeitern und Dienstleistern einen gesicherten Zugang zum Netz des Unternehmens zu ermöglichen. Die IT-Abteilung oder ein externer Berater könnte Ihnen möglicherweise diese (beispielhaft ausgewählten) verschiedenen Lösungen vorschlagen:
- Cisco ASA, recht populäre Systeme, die auch im Cluster betrieben werden können. Sie bieten die beschriebenen Features, allerdings arbeitet Cisco mit einem etwas eigenwilligen Lizensierungsmodell: die Grundausstattung ist eher günstig in der Anschaffung, aber wichtige Features bedeuten oft nicht unerhebliche Mehrkosten. Zudem bieten die Systeme zwar eine grafische Oberfläche, sind aber nicht eben trivial einzurichten. Erfahrene Ciscoadministratoren konfigurieren ein solches Gerät eher auf dem so genannten Command Line Interface, der CLI - mithin also einer Konsole, die ebenso farbenunfroh und Mausfeindlich daherkommt wie die bekannt-berüchtigte DOS-Box unter Windows oder die so genannte Konsole (auch als Terminal bezeichnet) in einem «nackten» Unixsystem. Zwei ASAs können für ein echtes Fail-Over als active/active-Cluster (Sie erinnern sich an das letzte Thema der Woche auf Weka-IT) betrieben werden. Allerdings kostet eine solche, hochverfügbare Firewall-Lösung dann schnell zwischen 7000,- und 11000,- CHF (grob gemittelte Preise vom Februar 2010).
- Fortinets Fortigate: diese Systeme führten lange ein Schattendasein neben den populären Lösungen von Juniper, Checkpoint, Cisco und anderen. Dabei bieten die für den KMU-Einsatz gedachten Fortigate-Serien praktisch alle gängigen Routing-, Firewalling- und VPN-Features. Die Fähigkeit zum Aufbau eines active/active-Clusters ist bei Fortinet schon länger integriert, zumindest in den etwas höherwertigen Geräten. Interessanterweise liegen die clusterfähigen Lösungen preislich noch über den Geräten von Cisco. Dafür sind sie als eine der wenigen Systeme aus diesem Metier durch die ICSA, die International Computer Security Association, zertifiziert.
- Stonesoft Stonegate: die finnische Firma Stonesoft bietet mit ihren integrierten Firewall-, IPS(Intrusion Prevention System)- und VPN-Appliances Lösungen, die weit über reine Routingfunktionalitäten und Firewalling hinausgehen. Die Geräte bieten Hochverfügbarkeit durch Clustering und Load-Balancing. In aktuellen Tests der NSS Labs haben sie ihre technische Ausgereiftheit beeindruckend unter Beweis gestellt. Solche Funktionalität hat allerdings auch ihren Preis: um alle gewünschten Features nutzen zu können, werden verschiedene Appliances benötigt; sollen diese geclustert werden, schlägt eine solche Lösung schnell mit einigen 10000,- CHF zu Buche...
Soweit unser kurzer Überblick - was bereits bei einer ersten Betrachtung der Produktspezifikationen ins Auge fällt, ist die Vielzahl an Features, Ausbaustufen und Lizensierungsmodellen: hat man erst einmal das Lizenzmodell erworben, stehen beispielsweise bei einem Hersteller bis zu 750 gleichzeitige VPN-Verbindungen zur Verfügung. Hand aufs Herz: wie viele davon werden im KMU-Umfeld ernsthaft benötigt…? Hier ist Masse nicht unbedingt Klasse - im Fokus unserer Betrachtungen steht die Möglichkeit, wenige, aber essentielle Features hochverfügbar anzubieten; und hier kommt unsere OpenSource-Lösung zum Zuge.
Firewallappliance im Eigenbau
Mit zwei Serversystemen in der 1500-CHF-Liga - also im überschaubaren Preisrahmen - können Sie oder Ihre IT-Abteilung respektive Ihr IT-Administrator eine hochverfügbare Firewall aufbauen. Grundlage kann ein Debian-System sein, aber auch auf einem Mandriva, Suse, Fedora, Ubuntu oder Red Hat sollte sich dieses Szenario umsetzen lassen. Unter Linux gibt es eine gewisse Auswahl an Software für den Aufbau eines Clusters - neben der reinen Cluster-«Software», gemeinhin als Cluster Ressource Manager (CRM) bezeichnet, ist noch entscheidend, welche Technik die Knoten (die einzelnen Mitgliederserver eines Clusters werden als Knoten bezeichnet) zur Kommunikation und Verständigung untereinander benutzen.
Ein anderes Thema sind übrigens noch High-Performance-Lösungen, die einer Steigerung der Rechenleistungen eines Systems durch Bündelung der Rechnerressourcen dienen, wie etwa MOSIX, Oscar oder der Platform Cluster Manager. Solche Systeme spielen hier aber keine Rolle.
Der Aufbau eines Linux-HA-Clusters ist verhältnismäßig simpel: die Software wird auf beiden Systemen aufgespielt und eingerichtet. Der Cluster Ressource Manager verwaltet dann das Clustersystem und nutzt den quasi darunter liegenden Kommunikationsservice (ursprünglich heartbeat, OpenAIS und Corosync in den neueren Versionen). Die Kommunikation im Cluster ist somit vom Management der Ressourcen getrennt. In den neueren Entwicklungszweigen firmiert die Clusterlösung Linux-HA als pacemaker, OpenAIS soll durch Corosync abgelöst werden. Dem Aufbau und der Funktionalität des Clusters tut dieses natürlich keinen Abbruch – eventuell müssen Sie aber auf die jeweils passenden Pakete und Abhängigkeiten achten.
Unter Debian lässt sich die Clustersoftware durch die Eingabe eines schlichten
aptitude install heartbeat-2 heartbeat-2-gui
auf den Knoten installieren. Die anschließende Konfiguration geschieht über einfache Text- oder XML-Dateien. Sind beide Cluster eingerichtet und die Clusterdienste gestartet, kann als «Generalprobe» einer der Knoten abgeschaltet werden, während ein Ping (ICMP Request) auf den geclusterten Dienst läuft - nach einer kurzen Verzögerung sollte der ICMP Response erfolgen, im Idealfall ohne Verlust eines Paketes.
Keepalived
Aber auch mit LVS, dem Linux Virtual Server Project, lässt sich eine ebenso hochverfügbare wie auf Lastverteilung ausgelegte Firewall aufbauen. Für die Kommunikation der Cluster untereinander wird keepalived< eingesetzt:
| Firewall-clu1:/# aptitude search keepalived |
| p keepalived |
Daemon für LVS-Cluster zur Überwachung und Ausfallsicherung |
Der Knoten Nummer 1 fungiert hier als Master, er erhält beispielsweise die folgende Konfiguration in /etc/keepalived/keepalived.conf:
vrrp_sync_group VG1 {
group {
eth0
eth1
}
}
# Interne virtuelle IP-Adresse
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 1
priority 100
authentication {
auth_type AH
auth_pass password
}
virtual_ipaddress {
10.10.10.1/23 brd 10.10.11.255 dev eth0
}
}
# Externe virtuelle IP-Adresse
vrrp_instance VE_1 {
state MASTER
interface eth1
lvs_sync_daemon_interface eth0
virtual_router_id 2
priority 100
authentication {
auth_type AH
op
en
so
auth_pass password
}
virtual_ipaddress {
172.16.23.1/23 brd 172.16.23.255 dev eth1
}
}
Entsprechend sieht die Konfiguration auf dem Knoten 2, dem Slave, in etwa wie folgt aus:
vrrp_sync_group VG1 {
group {
eth0
eth1
}
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 1
priority 50
authentication {
auth_type AH
auth_pass password
}
virtual_ipaddress {
10.10.10.1/23 brd 10.10.11.255 dev eth0
}
}
vrrp_instance VE_1 {
state BACKUP
interface eth1
lvs_sync_daemon_interface eth0
virtual_router_id 2
priority 50
authentication {
auth_type AH
auth_pass password
}
virtual_ipaddress {
172.16.23.1/23 brd 172.16.23.255 dev eth1
}
}
Beachten Sie, dass nur wenige Änderungen der Konfiguration notwendig sind, um den Master zu bestimmen und um die beiden Systeme IP-technisch voneinander abzugrenzen.
Es fehlt noch eine Technik, um die Verbindungstabellen der Firewall - hier ist es das bekannte iptables - abzugleichen. Eine Firewall hält üblicherweise neben einem festen Regelsatz eine dynamische Tabelle mit den aktuell aufgebauten und verarbeiteten Verbindungen vor. Diese wurde noch vor wenigen Jahren mit dem Netfiltermodul ct_sync abgeglichen, allerdings erwies sich dieses nicht immer als sehr stabil. Inzwischen steht das Modul conntrack zur Verfügung. Dieses kontrolliert nicht nur die interne Verbindungstabelle, sondern sorgt auch für deren Abgleich mit den anderen Knoten des Clusters.
VPN
Nachdem wir erfolgreich die reine Routingfunktionalität einschließlich der gewünschten Filterregeln für unsere Hochverfügbarkeitsfirewall eingerichtet haben, ist noch ein weiteres Features auf unserer Wunschliste, nämlich das in vielen Unternehmen inzwischen so wichtig gewordene VPN, das virtuelle private Netzwerk (Weka-IT stellte Ihnen diese Technik und verschiedene Lösungen dazu an dieser Stelle bereits umfassend vor). Noch einmal kurz rekapituliert: ein VPN baut zwischen zwei Partnern einer eigentlich unsicheren (da über ein nicht vertrauliches Netz hinweg geführten) Verbindung mittels Verschlüsselungstechniken und Authentizitätsprüfungen eine als sehr sicher anzusehende Verbindung auf, den so genannten VPN-Tunnel. Und in eben dieser Vertraulichkeit liegt der Hase im Pfeffer: eine VPN-Verbindung wird zwischen exakt einem Server und dessen Partner aufgebaut; fällt der entsprechende Server aus und übernimmt eine andere Maschine im Cluster dessen Funktionen, ist die Vertraulichkeit und Authentizität zwischen zwei exklusiven Partnern dahin. Vereinfacht gesagt, gibt es hierfür zwei Lösungen:
- die Schlüssel werden ständig mit ausgetauscht; ob dies möglich ist, liegt an der jeweiligen VPN-Implementierung. Nicht alle VPN-Lösungen unterstützen dieses Feature
- der Tunnel wird vom Ersatzsystem neu aufgebaut.
Praktischerweise bieten populäre VPN-Lösungen wie IPSec und OpenVPN diese Möglichkeit bereits. VPN-Tunnel können ohnehin auf mannigfaltige Weise unterbrochen werden (lokale Störungen auf einem der beteiligten Partner, Netzausfälle im LAN oder WAN), weshalb es in der Regel eine als keepalive oder ähnliches benannte Funktion gibt (nicht zu verwechseln mit unserem keepalived!), bei der einer der VPN-Partner (oder beide) die Konnektivität des Tunnels prüfen und bei Ausbleiben dieser die Verbindung neu aufbauen können. Fällt in einem active/active-Cluster einer der Server aus, startet der aktive Knoten die Verbindung nach einer gewissen Auszeit (TimeOut) neu. Bei dem OpenSource-VPN OpenVPN lässt sich dieses Prozedere beispielsweise dermaßen stabil und performant einrichten, dass sogar die im Tunnel verwendeten, virtuellen IP-Adressen zwischen den Partnern synchronisiert und die TimeOut-Zeiten sehr gering gehalten werden. Eine bestehende Verbindung würde dann nicht einmal abreißen, sondern lediglich eine kurze Verzögerung erfahren - so, wie es etwa in WLANs mit deren schwankender Sendequalität auch nicht eben unüblich ist.
Übrigens ist dieses Szenario nicht zu verwechseln mit einem VPN Load Balancing Cluster, der die Verbindungen auf verschiedene Maschinen im Clusterverbund verteilt. Hier müssen bei einem Ausfall selbstredend die Verbindungen wieder von den anderen Servern neu aufgebaut werden, was ohne Übernahme von Schlüssel, IP-Einstellungen und Status der offenen Verbindungen zwangsläufig zu einem längeren Ausfall und vor allem zu einem Abbruch aller durch den Tunnel geleiteten Verbindungen führt.
Nachdem Firewall und VPN ausfallsicher laufen, sind Sie vielleicht auf den Geschmack gekommen? Tatsächlich lässt sich mit den hier beschriebenen Szenarien eine Vielzahl an Servern und Serverdiensten hochverfügbar einrichten: ein Apache-Webserver, ein Mailserver, der zentrale Datenserver ... Neben IT-Dienstleistern, die Ihnen ein solches System maßgeschneidert liefern können, gibt es natürlich auch die Möglichkeit, sich auf entsprechenden Seminaren das nötige Know-How zu holen. Die Kosten dafür sind gar nicht einmal so hoch, wenn man sich vor Augen hält, dass Sie oder Ihre IT-Fachkräfte anschließend vermutlich in der Lage sein werden, sehr flexible und in Anbetracht der kommerziellen Lösungen erstaunlich günstige Hochverfügbarkeits-Server aufzusetzen.
Fazit
Viele Wege führen nach Rom – und ebenso gibt es ein weites Feld an Lösungen für eine Hochverfügbarkeit Ihrer IT-Services. Die angesichts der in diesem Rahmen gebotenen Kürze lediglich angerissene Clusterlösung ist dabei weder eine «Bastellösung» noch lediglich eine für ausgekochte Profis. Ganz im Gegenteil: durch den Aufbau eines eigenen Clusters werden Sie oder Ihr Admin zu einem tieferen Verständnis der zugrundeliegenden Technik gelangen. Womöglich lassen Sie sich nicht mehr von den Hochglanzbroschüren (oder den entsprechenden Internetauftritten) so manches renommierten Herstellers blenden - womöglich gewinnen Sie aber auch gerade dadurch die Überzeugung, lieber auf ein teureres, aber mit entsprechendem Support durch den Hersteller versehenes Produkt zu setzen - es liegt ganz an Ihnen, den Anforderungen Ihres IT-Szenarios und natürlich an Ihrem IT-Etat. Wichtigste Quintessenz unserer Betrachtungen sollte aber sein, dass Hochverfügbarkeit kein Hexenwerk ist – und vor allem kein Luxus; eher sollte sich modernes IT-Management fragen, ob es sich den Verzicht darauf leisten kann und will.
Hier gelangen Sie direkt zum Download
|
|
|
|
 |
| |
|
|
|
 |
Dipl.-Paed Lars Behrens
Herr Behrens ist Geschäftsführer der Firma MaLiWi IT. Staatlich geprüfter Netzwerkadministrator, Microsoft MCP / Linux LCP. Herr Behrens hat langjährige Erfahrung in der Beratung bei Planung und Einrichtung von IT-Systemen und Netzwerken und dem Support heterogener Systeme (Apple Macintosh, Microsoft Windows, Linux). Universitätsstudium der Pädagogik, mehrere Jahre Tätigkeit im Ausland. Seminar- und Kursleiter, Referent und Fachbuchautor.
|
|
 |
|
 |
 |
Fernzugriff mit TeamViewer: Fernwartung, Fernzugriff, Remote Control, das Ende der Turnschuhadministration - Schlagworte, die sicher jedem IT-Administrator und -verantwortlichen geläufig sind. Gemeint ist, dass die allfällige Wartung eines Rechners und vor allem die Unterstützung der Benutzer bei Fragen und Problemen nicht mehr direkt am Gerät erfolgt, sondern vom PC des Admins aus über das Intra- oder Internet hinweg. Heute sehen wir uns einmal eine interessante Lösung für diesen Fernzugriff an, die keine Client-Server-Infrastruktur und keine aufwändig einzurichtenden VPN-Tunnel benötigt: TeamViewer.
|
|
|
|
|
|
Hotline-Warteschleifen – Wie man sich gegen Abzockerei wehrt: Oft ärgert man sich über Warteschleifen, wenn man eine Dienstleistungstelefonnummer anruft. Ist diese gebührenpflichtig, kann man die Regeln des OR über Schlechterfüllung anwenden und Schadenersatz verlangen.
Wenn man eine geführenpflichtige Hotline anruft, kommt ein Vertrag zustande. Der Anrufer erwartet eine Dienstleistung. Dies kann eine Beratung sein oder beispielsweise die Vorbestellung eines Veranstaltungsbilletes. Wird der Anrufer in eine gebührenpflichtige Warteschleife umgeleitet, kann das verschiedene Gründe haben.
Natürlich gibt es immer wieder Zeiten, während denen die Servicemitarbeitenden überlastet sind. Dann wäre es korrekt, die Wartezeit und ihre Kosten vorher anzugeben oder noch besser, die Warteschleife gebührenfrei zu gestalten. Das ist technisch möglich. Für Beschwerden, Anfragen oder Reklamationen von Kunde sollte die Hotline kostenlos sein.
|
|
|
|
|
|
Sind Sie bereit für IPv6?: IPv6 wird kommen - im letzten «Thema der Woche» hatten wir einiges über die Hintergründe dieser Entwicklung aufgezeigt. Zwar steht die nächste Generation des weltweiten Standards für Internetprotokolle seit Jahren immer nur in den Startlöchern, ohne es bisher geschafft zu haben, IPv4 abzulösen. Dennoch ist dieser Schritt unausweichlich und überfällig - zu knapp war seinerzeit der Adressraum in IPv4 berechnet worden und zu sehr leiden bereits einige Regionen - vor allem im boomenden fernen Osten - unter der Adressenverknappung. Die Umstellung unseres Internets auf IPv6 ist also nur noch eine Frage des Zeitpunkts.
|
|
|
|
|
|
zeige die ersten 25
|
|
|
|
|
|
|
|
|
