17Redundanz

Es gibt verschiedene Möglichkeiten mit dem mGuard  Fehler so zu kompensieren, dass eine bestehende Verbindung nicht unterbrochen wird.

–Firewall-Redundanz: Sie können zwei baugleiche mGuard s zu einem Redundanz­paar zusammenzufassen, bei dem im Fehlerfall der eine die Funktion des anderen übernimmt.

–VPN-Redundanz: Basis hierfür ist eine bestehende Firewall-Redundanz. Zusätzlich dazu werden die VPN-Verbindungen so ausgelegt, das mindestens ein mGuard  eines Redunanzpaares die VPN-Verbindungen betreibt.

–Ring-/Netzkopplung: Bei der Ring-/Netzkopplung wird ein anderer Ansatz gewählt. Hier werden Teile eines Netzes redundant ausgelegt. Im Fehlerfall wird dann der alter­native Weg gewählt.

17.1Firewall-Redundanz

Mit Hilfe der Firewall-Redundanz ist es möglich, zwei baugleiche mGuard s zu einem Re­dundanzpaar (einem virtuellen Router) zusammenzufassen. Dabei übernimmt ein mGuard  in einem Fehlerfall die Funktion des anderen. Beide mGuard s laufen synchron, so dass bei einem Wechsel die bestehende Verbindung nicht unterbrochen wird.

Bild 17-1: Firewall-Redundanz (Beispiel)

Grundbedingungen für die Firewall-Redundanz

–Nur baugleiche mGuard s können ein Redundanzpaar bilden.

–Im Netzwerk-Modus Router wird die Firewall-Redundanz nur mit dem Router-Modus „Statisch“ unterstützt.

–Ab mGuard -Firmwareversion 7.5 wird die Firewall-Redundanz ebenfalls im Stealth-Modus, allerdings nur in der Stealth-Konfiguration „Mehrere Clients“, unterstützt.

–Weitere Einschränkungen siehe „Voraussetzungen für die Firewall-Redundanz“ auf Seite 442 und „Grenzen der Firewall-Redundanz“ auf Seite 452.

17.1.1Komponenten der Firewall-Redundanz

Die Firewall-Redundanz besteht aus mehreren Komponenten:

–Konnektivitätsprüfung

Prüft, ob die erforderlichen Netzwerkverbindungen bestehen.

–Verfügbarkeitsprüfung

Prüft, ob ein aktiver mGuard  vorhanden ist und ob dieser aktiv bleiben soll.

–Zustandsabgleich der Firewall

Der mGuard  in Bereitschaft erhält eine Kopie des aktuellen Zustands der Firewall-Datenbank.

–Virtuelles Netzwerk-Interface

Stellt virtuelle IP-Adressen und MAC-Adressen bereit, die von anderen Geräten als Routen und Standard-Gateways genutzt werden können.

–Statusüberwachung

Koordiniert alle Komponenten.

–Statusanzeige

Zeigt dem Benutzer den Zustand des mGuard s an.

Konnektivitätsprüfung

Bei jedem mGuard  eines Redundanzpaares wird kontinuierlich geprüft, ob eine Verbindung besteht, über die Netzwerkpakete weitergleitet werden können.

Jeder mGuard  prüft seine interne und externe Netzwerk-Schnittstelle unabhängig vonein­ander. Beide Schnittstellen werden auf eine durchgehende Verbindung getestet. Diese Verbindung muss bestehen, sonst wird die Konnektivitätsprüfung nicht bestanden.

Optional können ICMP-Echo-Requests gesendet werden. Sie können die ICMP-Echo-Re­quests über das Menü   Redundanz >> Firewall-Redundanz >> Konnektivitätsprüfung   ein­stellen.

Verfügbarkeitsprüfung

Bei jedem mGuard  eines Redundanzpaares wird außerdem kontinuierlich geprüft, ob ein aktiver mGuard  vorhanden ist und ob dieser aktiv bleiben soll. Dafür wird eine Variante des CARP (Common Address Redundancy Protocol) verwendet.

Der aktive mGuard  sendet ständig Anwesenheitsnachrichten über sein internes und exter­nes Netzwerk-Interface, während beide mGuard s zuhören. Wenn ein dedizierter Ethernet-Link für den Zustandsabgleich der Firewall vorhanden ist, wird die Anwesenheitsnachricht auch über diesen gesendet. In diesem Fall kann die Anwesenheitsnachricht für die externe Netzwerk-Schnittstelle auch unterdrückt werden.

Die Verfügbarkeitsprüfung wird nicht bestanden, wenn ein mGuard  in einer bestimmten Zeit keine Anwesenheitsnachricht erhält. Außerdem wird die Prüfung nicht bestanden, wenn ein mGuard  Anwesenheitsnachrichten von niedrigerer Priorität erhält als die eigene.

Die Daten werden immer über das physikalische Netzwerk-Interface übertragen und nie­mals über das virtuelle Netzwerk-Interface.

Zustandsabgleich

Der mGuard , der sich im Zustand der Bereitschaft befindet, erhält eine Kopie des Zustan­des des aktuell aktiven mGuard s.

Dazu gehört eine Datenbank mit den weitergeleiteten Netzwerkverbindungen. Diese Da­tenbank wird laufend durch die weitergeleiteten Netzwerkpakete aufgebaut und erneuert. Sie ist gegen einen unberechtigen Zugriff geschützt. Die Daten werden über die physikali­sche LAN-Schnittstelle übertragen und niemals über das virtuelle Netzwerk-Interface ge­sendet.

Um den internen Datenverkehr gering zu halten, kann ein VLAN so konfiguiert werden, dass es die Abgleichsdaten in eine separate Multicast- und Broadcast-Domain verlagert.

Virtuelle IP-Adressen

Jeder mGuard  wird mit virtuellen IP-Adressen konfiguriert. Deren Anzahl hängt von dem verwendeten Netzwerk-Modus ab. Bei einem Redundanzpaar müssen Sie beiden mGuard s die gleichen virtuellen IP-Adressen zuweisen. Die virtuellen IP-Adressen werden vom mGuard  benötigt, um virtuelle Netzwerk-Interfaces aufzubauen.

Für den Netzwerk-Modus Router sind zwei virtuelle IP-Adressen notwendig, weitere kön­nen angelegt werden. Eine virtuelle IP-Adresse wird für das externe Netzwerk-Interface und die andere für das interne Netzwerk-Interface benötigt.

Diese IP-Adressen werden als Gateway für das Routen von Geräten benutzt, die sich im ex­ternen oder internen LAN befinden. Auf diese Weise können die Geräte von der hohen Ver­fügbarkeit profitieren, die durch die beiden redundanten mGuard s entsteht.

Das Redundanzpaar bestimmt automatisch MAC-Adressen für das virtuelle Netzwerk-Interface. Diese MAC-Adressen sind identisch für das Redundanzpaar. Im Netzwerk-Modus Router teilen sich beide mGuard s je eine MAC-Adresse für das virtuelle Netzwerk-Interface, das mit dem externen und dem internen Ethernet-Segment verbunden ist.

Im Netzwerk-Modus Router unterstützen die mGuard s eine Weiterleitung von speziellen UDP/TCP-Ports von einer virtuellen IP-Adresse zu anderen IP-Adressen, sofern letztere vom mGuard  erreicht werden können. Zusätzlich maskiert der mGuard  Daten mit virtuellen IP-Adressen, wenn Masquerading-Regeln eingerichtet sind.

Statusüberwachung

Die Statusüberwachung entscheidet darüber, ob der mGuard  im Zustand aktiv, in Bereit­schaft oder im Fehlerzustand ist. Jeder mGuard  entscheidet autonom über seinen Zustand, basierend auf den Informationen, die von anderen Komponenten bereitgestellt werden. Die Statusüberwachung sorgt dafür, dass nicht zwei mGuard s gleichzeitig aktiv sind.

Statusanzeige

Die Statusanzeige enthält detaillierte Informationen über den Status der Firewall-Redun­danz. Eine Zusammenfassung des Status kann über das Menü   Redundanz >> Firewall-Re­dundanz >> Redundanz   oder   Redundanz >> Firewall-Redundanz >> Konnektivitätsprü­fung   abgerufen werden.

17.1.2Zusammenarbeit der Firewall-Redundanz-Komponenten

