13Redundanz

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-Geräte zu einem Redun­danzpaar zusammenzufassen, bei dem im Fehlerfall der eine die Funktion des anderen übernimmt.

–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.

13.1Firewall-Redundanz

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

Bild 13-1Firewall-Redundanz (Beispiel)

Grundbedingungen für die Firewall-Redundanz

–Nur baugleiche mGuard-Geräte können ein Redundanzpaar bilden.

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

–Im Netzwerk-Modus „Stealth“ wird die Firewall Redundanz nur in der Stealth-Konfigu­ration „Mehrere Clients“, unterstützt.

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

13.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 mGuards an.

Konnektivitätsprüfung

Bei jedem Gerät eines Redundanzpaares wird kontinuierlich geprüft, ob eine Verbindung besteht, über die Netzwerkpakete weitergeleitet werden können.

Jedes mGuard-Gerät prüft seine interne und externe Netzwerk-Schnittstelle unabhängig voneinander. 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 Gerät eines Redundanzpaares wird außerdem kontinuierlich geprüft, ob ein ak­tives mGuard-Gerät vorhanden ist und ob dieses aktiv bleiben soll. Dafür wird eine Variante des CARP (Common Address Redundancy Protocol) verwendet.

Das aktive mGuard-Gerät sendet ständig Anwesenheitsnachrichten über sein internes und externes Netzwerk-Interface, während beide Geräte zuhören. Wenn ein dedizierter Ether­net-Link für den Zustandsabgleich der Firewall vorhanden ist, wird die Anwesenheitsnach­richt auch über diesen gesendet. In diesem Fall kann die Anwesenheitsnachricht für die ex­terne Netzwerk-Schnittstelle auch unterdrückt werden.

Die Verfügbarkeitsprüfung wird nicht bestanden, wenn ein mGuard-Gerät in einer bestimm­ten Zeit keine Anwesenheitsnachricht erhält. Außerdem wird die Prüfung nicht bestanden, wenn ein Gerät 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

Das mGuard-Gerät, das sich im Zustand der Bereitschaft befindet, erhält eine Kopie des Zustandes des aktuell aktiven mGuard-Geräts.

Dazu gehört eine Datenbank mit den weitergeleiteten Netzwerkverbindungen. Diese Da­tenbank wird laufend durch die weitergeleiteten Netzwerkpakete aufgebaut und erneuert. Die unverschlüsselten Zustandsdaten werden über die physikalische LAN-Schnittstelle übertragen und niemals über das virtuelle Netzwerk-Interface gesendet.

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

Virtuelle IP-Adressen

Jedes mGuard-Gerät wird mit virtuellen IP-Adressen konfiguriert. Deren Anzahl hängt von dem verwendeten Netzwerk-Modus ab. Bei einem Redundanzpaar müssen Sie beiden mGuard-Geräten die gleichen virtuellen IP-Adressen zuweisen. Die virtuellen IP-Adressen werden vom Gerät 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 mGuards 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 Geräte 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 Geräte eine Weiterleitung von speziellen UDP/TCP-Ports von einer virtuellen IP-Adresse zu anderen IP-Adressen, sofern letztere vom Gerät erreicht werden können. Zusätzlich maskiert das mGuard-Gerät Daten mit virtu­ellen IP-Adressen, wenn Masquerading-Regeln eingerichtet sind.

Statusüberwachung

Die Statusüberwachung entscheidet darüber, ob das Gerät im Zustand „aktiv“, in „Bereit­schaft“ oder im „Fehlerzustand“ ist. Jedes mGuard-Gerät entscheidet autonom über seinen Zustand, basierend auf den Informationen, die von anderen Komponenten bereitgestellt werden. Die Statusüberwachung sorgt dafür, dass nicht zwei Geräte 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-Redundanz >> Redundanz“   oder   „Redundanz >> Firewall-Redundanz >> Konnektivitäts­prüfung“   abgerufen werden.

13.1.2Zusammenarbeit der Firewall-Redundanz-Komponenten