Während des Betriebes interagieren die Komponenten folgendermaßen: Beide mGuard s führen fortlaufend für ihre beiden Netzwerk-Schnittstellen (internes und externes Interface) eine Konnektivitätsprüfung durch. Außerdem wird fortlaufend eine Verfügbarkeitsprüfung gemacht. Dazu lauscht jeder mGuard  kontinuierlich auf Anwesenheitsnachrichten (CARP) und der aktive mGuard  sendet diese zusätzlich.

Auf Grundlage der Informationen aus der Konnektivitäts- und - Verfügbarkeitsprüfung weiß die Statusüberwachung, in welchem Zustand sich die mGuard s befinden. Die Statusüber­wachung sorgt dafür, dass der aktive mGuard  seine Daten auf den anderen mGuard  spie­gelt (Zustandsabgleich).

17.1.3Firewall-Redundanz-Einstellungen aus vorherigen Versio­nen

Vorhandene Konfigurationsprofile der Firmware-Version 6.1.x (und davor) können mit be­stimmten Einschränkungen importiert werden. Bitte nehmen Sie hierzu Kontakt zu Phoenix Contact  auf.

17.1.4Voraussetzungen für die Firewall-Redundanz

–Um die Redundanz-Funktion zu nutzen, müssen beide mGuard s die gleiche Firmware haben.

–Die Firewall-Redundanz kann nur aktiviert werden, wenn ein gültiger Lizenzschlüssel installiert ist.

(unter:   Redundanz >> Firewall-Redundanz >> Redundanz   >>  Aktiviere Redundanz )

–  Redundanz >> Firewall-Redundanz >> Redundanz  >>  Interface, das zum Zustandsab­gleich verwendet wird  

Der Wert Dediziertes Interface wird nur auf mGuard s akzeptiert, die mehr als zwei physikalische und getrennte Ethernet-Interfaces haben. Zur Zeit ist das der mGuard centerport (Innominate)  / FL MGUARD CENTERPORT  .

–Jeder Satz von Zielen für die Konnektivitätsprüfung kann mehr als zehn Ziele beinhal­ten. (Ohne eine Obergrenze kann eine Failover-Zeit nicht garantiert werden.)

  Redundanz >> Firewall-Redundanz >> Redundanz  

–>>  Externes Interface  >>  Primäre externe Ziele (für ICMP Echo-Anfragen)  

–>>  Externes Interface  >>  Sekundäre externe Ziele (für ICMP Echo-Anfragen)  

–>>  Internes Interface  >>  Primäre externe Ziele (für ICMP Echo-Anfragen)  

–>>  Internes Interface  >>  Sekundäre externe Ziele (für ICMP Echo-Anfragen)  

Wenn unter   Externes Interface  >>  Art der Prüfung   „mindestens ein Ziel muss ant­worten“ oder „alle Ziele einer Menge müssen antworten“ ausgewählt ist, darf   Exter­nes Interface  >>  Primäre externe Ziele (für ICMP Echo-Anfragen)  nicht leer sein. Das Gleiche gilt für das Interne Interface.

–Im Netzwerk-Modus Router müssen mindestens eine externe und eine interne virtu­elle IP-Adresse eingestellt werden. Keine virtuelle IP-Adresse darf doppelt aufgelistet werden.

17.1.5Umschaltzeit im Fehlerfall

Von der Variablen Umschaltzeit im Fehlerfall errechnet der mGuard  automatisch die Zeit­abstände für die Konnektivitäts- und Verfügbarkeitsprüfung.

Konnektivitätsprüfung

In der Tabelle 17-1 auf Seite 443 werden die Faktoren angegeben, die die Zeitabstände für die Konnektivitätsprüfung bestimmen.

Für die Konnektivitätsprüfung werden ICMP-Echo-Requests verschickt, die 64 kByte groß sind. Sie werden auf Layer 3 des Internet-Protokolls gesendet. Mit dem Ethernet auf Layer 2 kommen 18 Bytes für den MAC-Header und die Prüfsumme dazu, wenn kein VLAN verwen­det wird. Der ICMP-Echo-Reply hat die gleiche Größe.

In Tabelle 17-1 wird außerdem die Bandbreite gezeigt. Sie berücksichtigt die genannten Werte für ein einzelnes Ziel und summiert die Bytes für ICMP-Echo-Request und Reply.

Der Timeout am mGuard  nach dem Senden enthält Folgendes:

–Die Zeit, die der mGuard  braucht, um den ICMP-Echo-Reply zu übertragen. Der Halb-Duplex-Modus ist hierfür nicht geeignet, wenn anderer Datenverkehr dazu kommt.

–Die Zeit, die für die Übertragung des ICMP-Echo-Requests zu einem Ziel erforderlich ist. Beachten Sie dabei die Latenzzeit bei einer hohen Auslastung. Die gilt besonders, wenn Router die Anfrage weiterleiten. Die tatsächliche Latenzzeit kann unter ungünsti­gen Umständen (Fehler der Konnektivitätsprüfung) den doppelten Wert der konfigu­rierten Latenzzeit annehmen.

–Die Zeit, die pro Ziel benötigt wird, um den Request zu bearbeiten und das Reply zum Ethernet-Layer zu übertragen. Beachten Sie, dass hier ebenfalls der Voll-Duplex-Mo­dus gebraucht wird.

–Die Zeit für die Übertragung des ICMP-Echo-Replies zum mGuard .

Wenn sekundäre Ziele konfiguriert sind, kann es gelegentlich passieren, dass zusätzliche ICMP-Echo-Requests zu diesen Zielen gesendet werden. Dies muss bei der Berechnung für die ICMP-Echo-Request-Rate berücksichtigt werden.

In der Tabelle 17-1 wird der Timeout für einen einzelnen ICMP-Echo-Request gezeigt. Das sagt noch nichts darüber aus, wie viele der Responses vermisst werden dürfen, bevor die Konnektivitätsprüfung ausfällt. Diese Prüfung toleriert, wenn von zwei aufeinander folgen­den Intervallen eines negativ ist.

Verfügbarkeitsprüfung

Die Größe der Anwesenheitsnachrichten (CARP) beträgt bis zu 76 Bytes am Layer 3 des Internet-Protokolls. Mit dem Ethernet auf Layer 2 kommen 18 Bytes für den MAC-Header und die Prüfsumme dazu, wenn kein VLAN verwendet wird. Der ICMP-Echo-Reply hat die gleiche Größe.

Die Tabelle 17-2 zeigt die maximale Frequenz, mit der Anwesenheitsnachrichten (CARP) vom aktiven mGuard  gesendet werden. Sie zeigt außerdem die Bandbreite, die dabei ver­braucht wird. Die Frequenz hängt von der Priorität des mGuard s und der   Umschaltzeit im Fehlerfall   ab.

Die Tabelle 17-2 zeigt außerdem die maximale Latenzzeit, die der mGuard  für das Netz­werk toleriert, das die Anwesenheitsnachrichten (CARP) überträgt. Wenn diese Latenzzeit überschritten wird, kann das Redundanzpaar ein undefiniertes Verhalten zeigen.

17.1.6Fehlerkompensation durch die Firewall-Redundanz

Die Firewall-Redundanz dient dazu, den Ausfall von Hardware auszugleichen.

Bild 17-2: Mögliche Fehlerorte (1 ... 8)

In Bild 17-2 wird ein Aufbau gezeigt, der verschiedene Fehlerorte zeigt (unabhängig vom Netzwerk-Modus).

Jeder der beiden mGuard s eines Redundanzpaares sitzt in einem unterschiedlichen Be­reich (A und B). Der mGuard  in Bereich A ist mit seinem externen Ethernet-Interface an Switch A1 und mit seinem internen Ethernet-Interface an Switch A2 angeschlossen. Der mGuard  B ist entsprechend mit den Switchen B1 und B2 gekoppelt. Auf diese Weise ver­binden die Switche und die mGuard s ein externes mit einem internen Ethernet-Netzwerk. Sie stellen die Verbindung her, indem sie Netzwerk-Pakete (im Netzwerk-Modus Router) weiterleiten.

Die Firewall-Redundanz kompensiert die Fehler, die in Bild 17-2 gezeigt werden, wenn nur einer davon zur gleichen Zeit auftritt. Wenn zwei der Fehler gleichzeitig auftreten, werden sie nur kompensiert, wenn sie im selben Bereich (A oder B) auftreten.

Wenn zum Beispiel einer der mGuard s aufgrund eines Stromausfalls komplett ausfällt, dann wird das aufgefangen. Ein Ausfall einer Verbindung wird wett gemacht, wenn diese komplett oder nur teilweise ausfällt. Bei einer korrekt eingestellten Konnektivitätsprüfung wird auch eine fehlerhafte Verbindung entdeckt und kompensiert, die durch den Verlust von Datenpaketen oder einer zu hohen Latenzzeit entsteht. Ohne die Konnektivitätsprüfung kann der mGuard  nicht entscheiden, welcher Bereich die Fehler verursacht hat.

Ein Ausfall der Verbindung zwischen den Switchen einer Netzwerk-Seite (intern/extern) wird nicht ausgeglichen (7 und 8 in Bild 17-2).

17.1.7Umgang der Firewall-Redundanz mit extremen Situationen

Wiederherstellung bei einer Netzwerk-Lobotomie

Eine Netzwerk-Lobotomie bezeichnet den Zustand, dass ein Redundanzpaar in zwei unab­hängig von einander agierende mGuard s aufgesplittet wird. Jeder mGuard  kümmert sich in diesem Fall um seine eigenen Tracking-Informationen, da die beiden mGuard s nicht mehr über den Layer 2 kommunizieren können. Eine Netzwerk-Lobotomie kann durch eine un­glückliche, seltene Kombinationen von Netzwerk-Einstellungen, Netzwerk-Ausfällen und Einstellungen in der Firewall-Redundanz ausgelöst werden.

Bei einer Netzwerk-Lobotomie wird jeder mGuard  aktiv. Nachdem die Netzwerk-Lobotomie wieder behoben worden ist, passiert Folgendes: Wenn die mGuard s unterschiedliche Prio­ritäten haben, wird der mit der höheren aktiv und der andere geht in den Bereitschaftszu­stand. Wenn beide mGuard s die gleiche Priorität haben, entscheidet ein Identifier, der mit den Anwesenheitsnachrichten (CARP) mitgeschickt wird, darüber, welcher mGuard  aktiv wird.

Während die Netzwerk-Lobotomie besteht, haben beide mGuard s ihren Firewall-Zustand selbst verwaltet. Der mGuard , der aktiv wird, behält seinen Zustand. Die Verbindungen des anderen mGuard s, die während der Lobotomie bestanden haben, werden fallengelassen.

Failover beim Aufbau von komplexen Verbindungen

Komplexe Verbindungen sind Netzwerk-Protokolle, die auf verschiedenen IP-Verbindun­gen basieren. Ein Beispiel dafür ist das FTP-Protokoll. Beim FPT-Protokoll baut der Client bei einer TCP-Verbindung einen Kontroll-Kanal auf. Er erwartet, dass der Server eine an­dere TCP-Verbindung öffnet, über die der Client dann Daten übertragen kann. Während der Kontroll-Kanal am Port 21 des Servers aufgebaut wird, wird der Datenkanal am Port 20 des Servers eingerichtet.

Wenn beim mGuard  die entsprechende Verfolgung der Verbindung (Connection Tracking) aktiviert ist (siehe „Erweitert“ auf Seite 293), dann werden solche komplexen Verbindung verfolgt. In diesem Fall braucht der Administrator nur eine Firewall-Regel am mGuard  zu er­stellen, die es dem Clienten erlaubt, einen Kontroll-Kanal zum FTP-Server aufzubauen. Der mGuard  wird automatisch den Aufbau eines Datenkanals durch den Server erlauben, un­abhängig davon, ob die Firewall-Regeln das vorsehen.

Das Verfolgen von komplexen Verbindungen ist Bestandteil des Firewall-Zustandsabglei­ches. Aber um eine kurze Latenzzeit zu erreichen, leitet der mGuard  Netzwerk-Pakete un­abhängig vom Update des Firewall-Zustandsabgleichs weiter, das sie selbst verursacht ha­ben.

So kann es für eine ganz kurze Zeit so sein, dass eine Statusänderung für die komplexe Verbindung nicht an den mGuard  in Bereitschaft weitergeleitet worden ist, wenn der aktive mGuard  ausfällt. In diesem Fall wird die Verfolgung der Verbindung vom mGuard , der nach dem Failover aktiv ist, nicht korrekt fortgeführt. Das kann durch den mGuard  nicht korrigiert werden. Dann wird die Datenverbindung zurückgesetzt oder unterbrochen.

Failover beim Aufbau von semi-unidirektionalen Verbindungen

Eine semi-unidirektionale Verbindung bezieht sich auf eine einzelne IP-Verbindung (wie UDP-Verbindungen), bei denen die Daten nur in eine Richtung fließen, nachdem die Ver­bindung mit einem bidirektionalen Handshake zustande gekommen ist.

Die Daten fließen vom Responder zum Initiator. Der Initiator sendet nur ganz am Anfang Da­tenpakete.

Das folgende gilt nur für ganz bestimmt Protokolle, die auf UDP basieren. Bei TCP-Verbin­dungen fließen die Daten immer in beide Richtungen.

Wenn die Firewall des mGuard s so gestaltet ist, dass sie nur Datenpakete akzeptiert, die vom Initiator kommen, wird die Firewall alle Antworten darauf per se zulassen. Das ist un­abhängig davon, ob dafür eine Firewall-Regel vorhanden ist.

Es ist ein Fall denkbar, dass der mGuard  das initierende Datenpaket hat passieren lassen und ausfällt, bevor es den entsprechenden Verbindungs-Eintrag im anderen mGuard  gibt. Dann kann es sein, dass der andere mGuard  die Antworten zurückweist, sobald er der ak­tive mGuard  geworden ist.

Durch die einseitige Verbindung kann der mGuard  diese Situation nicht korrigieren. Als Ge­genmaßnahme kann die Firewall so konfiguriert werden, dass sie den Verbindungsaufbau in beide Richtungen zulässt. Normalerweise wird dies bereits über die Protokoll-Layer ge­regelt und muss nicht extra zugewiesen werden.

Datenpaket-Verlust beim Zustandsabgleich

Wenn beim Zustandsabgleich Datenpakete verloren gehen, dann entdeckt der mGuard  dies automatisch und bittet den aktiven mGuard , die Daten erneut zu senden.

Diese Anfrage muss in einer bestimmten Zeit beantwortet werden, sonst erhält der mGuard  in Bereitschaft den Status „outdated“ und fragt den aktiven mGuard  nach einer kompletten Kopie aller Zustandsinformationen.

Die Antwortzeit wird automatisch aus der Failover-Umschaltzeit berechnet. Sie ist länger als die Zeit für die Anwesenheitsnachrichten (CARP), aber kürzer als die obere Grenze der Failover-Umschaltzeit.

Verlust von Anwesenheitsnachrichten (CARP) bei der Übertragung

Ein einzelner Verlust von Anwesenheitsnachrichten (CARP) wird vom mGuard  toleriert, aber nicht für die nachfolgenden Anwesenheitsnachrichten (CARP). Dies gilt für die Verfüg­barkeitsprüfung jedes einzelnen Netzwerk-Interfaces, selbst wenn diese gleichzeitig ge­prüft werden. Daher ist es sehr unwahrscheinlich, dass eine sehr kurze Netzwerk-Unterbre­chung die Verfügbarkeitsprüfung scheitern lässt.

Verlust von ICMP-Echo-Requests/Replies bei der Übertragung

ICMP-Echo-Requests oder -Replies sind wichtig für die Konnektivitätsprüfung. Ein Verlust wird grundsätzlich beachtet, aber unter bestimmten Bedingungen wird er toleriert.

Folgende Maßnahmen tragen dazu bei, die Toleranz bei ICMP-Echo-Requests zu erhöhen.

–Wählen Sie im Menü   Redundanz >> Firewall-Redundanz >> Konnektivitätsprüfung  un­ter dem Punkt Art der Prüfung die Auswahl Mindestens ein Ziel muss antworten aus.

–Definieren Sie zusätzlich dort eine sekundäre Menge von Zielen. Sie können die Tole­ranz für den Verlust von ICMP-Echo-Requests noch erhöhen, wenn die Ziele von un­zuverlässigen Verbindungen unter beiden Mengen (primär und sekundär) eingetragen werden oder innerhalb einer Menge mehrfach aufgelistet werden.

Wiederherstellen des primären mGuard  s nach einem Ausfall