Während des Betriebes interagieren die Komponenten folgendermaßen: Beide mGuard-Geräte führen fortlaufend für ihre beiden Netzwerk-Schnittstellen (internes und externes In­terface) eine Konnektivitätsprüfung durch. Außerdem wird fortlaufend eine Verfügbarkeits­prüfung gemacht. Dazu lauscht jedes Gerät kontinuierlich auf Anwesenheitsnachrichten (CARP) und das aktive Gerät 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-Geräte befinden. Die Sta­tusüberwachung sorgt dafür, dass das aktive Gerät seine Daten auf das andere Gerät spie­gelt (Zustandsabgleich).

13.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.

13.1.4Voraussetzungen für die Firewall-Redundanz

–Um die Redundanz-Funktion zu nutzen, muss auf beiden mGuard-Geräten die gleiche Firmwareversion installiert sein.

–Jeder Satz von Zielen für die Konnektivitätsprüfung kann nicht mehr als zehn Ziele be­inhalten. (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   „Ex­ternes 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.

13.1.5Umschaltzeit im Fehlerfall

Von der Variablen Umschaltzeit im Fehlerfall errechnet das mGuard-Gerät automatisch die Zeitabstände für die Konnektivitäts- und Verfügbarkeitsprüfung.

Konnektivitätsprüfung

In der Tabelle 13-1 werden die Faktoren angegeben, die die Zeitabstände für die Konnek­tivitätsprüfung bestimmen.

Für die Konnektivitätsprüfung werden ICMP-Echo-Requests verschickt, die 64 Byte 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 13-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 Gerät 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 Tabelle 13-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 Kon­nektivitätsprüfung ausfällt. Diese Prüfung toleriert, wenn von zwei aufeinander folgenden In­tervallen 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.

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

Tabelle 13-2 zeigt außerdem die maximale Latenzzeit, die das Gerät für das Netzwerk tole­riert, das die Anwesenheitsnachrichten (CARP) überträgt. Wenn diese Latenzzeit über­schritten wird, kann das Redundanzpaar ein undefiniertes Verhalten zeigen.

13.1.6Fehlerkompensation durch die Firewall-Redundanz

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

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

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

Jeder der beiden Geräte eines Redundanzpaares sitzt in einem unterschiedlichen Bereich (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 verbinden die Switche und die mGuard-Geräte ein externes mit einem internen Ethernet-Netzwerk. Sie stellen die Verbindung her, indem sie Netzwerk-Pakete (im Netzwerk-Modus Router) wei­terleiten.

Die Firewall-Redundanz kompensiert die Fehler, die in Bild 13-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 mGuards 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 13-2).

13.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 mGuards aufgesplittet wird. Jeder mGuard kümmert sich in diesem Fall um seine eigenen Tracking-Informationen, da die beiden mGuards 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 mGuards unterschiedliche Prio­ritäten haben, wird der mit der höheren aktiv und der andere geht in den Bereitschaftszu­stand. Wenn beide mGuards 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 mGuards ihren Firewall-Zustand selbst verwaltet. Der mGuard, der aktiv wird, behält seinen Zustand. Die Verbindungen des anderen mGuards, 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 212), 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 mGuards 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“   unter 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 mGuards 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 Fire­wall. Bevor die Verbindung also wieder hergestellt wird, muss dieser Datenbestand aktua­lisiert werden. Der primäre mGuard sorgt dafür, dass er zunächst eine aktuelle Kopie erhält, bevor er aktiv wird

13.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 mGuards 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 305). 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 mGuards 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 mGuards ü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 (Red­undanzverbund). 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 323 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 mGuards 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.

13.1.9Grenzen 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 mGuards möglich. Zugriffe auf virtuelle Adressen werden zurückgewiesen.

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

–ein DHCP-Server,

–ein DHCP-Relay,

–eine Benutzer-Firewall und

–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)

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

–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 326 und „Failo­ver beim Aufbau von semi-unidirektionalen Verbindungen“ auf Seite 326.)

–Der Zustandsabgleich repliziert keine Connection-Tracking-Einträge für ICMP-Echo-Requests, die vom mGuard weitergeleitet werden. Deshalb können ICMP-Echo-Re­plies 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 mGuards ohne Firewall-Redundanz. Ohne aktivierte Firewall-Redundanz wird in einer Routing-Tabelle festgelegt, hinter welcher externen bzw. internen IP-Adresse der Sender verborgen wird.