Wenn ein Redundanzpaar mit unterschiedlichen Prioritäten definiert ist, wird der sekundäre mGuard  bei einem Verbindungsausfall aktiv. Nachdem der Ausfall behoben ist, wird der pri­märe mGuard  wieder aktiv. Der sekundäre mGuard  erhält eine Anwesenheitsnachricht (CARP) und geht wieder in den Bereitschaftszustand.

Zustandsabgleich

Wenn der primäre mGuard  nach einem Ausfall der internen Netzwerkverbindung wieder aktiv werden soll, hat er möglicherweise eine veraltete Kopie des Datenbestandes der Fi­rewall. Bevor die Verbindung also wieder hergestellt wird, muss dieser Datenbestand aktu­alisiert werden. Der primäre mGuard  sorgt dafür, dass er zunächst eine aktuelle Kopie er­hält, bevor er aktiv wird

17.1.8Zusammenwirken mit anderen Geräten

Virtuelle und reale IP-Adressen

Bei der Firewall-Redundanz im Netzwerk-Modus Router nutzt der mGuard  reale IP-Adres­sen, um mit anderen Netzwerk-Geräten zu kommunizieren.

Virtuelle IP-Adressen werden in diesen beiden Fällen eingesetzt:

–Beim Aufbauen und Betreiben von VPN-Verbindungen werden virtuelle IP-Adressen in Anspruch genommen.

–Wenn die Dienste DNS und NTP entsprechend der Konfiguration genutzt werden, dann werden diese an internen virtuellen IP-Adressen angeboten.

Das Nutzen der realen (Management) IP-Adressen ist besonders wichtig für die Konnekti­vitäts- und Verfügbarkeitsprüfung. Daher muss die reale (Management) IP-Adresse so kon­figuriert werden, dass der mGuard  die erforderlichen Verbindungen herstellen kann.

Ein mGuard  kommuniziert z. B.

–mit NTP-Servern, um seine Uhrzeit zu synchronisieren

–mit DNS-Servern, um Hostnamen aufzulösen (besonders von VPN-Partnern)

–wenn er seine IP-Adresse bei einem DynDNS-Dienst registrieren will

–wenn er SNMP-Traps sendet will

–wenn er Log-Nachrichten an einen Remote-Server weiterleiten will

–um eine CRL von einem HTTP(S)-Server herunterzuladen

–um einen Benutzer über einen RADIUS-Server zu authentifizieren

–um über einen HTTPS-Server ein Konfigurationsprofil herunterzuladen.

–um von einem HTTPS-Server ein Firmware-Update herunterzuladen.

Bei der Firewall-Redundanz im Netzwerk-Modus Router müssen Geräte, die am selben LAN-Segment wie das Redundanzpaar angeschlossen sind, ihre jeweiligen virtuellen IP-Ad­ressen als Gateway für ihre Routen nutzen. Wenn diese Geräte dafür die reale IP-Adresse eines der beiden mGuard s nutzen würden, würde es funktionieren, bis dieser mGuard  aus­fällt. Dann aber kann der andere mGuard  nicht übernehmen.

Ziele für die Konnektivitätsprüfung

Falls bei der Konnektivitätsprüfung ein Ziel für ICMP-Echo-Requests eingestellt ist, dann müssen diese Anfragen in einer bestimmten Zeit beantwortet werden, auch wenn das Netz­werk noch mit anderen Daten belastet ist. Der Netzwerkpfad zwischen dem Redundanz­paar und diesen Zielen muss so gestaltet sein, dass er in der Lage ist, die ICMP-Antworten auch in Zeiten hoher Last weiterzuleiten. Andernfalls könnte bei einem mGuard  fälschli­cherweise die Konnektivitätsprüfung scheitern.

Bei der Konnektivitätsprüfung können Ziele für das interne und externe Interface konfigu­riert werden (siehe „Konnektivitätsprüfung“ auf Seite 425). Es ist wichtig, dass diese Ziele tatsächlich an dem angegebenen Interface angeschlossen sind. Ein ICMP-Echo-Reply kann nicht von einem externen Interface empfangen werden, wenn das Ziel am internen In­terface angeschlossen ist (und umgekehrt). Bei einem Wechsel der statischen Routen kann es leicht passieren, dass vergessen wird, die Konfiguration der Ziele entsprechend anzu­passen.

Die Ziele für die Konnektivitätsprüfung sollten gut durchdacht sein. Ohne eine Konnektivi­tätsprüfung können schon zwei Fehler zu einer Netzwerk-Lobotomie führen.

Eine Netzwerk-Lobotomie wird verhindert, wenn die Ziele für beide mGuard s identisch sind und alle Ziele auf die Anfrage antworten müssen. Allerdings hat dies den Nachteil, dass die Konnektivitätsprüfung häufiger fehlschlägt, wenn eines der Ziele nicht hoch verfügbar ist.

Im Netzwerk-Modus Router empfehlen wir ein hoch verfügbares Gerät als Ziel am exter­nen Interface zu definieren. Das kann das Standard-Gateway für das Redundanzpaar sein, z. B. ein virtueller Router, der aus zwei unabhängigen Geräten besteht. Am internen Inter­face sollte dann entweder kein Ziel definiert sein oder eine Auswahl von Zielen.

Bei der Konstellation, dass Sie bei einem Redundanzpaar als Standard-Gateway einen vir­tuellen Router einsetzen, der aus zwei unabhängigen Geräten besteht, gibt es noch etwas zu beachten. Wenn diese Geräte VRRP nutzen, um ihre virtuelle IP zu synchronisieren, dann könnte eine Netzwerk-Lobotomie die virtuelle IP dieses Routers in zwei identische Ko­pien aufsplitten. Möglicherweise nutzen diese Router ein dynamisches Routing Protokoll und nur einer darf für die Datenströme des Netzwerkes ausgewählt werden, das durch die mGuard s überwacht wird. Nur dieser Router sollte die virtuelle IP behalten. Andernfalls kön­nen Sie in der Konnektivitätsprüfung Ziele definieren, die über diese Route erreichbar sind. Die virtuelle IP-Adresse des Routers wäre dann kein sinnvolles Ziel.

Redundanzverbund

Sie können innerhalb eines LAN-Segmentes mehrere Redundanzpaare anschließen (Re­dundanzverbund). Für jede virtuelle Existenz des Redundanzpaares legen Sie einen Wert als Identifier fest (über die Router-ID). Solange diese Identifier unterschiedlich sind, stören sich die Redundanzpaare nicht untereinander.

Datenverkehr

Eine hohe Latenzzeit im Netzwerk, das für Updates des Zustandsabgleichs genutzt wird oder ein ernster Datenverlust in diesem Netzwerk führen dazu, dass der mGuard  in Bereit­schaft in den „outdated“ Zustand geht. Solange nicht mehr als zwei aufeinander folgende Updates verloren gehen, kommt es aber nicht dazu. Denn der mGuard  in Bereitschaft for­dert automatisch eine Wiederholung des Updates ein. Die Anforderungen an die Latenzzeit sind dieselben, wie unter „Umschaltzeit im Fehlerfall“ auf Seite 443 beschrieben.

Ausreichende Bandbreite

Der Datenverkehr, der durch die Konnektivitäts- und Verfügbarkeitsprüfung und den Zu­standsabgleich entsteht, verbraucht Bandbreite im Netzwerk. Außerdem erzeugt die Kon­nektivitätsprüfung einen rechnerischen Aufwand. Es gibt mehrere Methoden, dies zu ver­ringern oder ganz aufzuheben.

Wenn ein Einfluss auf andere Geräte nicht akzeptabel ist,

–dann muss die Konnektivitätsprüfung entweder deaktiviert werden oder sie darf sich nur auf die reale IP-Adresse des anderen mGuard s beziehen.

–dann muss der Datenverkehr durch die Verfügbarkeitsprüfung und den Zustandsab­gleich in ein separates VLAN verschoben werden.

–dann müssen Switche genutzt werden, die es erlauben, VLANs zu splitten.

Dediziertes Interface

Der mGuard centerport (Innominate)  / FL MGUARD CENTERPORT  unterstützt ein dedi­ziertes Interface. Das ist eine reservierte direkte Ethernet-Schnittstelle oder ein dedizier­tes LAN-Segment, über das der Zustandsabgleich gesendet wird. Auf diese Weise ist die Last sogar physikalisch vom internen LAN-Segment getrennt.

17.1.9Übertragungsleistung der Firewall-Redundanz

Die Werte gelten für den Netzwerk-Modus Router, wenn der Datenverkehr für den Zu­standsabgleich unverschlüsselt übertragen wird. Wenn die hier beschriebene Übertra­gungsleistung überschritten wird, kann im Fehlerfall eine längere Umschaltzeiten entste­hen, als eingestellt ist.

Failover-Umschaltzeit

Sie können die Umschaltzeit im Fehlerfall auf 1, 3 oder 10 Sekunden einstellen.

Die Obergrenze von 1 Sekunde wird derzeit nur vom mGuard centerport (Innominate) , FL MGUARD CENTERPORT  auch unter hoher Auslastung eingehalten.

17.1.10Grenzen der Firewall-Redundanz

–Im Netzwerk-Modus Router wird die Firewall-Redundanz nur mit dem Modus „statisch“ unterstützt.

–Ein Zugang zum mGuard  über die Management-Protokolle HTTPS, SNMP und SSH ist nur mit einer realen IP-Adresse eines jeden mGuard s möglich. Zugriffe auf virtuelle Adressen werden zurückgewiesen.

–Die folgenden Features können mit der Firewall-Redundanz nicht benutzt werden.

–ein sekundäres externes Ethernet-Interface,

–ein DHCP-Server,

–ein DHCP-Relay,

–ein SEC-Stick-Server,

–eine Benutzer-Firewall und

–das CIFS-Integrity-Monitoring.

–Das Redundanzpaar muss identisch konfiguriert werden. Beachten Sie dies bei der Einstellung von:

–NAT-Einstellungen (Masquerading, Port-Weiterleitung und 1:1-NAT)

–Flood-Protection

–Paketfilter (Firewall-Regeln, MAC-Filter, Erweiterte Einstellungen)

–den Queues und den Regeln für die QoS

–Nach einer Netzwerk-Lobotomie sind möglicherweise einige Netzwerkverbindungen unterbrochen. (Siehe „Wiederherstellung bei einer Netzwerk-Lobotomie“ auf Seite 446).

–Nach einem Failover können semi-unidirektionale oder komplexe Verbindungen unterbrochen sein, die genau in der Sekunde vor dem Failover aufgebaut worden sind. (Siehe „Failover beim Aufbau von komplexen Verbindungen“ auf Seite 446 und „Fai­lover beim Aufbau von semi-unidirektionalen Verbindungen“ auf Seite 446.)

–Die Firewall-Redundanz unterstützt nicht den FL MGUARD PCI 533/266  im Treiber-Modus.

–Der Zustandsabgleich repliziert keine Connection-Tracking-Einträge für ICMP-Echo-Requests, die vom mGuard  weitergeleitet werden. Deshalb können ICMP-Echo-Replies entsprechend der Firewall-Regeln fallen gelassen werden, wenn sie den mGuard  erst erreichen, wenn der Failover abgeschlossen ist. Beachten Sie, dass ICMP-Echo-Replies nicht dazu geeignet sind, die Failover-Umschaltzeit zu messen.

–Masquerading wird dadurch ausgeführt, dass der Sender hinter der ersten virtuellen IP-Adresse bzw. der ersten internen IP-Adresse verborgen wird. Das unterscheidet sich von dem Masquerading des mGuard s ohne Firewall-Redundanz. Ohne aktivierte Firewall-Redundanz wird in einer Routing-Tabelle festgelegt, hinter welcher externen bzw. internen IP-Adresse der Sender verborgen wird.

17.2VPN-Redundanz

Die VPN-Redundanz kann nur zusammen mit der Firewall-Redundanz genutzt werden.

Das Konzept ist genauso wie bei der Firewall-Redundanz. Um einen Fehler im Umfeld auf­zufangen, wird die Aktivität von dem aktiven mGuard  auf einen mGuard  in Bereitschaft übertragen.

Zu jedem Zeitpunkt betreibt mindestens ein mGuard  des Redundanzpaares die VPN-Ver­bindung, außer wenn eine Netzwerk-Lobotomie vorliegt.

Grundbedingungen für die VPN-Redundanz

Für die VPN-Redundanz gibt es keine eigenen Variablen. Es gibt gegenwärtig kein eigenes Menü in der Benutzeroberfläche, sondern sie wird mit der Firewall-Redundanz zusammen aktiviert.

Voraussetzung für die VPN-Redundanz ist eine entsprechende Lizenz, die Sie auf dem mGuard  installieren müssen.

Da für die VPN-Redundanz der Aufbau von VPN-Verbindungen notwendig ist, brauchen Sie zusätzlich eine entsprechende VPN-Lizenz.

Wenn Sie nur die Lizenz für die Firewall-Redundanz haben und VPN-Verbindungen instal­liert sind, können Sie keine VPN-Redundanz aktivieren. Sie erhalten eine Fehlermeldung, sobald Sie die Firewall-Redundanz nutzen wollen.

Nur baugleiche mGuard s können ein Redundanzpaar bilden.

17.2.1Komponenten der VPN-Redundanz

Die Komponenten der VPN-Redundanz sind die gleichen, die bei der Firewall-Redundanz beschrieben worden sind. Zusätzlich gibt es noch eine weitere Komponente: der VPN-Zu­standsabgleich. Einige wenige Komponenten sind für die VPN-Redundanz leicht erweitert. Aber die Konnektivitäts- und Verfügbarkeitsprüfung und der Zustandsabgleich von der Fi­rewall funktionieren auf die gleiche Weise.

VPN-Zustandsabgleich

Der mGuard  unterstützt die Konfiguration von Firewall-Regeln für die VPN-Verbindung.

Der VPN-Zustandsabgleich verfolgt den Zustand der verschiedenen VPN-Verbindungen am aktiven mGuard . Er sorgt dafür, dass der mGuard  in Bereitschaft eine zur Zeit gültige Kopie der VPN-Zustand-Datenbank erhält.

Wie bei dem Zustandsabgleich der Firewall sendet er Updates vom aktiven mGuard  zum mGuard  in Bereitschaft. Auf Anfrage vom mGuard  in Bereitschaft versendet der aktive mGuard  einen kompletten Satz aller Zustandsinformationen.

Dediziertes Interface (mGuard centerport (Innominate) , FL MGUARD CENTERPORT )

Beim mGuard centerport (Innominate) , FL MGUARD CENTERPORT   können Sie das dritte Ethernet-Interface für den VPN-Zustandsabgleich fest zuordnen.

Wie bei dem Zustandsabgleich der Firewall wird der Datenverkehr für den VPN-Zu­standsabgleich für das dedizierte Interface übertragen, wenn eine Variable gesetzt wird. Stellen Sie unter   Redundanz >> Firewall-Redundanz >> Redundanz  das  Interface, das zum Zustandsabgleich verwendet wird   auf Dediziertes Interface.

Aufbau von VPN-Verbindungen

Mit der VPN-Redundanz wird das virtuelle Netzwerk-Interface für einen zusätzlichen Zweck genutzt: Es wird verwendet, um VPN-Verbindungen aufzubauen, zu akzeptieren und zu be­treiben. Der mGuard  lauscht nur auf der ersten virtuellen IP-Adresse.

Im Netzwerk-Modus Router hört er an der ersten externen und internen virtuellen IP-Ad­resse zu.

Statusüberwachung

Die Statusüberwachung überwacht den VPN-Zustandsabgleich genauso wie den der Fi­rewall.

17.2.2Zusammenarbeit der VPN-Redundanz Komponenten

Die einzelnen Komponenten arbeiten auf die gleiche Weise zusammen, wie bei der Firewall-Redundanz. Der VPN-Zustandsabgleich wird ebenfalls durch die Statusüberwa­chung gesteuert, der Status wird festgehalten und es werden Updates gesendet.

Damit die Zustände eintreten, müssen bestimmte Bedingungen erfüllt werden. Der VPN-Zustandsabgleich wird damit mit berücksichtigt.

17.2.3Fehlerkompensation durch die VPN-Redundanz

Die VPN-Redundanz kompensiert genau die gleichen Fehler wie die Firewall-Redundanz (siehe „Fehlerkompensation durch die Firewall-Redundanz“ auf Seite 445).

Allerdings kann bei einer Netzwerk-Lobotomie der VPN-Teil die anderen VPN-Gateways stören. Die von einander unabhängigen mGuard s haben dann die gleiche virtuelle IP-Ad­resse um mit den VPN-Partnern zu kommunizieren. Das kann dazu führen, dass die VPN-Verbindungen in schneller Folge auf- und abgebaut werden.

17.2.4Variablen für die VPN-Redundanz erstellen

Bei passenden Lizenzschlüsseln wird die VPN-Redundanz automatisch aktiviert, wenn Sie die Firewall-Redundanz aktivieren. Dies geschieht, sobald Sie im Menü   Redundanz >> Fi­rewall-Redundanz >> Redundanz   den Punkt   Aktiviere Redundanz   auf Ja stellen.

Es gibt kein eigenes Menü für die VPN-Redundanz. Die vorhandenen Firewall-Redundanz-Variablen werden erweitert.

17.2.5Voraussetzungen für die VPN-Redundanz

–Die VPN-Redundanz kann nur aktiviert werden, wenn ein Lizenzschlüssel für die VPN-Redundanz installiert ist und eine VPN-Verbindung aktiviert ist.

–Nur bei TC MGUARD RS4000 3G , TC MGUARD RS4000 4G , FL MGUARD RS4004 , FL MGUARD RS4000 , FL MGUARD GT/GT  und FL MGUARD RS  

Wenn eine VPN-Verbindung über einen VPN-Schalter gesteuert wird, dann kann die VPN-Redundanz nicht aktiviert werden.

(unter:  IPsec VPN >> Global >> Optionen  >> VPN-Schalter)

Beim VPN-Zustandsabgleich wird kontinuierlich der Zustand der VPN-Verbindung vom ak­tiven auf den mGuard  in Bereitschaft übertragen, damit dieser im Fehlerfall eine tatsächli­che Kopie hat. Die einzige Ausnahme dazu ist der Status des IPsec Replay Windows. Än­derungen dort werden nur von Zeit zur Zeit übertragen.

Der Umfang des Datenverkehrs für den Zustandsabgleich hängt nicht von dem Datenver­kehr ab, der über die VPN-Tunnel geleitet wird. Das Datenvolumen für den Zustandsab­gleich wird durch verschiedene Parameter bestimmt, die für ISAKMP SAs und IPsec SAs vergeben werden.

17.2.6Umgang der VPN-Redundanz mit extremen Situationen

Die Bedingungen, die unter „Umgang der Firewall-Redundanz mit extremen Situationen“ auf Seite 446 aufgeführt sind, gelten auch für die VPN-Redundanz. Sie gelten auch dann, wenn der mGuard  ausschließlich dafür genutzt wird, VPN-Verbindungen weiterzuleiten. Der mGuard  leitet die Datenströme über die VPN-Tunnel weiter und sortiert fehlerhafte Pa­kete aus, unabhängig davon, ob für die VPN-Verbindungen Firewall-Regeln definiert sind oder nicht.

Ein Fehler unterbricht den laufenden Datenverkehr

Wenn ein Fehler den Datenverkehr unterbricht, der über die VPN-Tunnel läuft, ist das eine extreme Situation. In diesem Fall ist der IPsec-Datenverkehr für kurze Zeit für Replay-Attacken anfällig. (Eine Replay-Attacke ist die Wiederholung bereits gesendeter verschlüs­selter Datenpakete mit Hilfe von Kopien, die ein Angreifer aufbewahrt hat.) Der Datenver­kehr wird mit Hilfe von Sequenznummern geschützt. Für jede Richtung eines IPsec-Tunnels werden unabhängige Sequenznummern verwendet. Der mGuard  lässt ESP-Pakete fallen, die die gleiche Sequenznummer haben, wie ein Paket, das der mGuard  für einen bestimm­ten IPsec-Tunnel bereits entschlüsselt hat. Dieser Mechanismus wird IPsec-Replay-Window genannt.

Das IPsec-Relay-Window wird beim Zustandsabgleich nur von Zeit zur Zeit repliziert, da es zu viele Ressourcen bindet. So kann es vorkommen, dass nach einem Failover der aktive mGuard  ein veraltetes IPsec-Replay-Window hat. Auf diese Weise ist ein Angriff möglich, bis der echte VPN-Partner das nächste ESP-Paket für die entsprechenden IPsec SA sen­det oder bis der IPsec SA erneuert wird.

Um eine zu geringe Sequenznummer bei dem ausgehenden IPsec SA zu verhindern, ad­diert die VPN-Redundanz zu jeder ausgehenden IPsec SA einen konstanten Wert zur Se­quenznummer dazu, bevor der mGuard  aktiv wird. Dieser Wert ist so berechnet, dass er zu der maximalen Anzahl an Datenpaketen passt, die durch den VPN-Tunnel während der ma­ximalen Failover-Umschaltzeit gesendet werden können. Im schlimmsten Fall (bei einem Gigabit-Ethernet und einer Umschaltzeit von 10 Sekunden) sind das 0,5 % einer IPsec Se­quenz. Im besten Fall ist es nur ein Promille.

Das Addieren des konstanten Wertes zur Sequenznummer verhindert, dass eine Sequenz­nummer versehentlich wiederverwendet wird, die bereits vom anderen mGuard  verwendet wurde, kurz bevor dieser ausgefallen ist. Ein weiterer Effekt ist, dass die ESP-Pakete, die vom vorher aktiven mGuard  gesendet wurden, vom VPN-Partner fallengelassen werden, wenn neue ESP-Pakete vom nun aktiven mGuard  früher ankommen. Dafür ist es aber not­wendig, dass die Latenzzeit im Netzwerk sich von der Failover-Umschaltzeit unterscheidet.

Ein Fehler unterbricht den ersten Aufbau von ISAKMP SA oder IPsec SA

Wenn ein Fehler den ersten Aufbau von ISAKMP SA oder IPsec SA unterbricht, dann kann der mGuard  in Bereitschaft den Aufbau nahtlos fortsetzen, da der Status der SA synchron repliziert wird. Der Response auf eine IKE-Nachricht wird nur vom aktiven mGuard  gesen­det, nachdem der mGuard  in Bereitschaft den Empfang des entsprechenden Updates des VPN-Zustandsabgleichs bestätigt hat.

Wenn ein mGuard  aktiv wird, wiederholt er sofort die letzte IKE-Nachricht, die vom vorher aktiven mGuard  hätte gesendet werden müssen. Damit wird der Fall kompensiert, dass der vorher aktive mGuard  zwar den Zustandabgleich noch gesendet hat, aber ausgefallen ist, bevor er die entsprechende IKE-Nachricht senden konnte.

Auf diese Weise wird während eines Failovers der Aufbau von ISAKMP SA oder IPsec SA nur um die Zeit verzögert, die für die Umschaltung benötigt wird.

Ein Fehler unterbricht die Erneuerung einer ISAKMP SA

Wenn ein Fehler die Erneuerung einer ISAKMP SA unterbricht, wird das auf die gleiche Weise ausgeglichen, wie dem ersten Aufbau einer SA. Außerdem wird die alte ISAKMP SA für die Dead Peer Detection beibehalten, bis die Erneuerung der ISAKMP SA abgeschlos­sen ist.

Ein Fehler unterbricht die Erneuerung einer IPsec SA

Wenn ein Fehler die Erneuerung einer IPsec SA unterbricht, wird das auf die gleiche Weise ausgeglichen, wie dem ersten Aufbau einer SA. Solange die Erneuerung der ISAKMP SA noch nicht abgeschlossen ist, werden die alten ein- und ausgehende IPsec SAs beibehal­ten, bis der VPN-Partner den Wechsel bemerkt hat.

Der VPN-Zustandsabgleich sorgt dafür, dass die alten IPsec SA beibehalten werden, so­lange der mGuard  in Bereitschaft ist. Wenn er dann aktiv wird, ist sichergestellt, dass er ohne weitere Aktionen mit der Ver- und Entschlüsselung des Datenverkehrs fortfahren kann.

Datenpaket-Verlust beim VPN-Zustandsabgleich

Der Zustandsabgleich ist gegen den Verlust von einem von zwei aufeinanderfolgenden Up­date-Paketen resistent. Wenn mehr Datenpakete verloren gehen, kann es zu einer länge­ren Umschaltzeit im Fehlerfall kommen.

Der mGuard  in Bereitschaft hat ein veraltetes Maschinenzertifikat

Es kann vorkommen, dass X.509-Zertifikate und private Schlüssel geändert werden müs­sen, die von einem Redundanzpaar genutzt werden, um sich selbst als VPN-Partner zu au­thentifizieren. Die Kombination aus privatem Schlüssel und Zertifikat wird im Folgenden Maschinenzertifikat genannt.

Jeder mGuard  eines Redundanzpaares muss neu konfiguriert werden, um das Maschinen­zertifikat zu tauschen. Und beide mGuard s benötigen das gleiche Zertifikat, um aus der Sicht ihrer VPN-Partner als die selbe virtuelle VPN-Appliance zu erscheinen.

Da jeder mGuard  einzeln neu konfiguriert wird, kann es für eine kurze Zeit vorkommen, dass der mGuard  in Bereitschaft ein veraltetes Maschinenzertifikat besitzt.

Wenn der mGuard  in Bereitschaft genau in dem Augenblick aktiv wird, in dem ISAKMP SAs aufgebaut werden, kann es das mit einem veralteten Maschinenzertifikat nicht fortsetzen,

Als Gegenmaßnahme repliziert der VPN-Zustandsabgleich das Maschinenzertifikat vom aktiven mGuard s zu dem mGuard  in Bereitschaft. Bei einem Failover wird der mGuard  in Bereitschaft dieses nur benutzen, um den bereits begonnenen Aufbau der ISAKMP SAs abzuschließen.

Wenn der mGuard  in Bereitschaft nach einem Failover neue ISAKMP SAs aufbaut, wird er das noch konfigurierte Maschinenzertifikat nutzen.

Der VPN-Zustandsabgleich sorgt also für die Replizierung der Maschinenzertifikate, die ge­rade benutzt werden. Aber es repliziert nicht die Konfiguration selbst.

Der mGuard  in Bereitschaft hat einen veralteten Pre-Shared-Key (PSK)

Ebenso müssen Preshared-Keys (PSK) zur Authentifizierung von VPN-Partnern manchmal erneuert werden. Für eine kurze Zeit können also die redundanten mGuard s einen unter­schiedlichen PSK haben. In diesem Fall kann nur einer der mGuard s eine VPN-Verbindung aufbauen, da die meisten VPN-Partner nur einen PSK akzeptieren. Der mGuard  hat hierfür keine Gegenmaßnahme.

Wenn der VPN-Zustandsabgleich die PSKs längere Zeit auf den mGuard  in Bereitschaft repliziert, dann verdeckt dies eine fehlerhafte Konfiguration für eine längere Zeit und ist schwer zu entdecken.

17.2.7Zusammenwirken mit anderen Geräten

Auflösen von Hostnamen

Wenn Hostnamen als VPN-Gateways konfiguriert sind, dann müssen die mGuard s eines Redundanzpaares in der Lage sein, die Hostnamen zu selben IP-Adresse aufzulösen. Dies gilt besonders, wenn   DynDNS-Überwachung   (siehe   Seite 335  ) aktiviert ist.

Wenn die Hostnamen von dem mGuard  in Bereitschaft auf eine andere IP-Adresse aufge­löst werden, dann wird nach einem Failover die VPN-Verbindung zu diesem Host abgebro­chen. Die VPN-Verbindung wird an einer anderen IP-Adresse wieder aufgebaut. Dies pas­siert direkt nach dem Failover. Es kann aber zu einer kurzen Verzögerung kommen, die u. a. davon abhängt, was unter   DynDNS-Überwachung   als Wert für das   Abfrageintervall  einge­tragen ist.

Veraltetes IPsec-Replay-Window

Der IPsec-Datenverkehr ist gegen einen unauthorisierten Zugriff geschützt. Dazu wird jeder IPsec-Tunnel mit einer unanhängigen Sequenznummer versehen. Der mGuard  lässt ESP-Pakete fallen, die die gleiche Sequenznummer haben, wie ein Paket, das der mGuard  für einen bestimmten IPsec-Tunnel bereits entschlüsselt hat. Dieser Mechanismus wird IPsec-Replay-Window genannt. Es verhindert einen Replay-Angriff, bei dem der Angreifer zuvor aufgezeichnete Daten sendet, um etwa eine fremde Identität vorzutäuschen.

Das IPsec-Relay-Window wird beim Zustandsabgleich nur von Zeit zur Zeit repliziert, da es zu viele Ressourcen bindet. So kann es vorkommen, dass nach einem Failover der aktive mGuard  ein veraltetes IPsec-Replay-Window hat. Auf diese Weise ist kurzzeitig eine Replay-Angriff möglich, bis der echte VPN-Partner das nächste ESP-Paket für die entspre­chenden IPsec SA sendet oder bis der IPsec SA erneuert wird. Allerdings müsste ein voll­ständiger Traffic gekapert werden.

Dead Peer Detection

Sie müssen bei der Dead Peer Detection einen Punkt beachten.

Andernfalls könnten die VPN-Partner das Redundanzpaar für tot halten, obwohl sie nur mit dem Failover beschäftigt sind.

Datenverkehr

Eine hohe Latenzzeit im Netzwerk, das für die Updates des Zustandsabgleichs genutzt wird führt dazu, dass der mGuard  in Bereitschaft in den „outdated“ Zustand geht. Das Gleiche geschieht bei einem ernsten Datenverlust in diesem Netzwerk.

Solange nicht mehr als zwei aufeinander folgende Updates verloren gehen, kommt es aber nicht dazu. Denn der mGuard  in Bereitschaft fordert automatisch eine Wiederholung des Updates ein. Die Anforderungen an die Latenzzeit sind dieselben, wie unter „Umschaltzeit im Fehlerfall“ auf Seite 443 beschrieben.

Reale IP-Adressen

VPN-Partner dürfen keinen ESP-Traffic an die reale IP-Adresse des Redundanzpaares senden. VPN-Partner müssen immer die virtuelle IP-Adresse des Redundanzpaares nut­zen, um dorthin IKE-Nachrichten oder ESP-Traffic zu senden.

17.2.8Übertragungsleistung der VPN-Redundanz

Die Werte gelten für den Netzwerk-Modus Router, wenn der Datenverkehr für den Zu­standsabgleich unverschlüsselt übertragen wird. Wenn die hier beschriebene Übertra­gungsleistung überschritten wird, kann im Fehlerfall eine längere Umschaltzeiten entste­hen, als eingestellt ist.

Failover-Umschaltzeit

Sie können die Umschaltzeit im Fehlerfall auf 1, 3 oder 10 Sekunden einstellen.

Die Obergrenze von 1 Sekunde wird derzeit nur vom mGuard centerport (Innominate)  / FL MGUARD CENTERPORT  auch unter hoher Auslastung eingehalten.

17.2.9Grenzen der VPN-Redundanz

Die Grenzen die für die Firewall-Redundanz dokumentiert sind, gelten auf für die VPN-Re­dundanz (siehe „Grenzen der Firewall-Redundanz“ auf Seite 452). Es gibt zusätzlich wei­tere Einschränkungen.

–Das Redundanzpaar muss bei diesen Punkten identisch konfiguriert sein:

–bei den allgemeinen VPN-Einstellungen und

–jeder einzelnen VPN-Verbindung.

–Der mGuard  akzeptiert VPN-Verbindungen nur an der ersten virtuellen IP-Adresse.

–Für den Netzwerk-Modus Router meint dies die erste interne und die erste externe IP-Adresse.

–Die folgenden Features können mit der VPN-Redundanz nicht genutzt werden:

–Die dynamische Aktivierung der VPN-Verbindungen mit Hilfe eines VPN-Schalters oder über die Kommandos des CGI-Skriptes nph-vpn.cgi (nur beim TC MGUARD RS4000 3G , TC MGUARD RS4000 4G , FL MGUARD RS4004  und FL MGUARD RS4000 ).

–Das Archivieren von Diagnose-Meldungen für VPN-Verbindungen.

–VPN-Verbindungen werden nur im Tunnel-Modus unterstützt. VPN-Verbindungen im Transport-Modus werden nicht hinreichend berücksichtigt.

–Die obere Grenze der Failover-Umschaltzeit gilt nicht für Verbindungen, die mit TCP gekapselt sind. Solche Verbindungen werden bei einem Failover für eine längere Zeit unterbrochen. Nach jedem Failover müssen die gekapselten TPC-Verbindungen von der initiierenden Seite neu aufgebaut werden. Wenn der Failover auf der initiierenden Seite passiert ist, können sie sofort nach der Übernahme starten. Aber wenn der Fai­lover auf der antwortenden Seite liegt, muss der Initiator erst die Unterbrechung entde­cken und kann sie dann neu aufbauen.

–Die VPN-Redundanz unterstützt Masquerading auf die gleiche Weise, wie ohne VPN-Redundanz. Dies gilt, wenn ein Redundanzpaar durch ein NAT-Gateway mit einer dy­namischen IP-Adresse maskiert wird.

Zum Beispiel kann ein Redundanzpaar hinter einem DSL-Router versteckt werden, der das Redundanzpaar mit einer offiziellen IP-Adresse maskiert. Dieser DSL-Router leitet den IPsec-Datenverkehr (IKE und ESP, UDP-Ports 500 und 4500) zu den virtuellen IP-Adressen weiter. Wenn sich die dynamische IP-Adresse ändert, werden alle aktiven VPN-Verbindungen, die über das NAT-Gateway fließen, wieder aufgebaut.

Für den Wiederaufbau sorgt die Dead Peer Detection (DPD) mit der dafür konfigurier­ten Zeit. Dieser Effekt liegt außerhalb des Einflussbereichs des mGuard s.

–Die Redundanz-Funktion des mGuard s unterstützt keine Pfad-Redundanz. Die Pfad-Redundanz kann über andere Maßnahmen erreicht werden, z. B. über ein Routerpaar. Dieses Routerpaar wird auf der einen virtuellen Seite von den mGuard s gesehen, wäh­rend auf der anderen Seite jeder der Router unterschiedliche Verbindungen hat.

Eine Pfad-Redundanz darf keine NAT-Mechanismen wie Masquerading nutzen, um die virtuellen IP-Adressen der mGuard s zu verbergen. Andernfalls wird eine Migration von einem Pfad zum anderen die IP-Adressen, mit denen das Redundanzpaar maskiert ist, ändern. Das würde dazu führen, dass alle VPN-Verbindungen (alle ISAKMP SAs und alle IPsec SAs) wieder aufgebaut werden müssen.

Für den Wiederaufbau sorgt die Dead Peer Detection (DPD) mit der dafür konfigurier­ten Zeit. Dieser Effekt liegt außerhalb des Einflussbereichs des mGuard s.

–Bei einer Pfad-Redundanz, die durch eine Netzwerk-Lobotomie ausgelöst wird, wer­den die VPN-Verbindungen nicht länger unterstützt. Eine Netzwerk-Lobotomie muss wenn möglich verhindert werden.

X.509-Zertifikate für die VPN-Authentification

Der mGuard  unterstützt die Verwendung von X.509-Zertifikaten beim Aufbau von VPN-Ver­bindungen. Dies wird ausführlich unter „Authentifizierung“ auf Seite 359 beschrieben.

Es gib aber einige Besonderheiten, wenn X.509-Zertifikate zur Authentifizierung von VPN-Verbindungen in Kombination mit Firewall- und VPN-Redundanz genutzt werden.

Maschinen-Zertifikate wechseln

Ein Redundanzpaar kann so konfiguriert werden, dass es gemeinsam einen X.509-Zertifi­kat und einen entsprechenden privaten Schlüssel nutzt, um sich selbst als virtuelle einzelne VPN-Instanz bei einem entfernten VPN-Partner zu identifizieren.

Diese X.509-Zertifikate müssen regelmäßig erneuert werden. Wenn der VPN-Partner so eingestellt ist, dass er den Gültigkeitszeitraum der Zertifikate prüft, müssen diese erneuert werden, bevor ihre Gültigkeit erlischt (siehe „Zertifikatseinstellungen“ auf Seite 261).

Wenn ein Maschinenzertifikat ersetzt wird, werden alle VPN-Verbindung, die es nutzen, vom mGuard  neu gestartet. Währenddessen kann der mGuard  für eine bestimmte Zeit über die betroffenen VPN-Verbindungen keine Daten weiterleiten. Die Zeit hängt von der Anzahl der betroffenen VPN-Verbindungen, der Leistungsfähigkeit des mGuard s und der VPN-Partner und der Latenzzeit der mGuard s im Netzwerk ab.

Wenn dies für die Redundanz nicht tragbar sein sollte, müssten die VPN-Partner eines Re­dundanzpaares so konfiguriert werden, dass sie alle Zertifikate akzeptieren, deren Gültig­keit über einen Satz von bestimmten CA-Zertifikaten bestätigt wird (siehe „CA-Zertifikate“ auf Seite 265 und „Authentifizierung“ auf Seite 359).

Wenn das neue Maschinenzertifikat von einem anderen Sub-CA-Zertifikat herausgegeben wird, dann muss der VPN-Partner dieses kennen, bevor das Redundanzpaar das neue Ma­schinenzertifikat nutzt.

Das Maschinenzertifikat muss an beiden mGuard s eines Redundanzpaars getauscht we­den. Aber manchmal ist das nicht möglich, wenn einer nicht erreichbar ist. Dies kann zum Beispiel bei einem Netzwerkausfall geschehen. So kann der mGuard  in Bereitschaft ein veraltetes Maschinenzertifikat haben, wenn er aktiv wird. Das ist ein weiterer Grund dafür, dass die VPN-Partner so eingestellt sein müssen, dass sie beide Maschinenzertifikate nut­zen.

Normalerweise wird von dem VPN-Zustandsabgleich auch das Maschinenzertifikat mit dem passenden Schlüssel repliziert. Bei einem Failover kann der andere mGuard  überneh­men und sogar den Aufbau unvollständiger ISAKMP SAs fortsetzen.

Remote-Zertifikate für eine VPN-Verbindung wechseln

Der mGuard  kann so eingestellt werden, dass er VPN-Partner direkt über die X.509-Zertifi­kate authentifiziert, die diese vorweisen. Dafür muss dieses X.509-Zertifikat beim mGuard  eingestellt sein. Es wird   Remote CA-Zertifikat   genannt.

Wenn ein Remote-Zertifikat erneuert wird, hat kurzfristig nur einer der mGuard s ein neues Zertifikat. Wir empfehlen deshalb bei der VPN-Redundanz die VPN-Partner über CA-Zerti­fikate statt über Remote-Zertifikate zu authentifizieren.

Neues CA-Zertifikat hinzufügen, um VPN-Partner zu identifizieren

Der mGuard  kann so eingestellt werden, das er VPN-Partner über CA-Zertifikate authenti­fiziert (siehe „CA-Zertifikate“ auf Seite 265 und „Authentifizierung“ auf Seite 359).

Bei dieser Einstellung kann ein neues CA-Zertifikat hinzugefügt werden, ohne die aufge­bauten VPN-Verbindungen zu beeinflussen. Aber die neuen CA-Zertifikate werden sofort genutzt. Das X.509-Zertifikat, das der VPN-Partner nutzt, um sich beim mGuard  zu authen­tifizieren kann dann mit einer minimalen Unterbrechung ausgetauscht werden. Es muss nur sichergestellt werden, dass das neue CA-Zertifikat zuerst verfügbar ist.

Der mGuard  kann so eingestellt werden, dass er den Gültigkeitszeitraum der Zertifikate prüft, die vom VPN-Partner bereitgestellt werden (siehe „Zertifikatseinstellungen“ auf Seite 261). In diesem Fall ist es notwendig, dass neue vertrauenswürdige CA-Zertifikate zur Konfiguration des mGuard s hinzugefügt werden. Diese Zertifikate sollten ebenfalls einen Gültigkeitszeitraum haben.

Wenn die CRL-Prüfung eingeschaltet ist (unter   Authentifizierung >> Zertifikate >> Zertifi­katseinstellungen ), dann muss eine URL pro CA-Zertifikat vorgehalten werden, an der die entsprechende CRL verfügbar ist. Die URL und CRL müssen veröffentlicht werden, bevor der mGuard  die CA-Zertifikate nutzt, um die Gültigkeit der von den VPN-Partnern vorge­zeigten Zertifikate zu bestätigen.

Einsatz von X.509-Zertifikaten mit einem beschränkten Gültigkeitszeitraum und CRL-Prüfung

Der Einsatz von X.509-Zertifikaten wird unter „Zertifikatseinstellungen“ auf Seite 261 be­schrieben (Menü   „Authentifizierung >> Zertifikate >> Zertifikatseinstellungen“   ).

Wenn Sie X.509-Zertifikate einsetzen und dort Beachte den Gültigkeitszeitraum von Zertifikaten und CRLs eingestellt haben, dann muss die Systemzeit stimmen. Wir emp­fehlen, die Systemzeit mit einem vertrauenswürdigen NTP-Server zu synchronisieren. Jeder mGuard  eines Redundanzpaars kann den anderen als NTP-Server nutzen, aber nicht als einzigen NTP-Server.