Wechseln zu:Navigation, Suche
Wiki
KKeine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
{{DISPLAYTITLE:Cluster}}
{{Set_lang}}
== Informationen ==
 
Letze Anpassung zur Version: '''11.7'''  
 
</div>{{DISPLAYTITLE:Cluster}}{{TOC2}}
<p>'''Securepoint Cluster Konfiguration'''<br>
'''Best Practice'''
</p>
 
<p>Letzte Anpassung zur Version: '''11.8.7''' </p>
<br>
<br>
Bemerkung: Artikelanpassung
{{cl |Neu: |
* Erweiterte Hinweise zu DHCP
* Artikelanpassung
|w=40px}}
 
<br>
<br>
Vorherige Versionen: -
Vorherige Versionen: [[UTM/NET/Cluster_11.7 | '''11.7]]
<br>
<br>


'''Securepoint Cluster Konfiguration'''<br>
----
'''Best Practice'''




Zeile 15: Zeile 24:


'''Aktuelle Software'''<br>
'''Aktuelle Software'''<br>
Installieren Sie immer die neueste Version der Software. Nur in der aktuellen Version sind die neusten Funktionen, Sicherheits-Erweiterungen und Fehlerkorrekturen enthalten.
{{Hinweis | !|r}} Installieren Sie immer die neueste Version der Software. Nur in der aktuellen Version sind die neusten Funktionen, Sicherheits-Erweiterungen und Fehlerkorrekturen enthalten.


Für weiterführende Informationen, kontaktieren sie unseren Support:<br>
----
E-Mail: [mailto:support@securepoint.de support@securepoint.de]<br>
Telefon: 04131 2401 0


Oder nutzen Sie unser Support Portal:<br>
=== Einsatzgebiete ===
[http://support.securepoint.de/ http://support.securepoint.de]
 
 
= Einsatzgebiete =
Die UTM wird, durch die Umwandlung in einen Hot-Standy UTM-Cluster, aufgewertet und sichert geschäftskritische Prozesse gegen den Ausfall einer UTM ab. Securepoint stellt dazu einen Aktiv-/Passiv-Cluster zur Verfügung. Die UTMs innerhalb des Clusters überwachen sich gegenseitig und schalten bei Bedarf automatisch auf das Gerät mit dem besten Status um. Ein Eingriff des Administrators nicht notwendig.  
Die UTM wird, durch die Umwandlung in einen Hot-Standy UTM-Cluster, aufgewertet und sichert geschäftskritische Prozesse gegen den Ausfall einer UTM ab. Securepoint stellt dazu einen Aktiv-/Passiv-Cluster zur Verfügung. Die UTMs innerhalb des Clusters überwachen sich gegenseitig und schalten bei Bedarf automatisch auf das Gerät mit dem besten Status um. Ein Eingriff des Administrators nicht notwendig.  
{{Bild|Cluster-01.jpg|Abb.: 1.1}}


----


[[Datei:Cluster-01.jpg|800px|center|Abb.: 1.1]]
==== Einrichtung ====
 
 
== Einrichtung ==
Bei der Einrichtung des UTM-Clusters werden zwei UTMs mit identischer Firmware über eine Hotwire-Schnittstelle verbunden. Die Installation mit dem „Cluster Setup Wizard“ wird auf der ''Ursprungs-UTM'' ausgeführt, die im dann erstellen Cluster der MASTER sein wird. Mit dieser UTM wird die Synchronisierung der Konfiguration durchgeführt. Auf der ''Spare-UTM'', die im Cluster das BACKUP sein wird, werden bei der Installation die Hotwire-Schnittstelle definiert sowie ein SSH-Schlüssel erzeugt. Auch wird auf der Spare der SSH-Schlüssel des MASTER eingetragen.  
Bei der Einrichtung des UTM-Clusters werden zwei UTMs mit identischer Firmware über eine Hotwire-Schnittstelle verbunden. Die Installation mit dem „Cluster Setup Wizard“ wird auf der ''Ursprungs-UTM'' ausgeführt, die im dann erstellen Cluster der MASTER sein wird. Mit dieser UTM wird die Synchronisierung der Konfiguration durchgeführt. Auf der ''Spare-UTM'', die im Cluster das BACKUP sein wird, werden bei der Installation die Hotwire-Schnittstelle definiert sowie ein SSH-Schlüssel erzeugt. Auch wird auf der Spare der SSH-Schlüssel des MASTER eingetragen.  


Zeile 39: Zeile 41:
Die UTM mit der niedrigeren Priorität, die passive UTM, ist das BACKUP.
Die UTM mit der niedrigeren Priorität, die passive UTM, ist das BACKUP.


== Voraussetzungen ==
----
 
==== Voraussetzungen ====
Zum Cluster-Betrieb sind folgende Voraussetzungen notwendig:
Zum Cluster-Betrieb sind folgende Voraussetzungen notwendig:




=== Eine Cluster-Lizenz ===
* '''Eine Cluster-Lizenz'''<br><p>Zur Konfiguration und den Betrieb des UTM-Clusters wird eine gültige Cluster-Lizenz benötigt, die im [https://my.securepoint.de/index/login Securepoint Reseller Portal] beantragt werden kann:</p><p>Endkunden wenden sich bitte an Ihren [https://www.securepoint.de/partner/partnerprogramm.html autorisierten Securepoint Reseller.]</p><p>{{Hinweis | !! Die Menüpunkte zur Cluster-Konfiguration sind sichtbar, sobald eine Cluster-Lizenz eingespielt ist.|gelb|s=true}}<p>
Zur Konfiguration und den Betrieb des UTM-Clusters wird eine gültige Cluster-Lizenz benötigt, die im Securepoint Reseller Portal beantragt werden kann:


* '''Zwei identische Appliances mit mindestens 3 Ethernet Schnittstellen und gleicher Firmware'''<br><p>Im kleinsten Szenario (siehe Abbildung 1.1) sind eine Eingangs-Schnittstelle (internes LAN) und eine Ausgangs-Schnittstelle (externes LAN) sowie die dritte freie Schnittstelle vorhanden. Diese, im Folgenden auch als Hotwire-Schnittstelle bezeichnet, wird für den Abgleich der Konfiguration und das Connection-Tracking benötigt. Sie kann keine weitere Netzwerkfunktion übernehmen.</p>


[https://my.securepoint.de/index/login https://my.securepoint.de/index/login]
* '''Die eingesetzten Switches und Router unterstützen ''gratuitous ARP'''''<br><p>Kommt es im UTM-Cluster zum Master-/Backup-Wechsel, sendet die jetzt aktive UTM ''gratuitous ARP'' Pakete an ihre Umgebung, um die neuen MAC-Adresse bekannt zu geben.<br>Unterstützen die Switches bzw. Router diese Funktion nicht, können sie nur verzögert über die aktive UTM kommunizieren.


----


Endkunden wenden sich bitte an Ihren autorisierten Securepoint Reseller:


 
{{pt3|UTM11_BP_Cluster_pic5.png|Abb.: 1.2 | {{h4| Funktionsweise des Clusters |Funktionsweise des Clusters}} }}
[http://www.securepoint.de/partnerprogramm/ http://www.securepoint.de/partnerprogramm/]
Der Cluster verwendet '''eindeutige IP- und MAC-Adressen''' für die beiden Mitglieder des Clusters sowie '''virtuelle IP-Adressen''' für den Cluster selber. Die virtuellen IP-Adressen sind allein auf dem aktiven Mitglied des UTM-Clusters aktiv. Fällt das aktive Mitglied des Clusters ganz oder teilweise aus, so wechseln die virtuellen IP-Adressen zum zweiten Mitglied des Clusters.
 
 
{|style="background-color:#FFFFFF;border:2pt solid #FF0000;padding:0.5cm;"
|-
|[[Datei:UMA20_AHB_hinweispic.png|50px]]
|'''Achtung!'''<br>
Die Menüpunkte zur Cluster-Konfiguration sind sichtbar, sobald eine Cluster-Lizenz eingespielt ist.
|}
 
 
 
 
=== Zwei identische Appliances mit mindestens 3 Ethernet Schnittstellen und gleicher Firmware: ===
Im kleinsten Szenario (siehe Abbildung 1.1) sind eine Eingangs-Schnittstelle (internes LAN) und eine Ausgangs-Schnittstelle (externes LAN) sowie die dritte freie Schnittstelle vorhanden. Diese, im Folgenden auch als Hotwire-Schnittstelle bezeichnet, wird für den Abgleich der Konfiguration und das Connection-Tracking benötigt. Sie kann keine weitere Netzwerkfunktion übernehmen.
 
=== Die eingesetzten Switches und Router unterstützen "gratuitous ARP"===
Kommt es im UTM-Cluster zum Master-/Backup-Wechsel, sendet die jetzt aktive UTM „gratuitous ARP“ Pakete an ihre Umgebung, um die neuen MAC-Adresse bekannt zu geben. Unterstützen die Switches bzw. Router diese Funktion nicht, können sie nur verzögert über die aktive UTM kommunizieren.
 
== Funktionsweise des Clusters ==
Der Cluster verwendet eindeutige IP- und MAC-Adressen, für die beiden Mitglieder des Clusters sowie virtuelle IP-Adressen für den Cluster selber. Die virtuellen IP-Adressen sind allein auf dem aktiven Mitglied des UTM-Clusters aktiv. Fällt das aktive Mitglied des Clusters ganz oder teilweise aus, so wechseln die virtuellen IP-Adressen zum zweiten Mitglied des Clusters.


Für die Clients und Server in einer Clusterkonfiguration, ist die virtuelle IP-Adresse der Kommunikationspartner im Routing (also zum Beispiel das Standard Gateway, siehe Abb. 1.2).
Für die Clients und Server in einer Clusterkonfiguration, ist die virtuelle IP-Adresse der Kommunikationspartner im Routing (also zum Beispiel das Standard Gateway, siehe Abb. 1.2).
<br clear=All>
----




[[Datei:UTM11_BP_Cluster_pic5.png|600px|Abb.: 1.2]]
{{pt3|UTM11_BP_Cluster_pic6.png| | {{ h4| Das Cluster VRR Protokoll | Das Cluster VRR Protokoll }} }}
 
<p>VRRP (Virtual Router Redundancy Protocol) ist das Kommunikationsprotokoll des Clusters. Es ist einzig auf den Schnittstellen aktiv, die als {{hoover|HA-|High-Availibility}}Schnittstelle konfiguriert sind. Über dieses Protokoll versendet der Master des UTM-Clusters Datenpakete an das Backup. Empfängt das Backup keine Datenpakete, so stuft es sich zum Master hoch.</p>
== Das Cluster VRR Protokoll ==
VRRP (Virtual Router Redundancy Protocol) ist das Kommunikationsprotokoll des Clusters. Es ist einzig auf den Schnittstellen aktiv, die als HA-Schnittstelle konfiguriert sind. Über dieses Protokoll versendet der Master des UTM-Clusters Datenpakete an das Backup. Empfängt das Backup keine Datenpakete, so stuft es sich zum Master hoch.


<p>Mit Hilfe von '''tcpdump''' können sie das Protokoll auf einer HA-Schnittstelle sichtbar machen (siehe Abb.)</p>


Mit Hilfe von '''tcpdump''' können sie das Protokoll auf einer HA-Schnittstelle sichtbar machen:
<p>Es sind keine speziellen Firewall Regeln notwendig, um die Kommunikation mit dem VRR-Protokoll zu ermöglichen.</p>


----


[[Datei:UTM11_BP_Cluster_pic6.png|600px]]
==== Umschalten des Clusters ====
 
 
Es sind keine speziellen Firewall Regeln notwendig, um die Kommunikation mit dem VRR-Protokoll zu ermöglichen.
 
== Umschalten des Clusters ==
Das Umschalten innerhalb des Clusters kann unter folgenden Bedingungen passieren:
Das Umschalten innerhalb des Clusters kann unter folgenden Bedingungen passieren:


* Das aktive Mitglied eines Clusters wird neu gestartet oder ganz heruntergefahren.
* Das aktive Mitglied eines Clusters wird neu gestartet oder ganz heruntergefahren.
Zeile 107: Zeile 87:
Tabelle, Verhalten im Cluster, Beispiel zwei HA-Schnittstellen:
Tabelle, Verhalten im Cluster, Beispiel zwei HA-Schnittstellen:


{| style="border-spacing:0;"
{| class="sptable0"
|-
! HA-Schnittstelle 1 !! HA-Schnittstelle 2 !! UTM 1 Status !! UTM 2 Status
! style="background-color:#A4A4A4;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;" |HA-Schnittstelle 1
! style="background-color:#A4A4A4;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;" |HA-Schnittstelle 2
! style="background-color:#A4A4A4;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;" |UTM 1 Status
! style="background-color:#A4A4A4;border:1pt solid #000000;padding:0.176cm;"|UTM 2 Status
|-
|-
| style="background-color:#ffffff;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| UTM 1 UP, UTM 2 UP
| UTM 1 UP{{mobil|<br>|, }}UTM 2 UP || UTM 1 UP{{mobil|<br>|, }}UTM 2 UP || style="background-color:#8ce390;"| <center>'''Aktiv'''</center> || style="background-color:#f5ffa1;"| <center>'''Passiv'''</center>
| style="background-color:#ffffff;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| UTM 1 UP, UTM 2 UP
| style="background-color:#8ce390;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| <center>'''Aktiv'''</center>
| style="background-color:#f5ffa1;border:1pt solid #000000;padding:0.176cm;"| <center>'''Passiv'''</center>
|-
|-
| style="background-color:#ffffff;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| UTM 1 DOWN, UTM 2 UP
| UTM 1 DOWN{{mobil|<br>|, }}UTM 2 UP || UTM 1 UP{{mobil|<br>|, }}UTM 2 UP || style="background-color:#f5ffa1;"| <center>'''Passiv'''</center> || style="background-color:#8ce390;"| <center>'''Aktiv'''</center>
| style="background-color:#ffffff;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| UTM 1 UP, UTM 2 UP
| style="background-color:#f5ffa1;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| <center>'''Passiv'''</center>
| style="background-color:#8ce390;border:1pt solid #000000;padding:0.176cm;"| <center>'''Aktiv'''</center>
|-
|-
| style="background-color:#ffffff;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| UTM 1 DOWN, UTM 2 DOWN
| UTM 1 DOWN{{mobil|<br>|, }}UTM 2 DOWN || UTM 1 UP{{mobil|<br>|, }}UTM 2 UP || style="background-color:#8ce390;"| <center>'''Aktiv'''</center> || style="background-color:#f5ffa1;" | <center>'''Passiv'''</center>
| style="background-color:#ffffff;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| UTM 1 UP, UTM 2 UP
| style="background-color:#8ce390;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| <center>'''Aktiv'''</center>
| style="background-color:#f5ffa1;border:1pt solid #000000;padding:0.176cm;"| <center>'''Passiv'''</center>
|-
|-
| style="background-color:#ffffff;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| UTM 1 DOWN, UTM 2 DOWN
| UTM 1 DOWN{{mobil|<br>|, }}UTM 2 DOWN || UTM 1 UP{{mobil|<br>|, }}UTM 2 DOWN || style="background-color:#d85568;"| <center>'''Aktiv'''</center> || style="background-color:#d85568;"| <center>'''Aktiv'''</center>
| style="background-color:#ffffff;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| UTM 1 UP, UTM 2 DOWN
| style="background-color:#d85568;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| <center>'''Aktiv'''</center>
| style="background-color:#d85568;border:1pt solid #000000;padding:0.176cm;"| <center>'''Aktiv'''</center>
|-
|-
| style="background-color:#ffffff;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| UTM 1 DOWN, UTM 2 DOWN
| UTM 1 DOWN{{mobil|<br>|, }}UTM 2 DOWN || UTM 1 DOWN{{mobil|<br>|, }}UTM 2 DOWN || style="background-color:#d85568;"| <center>'''Aktiv'''</center> || style="background-color:#d85568;"| <center>'''Aktiv'''</center>
| style="background-color:#ffffff;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| UTM 1 DOWN, UTM 2 DOWN
| style="background-color:#d85568;border-top:1pt solid #000000;border-bottom:1pt solid #000000;border-left:1pt solid #000000;border-right:none;padding:0.176cm;"| <center>'''Aktiv'''</center>
| style="background-color:#d85568;border:1pt solid #000000;padding:0.176cm;"| <center>'''Aktiv'''</center>
|}
|}
 
<br>
 
Hierbei ist zu beachten, dass UTM-1 eine höhere Priorität als UTM-2 hat. Ist der Zustand in der Tabelle aktiv und als rot gekennzeichnet bedeutet das, dass sich die beiden Mitglieder des Clusters nicht mehr sehen und davon ausgehen, dass der jeweils andere Partner nicht mehr vorhanden ist. Beide Mitglieder des Clusters sind dann aktiv. Eine Netzwerkkommunikation ist dann allerdings generell nicht mehr möglich, da das Problem in der Umgebung liegt.
Hierbei ist zu beachten, dass UTM-1 eine höhere Priorität als UTM-2 hat. Ist der Zustand in der Tabelle aktiv und als rot gekennzeichnet bedeutet das, dass sich die beiden Mitglieder des Clusters nicht mehr sehen und davon ausgehen, dass der jeweils andere Partner nicht mehr vorhanden ist. Beide Mitglieder des Clusters sind dann aktiv. Eine Netzwerkkommunikation ist dann allerdings generell nicht mehr möglich, da das Problem in der Umgebung liegt.


== Hotwire-Schnittstelle ==
----
Das Hotwire-Schnittstelle ist eine exklusives Schnittstelle, welches nur zum Synchronisieren der Konfiguration der Cluster-Mitglieder und Abgleich der laufenden Verbindungen (Connection-Tracking) verwendet wird. Diese Schnittstelle hat exklusiv diese Aufgabe. Das muss bei der Auswahl der Appliance entsprechend werden.


Für die Synchronisation der Konfiguration wird das SSH-Protokoll (TCP/22) verwendet. Das Connection-Tracking wird über den Port 3780 (UDP) abgeglichen. Ist eine Ethernet-Schnittstelle als Hotwire gekennzeichnet, werden die Regeln für die Kommunikation automatisch generiert. Für die SSH-Verbindung müssen öffentliche Schlüssel zwischen den Mitgliedern des UTM-Clusters ausgetauscht werden. Der Abgleich der Konfiguration kann in beide Richtungen zwischen den Mitgliedern des Cluster erfolgen. Das Connection-Tracking wird immer automatisch von dem Master im Cluster zum Backup übertragen (Abb. 1.3).
{{pt3 | UTM11_BP_Cluster_pic7.png|Abb.: 1.3 | {{h4| Hotwire-Schnittstelle |Hotwire-Schnittstelle}} }}
Die Hotwire-Schnittstelle ist eine exklusive Schnittstelle, die nur zum Synchronisieren der Konfiguration der Cluster-Mitglieder und Abgleich der laufenden Verbindungen (Connection-Tracking) verwendet wird. Diese Schnittstelle hat ''exklusiv'' diese Aufgabe. Bei der Auswahl der Appliances muss darauf geachtet werden, daß für das Hotwire-Netz jeweils eine Schnittstelle frei sein ist.


Für die Synchronisation der Konfiguration wird das SSH-Protokoll (TCP/22) verwendet. Das Connection-Tracking wird über den Port 3780 (UDP) abgeglichen. Ist eine Ethernet-Schnittstelle als Hotwire gekennzeichnet, werden die Regeln für die Kommunikation automatisch generiert. Für die SSH-Verbindung müssen öffentliche Schlüssel zwischen den Mitgliedern des UTM-Clusters ausgetauscht werden. Der Abgleich der Konfiguration kann in beide Richtungen zwischen den Mitgliedern des Clusters erfolgen. Das Connection-Tracking wird immer automatisch vom Master im Cluster zum Backup übertragen (Abb. 1.3).


[[Datei:UTM11_BP_Cluster_pic7.png|600px|Abb.: 1.3]]
{{Hinweis | !! Die Hotwire-Verbindung soll immer über eine direkte Kabelverbindung erfolgen (kein Switch etc. dazwischen). Stellen sie bitte sicher, dass niemand zu dem Zeitpunkt administrativ das Mitglied des Clusters verwendet, zu dem sie synchronisieren möchten.}}


----


{|style="background-color:#FFFFFF;border:2pt solid #FF0000;padding:5cm;"
==== Konfiguration abgleichen ====
|-
Über die Hotwire-Schnittstelle wird die Konfiguration synchronisiert. Änderungen, die auf einer Maschine im Cluster gemacht wurden, werden über diese Schnittstelle auf das andere Gerät übertragen. In der Regel wird die Konfiguration, nach der Inbetriebnahme des Clusters, allein auf einer UTM durchgeführt. Wir empfehlen den Master zu verwenden. '''Der Abgleich erfolgt immer manuell.''' Der Administrator entscheidet, wann er die Konfiguration im UTM-Cluster abgleichen möchte.
|[[Datei:UMA20_AHB_hinweispic.png|50px]]
|'''Achtung!'''<br>
Die Hotwire-Verbindung soll immer über eine direkte Kabelverbindung erfolgen (kein Switch etc. dazwischen). Stellen sie bitte sicher, dass niemand zu dem Zeitpunkt administrativ das Mitglied des Clusters verwendet, zu dem sie synchronisieren möchten.
|}


== Konfiguration abgleichen ==
Über die Hotwire-Schnittstelle wird die Konfiguration synchronisiert. Änderungen, die auf einer Maschine im Cluster gemacht wurden, werden über diese Schnittstelle auf das andere Gerät übertragen. In der Regel wird die Konfiguration, nach der Inbetriebnahme des Clusters, allein auf einer UTM durchgeführt. Wir empfehlen den Master zu verwenden. Der Abgleich erfolgt immer manuell. Der Administrator entscheidet, wann er die Konfiguration im UTM-Cluster abgleichen möchte.


Folgende Teile der Konfiguration werden '''nicht abgeglichen''':
#'''IP-Adressen die eindeutig zu einer Maschine gehören und die auf Ethernet- oder VLAN- Schnittstellen konfiguriert wurden.'''<br> Das sind die IP-Adressen, die im Webinterface unter dem Punkt {{Menu|Netzwerk |Netzwerkkonfiguration}} eingestellt werden. Wird ein Ethernet- oder VLAN-Schnittstelle neu erzeugt, wird dies zwar übertragen, jedoch nicht die Information über die IP-Adressen dieser Schnittstellen. Diese müssen bei Bedarf manuell auf dem Cluster-Mitglied konfiguriert werden, denn sie sind immer eindeutig einer UTM zugewiesen. Diese IP-Adressen sollen nicht mit virtuellen IP-Adressen auf einer HA-Schnittstelle verwechselt werden, die sich beide Maschinen im Cluster teilen.<br><br>
# '''Active Directory-Appliance-Account.'''<br> Dieser Account ist immer eindeutig im AD. Man erstellt unterschiedliche Namen auf beiden Maschinen und meldet jede separat am Active Directory an.


Folgende Teile der Konfiguration werden nicht abgeglichen:
{{ Hinweis| !! Es ist nicht zwingend notwendig, eindeutige IP-Adressen auf Schnittstellen zu konfigurieren, auf dem eine HA-Schnittstelle mit virtuellen IP-Adressen betrieben wird. Soll über diese Schnittstelle das Mitglied des UTM-Clusters eindeutig identifiziert werden, ist dies jedoch erforderlich. In dem Fall gelangt man über die virtuelle IP-Adresse auf die UTM, die in dem Augenblick der Master ist. | gelb |s=true }}
 
<br />
 
----
1. IP-Adressen die eindeutig zu einer Maschine gehören und die auf Ethernet- oder VLAN- Schnittstellen konfiguriert wurden. Das sind die IP-Adressen, die im Webinterface unter dem Punkt Netzwerk -> Netzwerkkonfiguration eingestellt werden. Wird ein Ethernet- oder VLAN-Schnittstelle neu erzeugt, wird dies zwar übertragen, jedoch nicht die Information über die IP-Adressen dieser Schnittstellen. Diese müssen bei Bedarf manuell auf dem Cluster-Mitglied konfiguriert werden, denn sie sind immer eindeutig einer UTM zugewiesen. Diese IP-Adressen sollen nicht mit virtuellen IP-Adressen auf einer HA-Schnittstelle verwechselt werden, die sich beide Maschinen im Cluster teilen.<br />
 
2. Active Directory-Appliance-Account. Dieser Account ist immer eindeutig im AD. Man erstellt unterschiedliche Namen auf beiden Maschinen und meldet jede separat am Active Directory an.<br />
 
 
{|style="background-color:#FFFFFF;border:2pt solid #FF0000;padding:5cm;"
|-
|[[Datei:UMA20_AHB_hinweispic.png|50px]]
|'''Achtung!'''<br>
Es ist nicht zwingend notwendig, eindeutige IP-Adressen auf Schnittstellen zu konfigurieren, auf dem eine HA-Schnittstelle mit virtuellen IP-Adressen betrieben wird. Soll über diese Schnittstelle das Mitglied des UTM-Clusters eindeutig identifiziert werden, ist dies jedoch erforderlich. In dem Fall gelangt man über die virtuelle IP-Adresse auf die UTM, die in dem Augenblick der Master ist.  
|}<br />


= Beispiel-Konfiguration: Externes DSL-Modem =
=== Beispiel-Konfiguration: Externes DSL-Modem ===
In diesem Beispiel wird eine Konfiguration aufgezeigt, mit der Sie einen UTM-Cluster an einer DSL-Leitung betreiben können. Die Einwahl erfolgt direkt durch die UTM.
In diesem Beispiel wird eine Konfiguration aufgezeigt, mit der Sie einen UTM-Cluster an einer DSL-Leitung betreiben können. Die Einwahl erfolgt direkt durch die UTM.


== Netzwerkkonfiguration:==
==== Netzwerkkonfiguration:====
 
'''Erstes Mitglied des Clusters (UTM 1)'''<br />
Interne IP-Adresse: 192.168.175.2/24<br>
Externe DSL Verbindung mittels PPPoE.<br>
Hotwire-IP-Adresse:192.168.180.2/24


'''Zweites Mitglied des Clusters (UTM 2)'''<br />
'''Erstes Mitglied des Clusters (UTM 1, Master)'''<br />
Interne IP-Adresse:192.168.175.3/24<br>
''eth0:'' Externe DSL Verbindung mittels PPPoE.<br>
Externe DSL Verbindung mittels PPPoE.<br>
''eth1:'' Interne IP-Adresse: 192.168.100.2/24<br>
Hotwire-IP-Adresse:192.168.180.3/24
''eth2:'' Hotwire-IP-Adresse:192.168.180.2/24


Als virtuelle IP-Adresse wird 192.168.175.1/24 definiert. <br />
'''Zweites Mitglied des Clusters (UTM 2, Spare)'''<br />
Diese IP-Adresse ist das Standard-Gateway des internen Netzwerks.
''eth0:'' Externe DSL Verbindung mittels PPPoE.<br>
''eth1:'' Interne IP-Adresse:192.168.100.3/24<br>
''eth2:'' Hotwire-IP-Adresse:192.168.180.3/24


Als virtuelle IP-Adresse wird 192.168.200.1/24 definiert. <br />
Diese IP-Adresse ist das Standard-Gateway des internen Netzwerks.<br>
{{Hinweis|! Bei Verwendung des DHCP-Servers, darf die Virtuelle IP-Adresse <u>nicht im gleichen Netz</u> wie die physische IP Adresse der Schnittstelle sein.}} Der DHCP-Server würde sich sonst beim Fallback auf die Physische Adresse der Spare-UTM schlüsseln und die Leases nicht synchronisieren.
----


== Inbetriebnahme der UTMs ==
==== Inbetriebnahme der UTMs ====
Zur Inbetriebnahme des UTM-Clusters wird zunächst der Installationsassistent verwendet. Um eine Doppeleinwahl zu unterbinden, soll das DSL-Modem nicht angeschlossen sein. Die Konfiguration der beiden UTMs unterscheidet sich bis zu diesem Zeitpunkt allein durch die interne und externe IP-Adresse. Im letzten Schritt des Installationsassistenten wird die Cluster-Lizenz ausgewählt. Nach Abschluss des Assistenten werden die UTMs neu gestartet.
Zur Inbetriebnahme des UTM-Clusters wird zunächst der Installationsassistent verwendet. Um eine Doppeleinwahl zu unterbinden, soll das DSL-Modem nicht angeschlossen sein. Die Konfiguration der beiden UTMs unterscheidet sich bis zu diesem Zeitpunkt allein durch die interne und externe IP-Adresse. Im letzten Schritt des Installationsassistenten wird die Cluster-Lizenz ausgewählt. Nach Abschluss des Assistenten werden die UTMs neu gestartet.
 
----
== Hotwire-Schnittstelle ==
==== Hotwire-Schnittstelle ====
Die UTMs werden nun physikalisch über die ausgewählte Hotwire-Schnittstelle verbunden. Diese muss auf den Maschinen den gleichen Port belegen - zum Beispiel LAN3/eth2.
Die UTMs werden nun physikalisch über die ausgewählte Hotwire-Schnittstelle verbunden. Diese muss auf den Maschinen den gleichen Port belegen - zum Beispiel LAN3/eth2.
----


== Cluster-Konfiguration ==
==== Cluster-Konfiguration ====
Die UTMs haben innerhalb des Clusters eine unterschiedliche Priorität. Die höhere Priorität hat der Master, die niedrigere das Backup-System. In unserem Beispiel wird die UTM mit der eindeutigen internen IP-Adresse 192.168.175.2 Master sein. Loggen sie sich auf diese über das Webinterface Maschine  ein.
{{Set_lang}}</div>
Die UTMs haben innerhalb des Clusters eine unterschiedliche Priorität. Die höhere Priorität hat der Master, die niedrigere das Backup-System. In unserem Beispiel wird die UTM mit der eindeutigen internen IP-Adresse 192.168.100.2 Master sein. Login über das Webinterface mit dieser IP und dem Port für Administration <small>(Default: 11115)</small>.


Öffnen sie nun den Netzwerk-Dialog, zu finden unter dem Menüpunkt Netzwerk -> Netzwerkkonfiguration. Dort fügen sie die IP-Adresse der zukünftigen Hotwire-Schnittstelle hinzu. In unserem Fall bekommt LAN3/eth2 die IP-Adresse 192.168.180.2/24.
{| class="sptable2 pd5"
|+ Cluster-Konfiguration
|-
! colspan="3" | {{h5| Master-UTM |Master-UTM}}
|-
| class="Leerzeile" colspan="3" | '''IP-Adresse der zukünftigen Hotwire-Schnittstelle'''<br>{{Menu|Netzwerk | Netzwerkkonfiguration}} {{ic|eth2}} → {{Button||w}} {{Reiter|IP-Adressen}}
|-
| {{b|IP-Adressen:}} || style="min-width: 165px" |{{ic|{{cb|192.168.180.2/24}} |pd=5px 5px 2em 5px|lh=2em}} || In der Clickbox wird die IP-Adresse der zukünftigen Hotwire-Schnittstelle hinzugefügt. <br>Im Beispiel bekommt LAN3/eth2 die IP-Adresse 192.168.180.2/24. || rowspan="1" class="bild" | {{bild|UTM v11.8.7 Cluster Schnittstelle1.png|hochkant=1.5|l=Abb.}}
|-
| class="hrzeile"|  {{hrzeile}}<br> Start des Cluster-Setup-Wizard unter {{Menu|Netzwerk|Clusterkonfiguration}} {{button|Cluster Assistent|+}}<br>'''Cluster Assistent Schritt 1'''
|-
| {{b| Hotwire Schnittstelle}} || {{Button|eth2: 192.168.180.2/24|dr}} || {{Hinweis|!|r}} Auf beiden Geräten muss die gleiche Schnitstelle gewählt werden! || rowspan="3" class="bild" | {{bild| UTM_v11.8.7_Cluster-Assistent_Schritt1.png | hochkant=1.5 | l=Abb.: 1.5}}
|-
| {{b| Lokale IP&#8209;Adresse: }} || {{ic| 192.168.180.2/24}} || IP-Adresse der Master-UTM
|-
| {{b| Remote IP&#8209;Adresse:}} ||  {{ic | 192.168.180.3 }} || IP-Adresse der Hotwire-Gegenstelle (Spare-UTM)
|-
| class="Leerzeile" colspan="3"| {{mobil|<hr>|<br>}}'''Cluster Assistent Schritt 2'''
|-
| {{ b| Schnittstelle: }} || {{Button|eth1|dr}} || Das zukünftige HA-Interface. Im Beispiel die interne Schnittstelle. || rowspan="3" class="bild" | {{bild|UTM_v11.8.7_Cluster-Assistent_Schritt2.png|hochkant=1.5 | l=Abb.: 1.6}}
|-
| {{b| Virtuelle IP&#8209;Adresse: }} || {{ic|192.168.200.1/24}} || Die virtuelle IP-Adresse soll 192.168.200.1 sein. Es können auf einer HA-Schnittstelle auch mehrere virtuelle IP-Adressen liegen.
|-
|colspan="3" | {{Hinweis | !|r}} Bei Verwendung der UTM als DHCP-Server dürfen diese IP-Adressen müssen nicht in der gleichen [http://de.wikipedia.org/wiki/Broadcast_Domain Broadcast Domain ] der anderen IP-Adressen liegen.{{hoover|{{spc|io|o|-}}|Der DHCP-Server würde sich sonst beim Fallback auf die Physische Adresse der Spare-UTM schlüsseln und die Leases nicht synchronisieren.}} <br>{{Hinweis|!|g}} Nachdem der Wizard durchlaufen wurde, können auch weitere HA-Schnittstellen konfiguriert werden.
|-
| class="Leerzeile" colspan="3"| {{mobil|<hr>|<br>}}'''Cluster Assistent Schritt 3''' || class="noborder" |
|-
| colspan="2" | {{b|Deaktivierte Schnittstellen während das Gerät im Backup Modus ist:}} <span style="float:inline-end;">{{ic| {{cb|wan0|-}}|pd=5px 5px 2em 5px|lh=2em }}</span>|| Schnittstellen, die auf dem Backup-System, der Spare-UTM, '''nicht''' hochgefahren werden. <br>Im Beispiel ''wan0'' (das DSL Interface). Die Einwahl soll nur durch die gerade aktive Master-UTM im Cluster erfolgen. {{hoover|{{spc|io|o|-}}|Dadurch ist es möglich, beide externen Interfaces der UTMs an das DSL Modem anzuschließen. Falls das Modem nur einen LAN Port besitzt, ist ein separater Switch zu verwenden.}} || rowspan="1" class="bild" | {{bild| UTM_v11.8.7_Cluster-Assistent_Schritt3.png|hochkant=1.5 | l=Abb.: 1.7}}
|-
| class="Leerzeile" colspan="3" | {{mobil|<hr>|<br>}}'''Cluster Assistent Schritt 4'''
|-
| colspan="2" | {{b|Deaktivierte Anwendungen während das Gerät im Backup Modus ist:}}{{ic| {{cb|Clientless VPN|-}} {{cb|DHCP Server|-}} {{cb|Greylisting Filter|-}} {{cb|HTTP Proxy|-}} {{cb|IPSEC|-}} {{cb|L2TP VPN|-}} {{cb|Mailrelay|-}} {{cb|POP3 Proxy|-}} {{cb|Routing Daemon|-}} {{cb|SPF Filter|-}} {{cb|SSL-VPN|-}} {{cb|Spamfilter|-}} {{cb|WLAN Server|-}} |pd=5px}}<small>'''Default'''</small>  || Per Default sind hier Anwendungen aufgeführt, die, sofern sich die Spare-UTM im Backup-Modus befindet, deaktiviert sein sollen || rowspan="1" class="bild" | {{bild| UTM_v11.8.7_Cluster-Assistent_Schritt4.png|hochkant=1.5 |l=Abb.: 1.8}}
|-
| class="Leerzeile" colspan="3" | {{mobil|<hr>|<br>}}'''Cluster Assistent Schritt 5'''
|-
| {{b|Priorität}} || {{Button|Hoch|dro}} || Die Master-UTM erhält die Priorität »hoch«. || rowspan="3" class="bild" | {{bild| UTM_v11.8.7_Cluster-Assistent_Schritt5.png|hochkant=1.5 |l=Abb.: 1.9}}
|-
| {{b|Passphrase: }} || {{ic|insecure}} || Die Passphrase für die Kommunikation der beiden UTMs auf den HA-Schnittstellen (VRR Protokoll)
|-
| class="hrzeile" colspan="3" | Cluster Assistent abschließen mit {{Button| Fertig }}
|-
| class="hrzeile"|  {{hrzeile}}<br>{{Menu|Netzwerk | Clusterkonfiguration}} {{Reiter|Schnittstellen}}
|-
| {{ic|eth1|bc=#EAE0E0;| c=#444444;}} || Schnittstelle benutzt für '''High Availability''' || Virtuelle IP 192.168.200.1/24<br>IP-Adresse: 192.168.100.2/24 || rowspan="5" class="bild" | {{bild|UTM_v11.8.7_Cluster_Konfig.png|hochkant=1.5|l=Abb.: 1.10}}
|-
| {{ic|eth2|bc=#EAE0E0;| c=#444444;}} || Schnittstelle wird benutzt als '''Hotwire''' || IP-Adresse 192.168.180.2/24
|-
| {{ic|wan0|bc=#EAE0E0;| c=#444444;}} || Schnittstelle ist '''beim Backup deaktiviert''' ||
|-
| {{b|Clusterstatus:}} || <span style="color:{{Farbe|#515151;}}">⬤</span> ||  Der Clusterstatus zeigt noch keinen Zustand an, weil der Cluster noch nicht auf aktiv geschaltet ist.
|-
| {{b|Synchronisationsstatus:}} || <span style="color:{{Farbe|#DD463E;}}">⬤</span> || Der Synchronisationsstatus steht auf rot, weil die Gegenstelle nicht erreichbar ist.
|-
| class="Leerzeile" colspan="3"| {{mobil|<hr>|<br>}}<br>{{Menu|Netzwerk | Clusterkonfiguration}} {{Reiter|Einstelungen}}
|-
| rowspan="2" | {{b|Lokaler SSH&#8209;Schlüssel:}} || {{Button | Neuen lokalen SSH-Schlüssel generieren}} || Im Reiter {{ Reiter | Einstellungen}} wird ein SSH Public Key erzeugt. || rowspan="2" class="bild" | {{bild| UTM_v11.8.7_Netzwerk_Cluster-Config_Einstellungen.png | hochkant=1.5 | l=Abb.: 1.11}}
|-
| {{ic| <nowiki>ssh-rsa</nowiki><br><nowiki>AAAAB3Nz […] zE0SU=</nowiki><br>''<nowiki>root@master.cluster.local</nowiki>''}} || SSH-Schlüssel in die Zwischenablage kopieren
|-
| class="Leerzeile noborder" colspan="4"| <hr>
|-
! colspan="3"| {{h5|Spare-UTM | Spare UTM}} </td><td class="noborder" style="border-top: 0;">
|-
| colspan="3" class="Leerzeile" | <br>Login über die IP-Adresse 192.168.180.3 auf das Web-Interface der Spare-UTM.<br>{{Menu| Netzwerk| Clusterkonfiguration}} {{Reiter|Schnittstellen}}
|-
| {{b|Name:}} || eth2 || {{ic|eth2}} {{b| |w}} Schnittstelle bearbeiten || rowspan="4" class="bild" | {{bild|UTM_v11.8.7_Netzwerk_Cluster-Config_UTM2_eth2.png|hochkant=1.5 |l=Abb.: 1.12}}
|-
| {{b|Verwendung:}} || {{ button|Schnittstelle als Hotwire benutzen|dr}} || Die Schnittstelle eth2 der Spare-UTM wird als Hotwire gekennzeichnet.
|-
| {{b| Lokale IP-Adresse: }} || {{ic|192.168.180.3/24}} || IP-Adresse der Spare-UTM, die für Hotwire verwendet werden soll.
|-
| {{b| Remote IP-Adresse: }} || {{ic|192.168.180.2}} || IP-Adresse der bereits konfigurierten Master-UTM, die als Hotwire angesprochen werden soll.
|-
| class="Leerzeile noborder" colspan="4"| {{mobil|<hr>|<br>}}{{Menu | Netzwerk |Clusterkonfiguration}} {{Reiter| Einstellungen}}
|-
| rowspan="2" | {{b|Lokaler SSH&#8209;Schlüssel:}} || {{Button | Neuen lokalen SSH-Schlüssel generieren}} || SSH Public Key für die ''Spare-UTM'' erzeugen || rowspan="4" class="bild" | {{bild| UTM_v11.8.7_Netzwerk_Cluster-Config_Einstellungen-Spare.png | hochkant=1.5 | l=Abb.: 1.13}}
|-
| {{ic| <nowiki>ssh-rsa</nowiki><br><nowiki>AAAAB3Nz […] Q1/k=</nowiki><br>''<nowiki>root@spare.cluster.local</nowiki>''}} || SSH-Schlüssel '''noch nicht''' in die Zwischenablage kopieren
|-
| {{b| SSH&#8209;Schlüssel der Gegenstelle: }} || {{ic| <nowiki>ssh-rsa</nowiki><br><nowiki>AAAAB3Nz […] zE0SU=</nowiki><br>''<nowiki>root@master.cluster.local</nowiki>''}} || Public-SSH-Key der ''Master-UTM'' aus der Zwischenablage einfügen
|-
| {{b|Lokaler SSH&#8209;Schlüssel:}} || colspan="2" | '''Jetzt''' den lokalen Public-SSh-Key der Spare-UTM in die Zwischenablage einfügen.<br>Wechsel auf die ''Master-UTM'' und dort einfügen unter {{b| SSH&#8209;Schlüssel der Gegenstelle: }} (Auf der ''Master-UTM'' ist entspicht die ''Spare-UMT'' der Gegenstelle)
|-
| colspan="3" class="Leerzeile" | {{mobil|<hr>}}Auf beiden Seiten sollte sich nun ein lokaler SSH Schlüssel und jeweils der SSH Schlüssel der Gegenstelle gefinden. Speichern der Einstellungen auf beiden UTMs in diesem Dialog durch Betätigung der {{Button|Speichern}} Schaltfläche.
|-
| {{b|Synchronisationsstatus}} ||<span style="color:{{Farbe|#E9C321;}}">⬤</span> ||colspan="2" |  Der Synchronisationsstatus sollte nun von rot zu orange wechseln. Das bedeutet, die beiden UTMs sehen sich über die Hotwire-Schnittstelle, jedoch ist die Konfiguration noch nicht synchronisiert. <br>{{Hinweis|!|g}} Der Status wird {{f|in bestimmten Intervallen§nämlich welchen?}} aktualisiert. In dem Reiter {{Reiter |Schnittstellen}} kann die Aktualisierung mit der Synchronisieren-Schaltfläche {{button||refresh}} manuell ausgelöst werden.
|-
| class="Leerzeile" colspan="3"| {{button|Konfiguration synchronisieren}}
|-
| {{b|Synchronisationsstatus}} || <span style="color:{{Farbe|#3EAB30;}}">⬤</span>||colspan="2" |  Wenn die Synchronisation erfolgreich abgeschlossen wurde, steht jetzt der Synchronisationsstatus auf grün. Die beiden UTMs sind abgeglichen.<br>Dieser Vorgang kann überprüft werden, indem auf der Spare-UTM eine Konfiguration aufgerufen wird, die im Master verändert wurde.<br>
Die Cluster {{b|Priorität}} {{Menu|Netzwerk|Clusterkonfiguration}} {{Reiter|einstellungen}} der Spare-UTM (Backup) wurde automatisch auf niedrig gestellt.<br>
{{Hinweis|!|g}} Würde die Priorität auf der jetzigen Spare-UTM auf hoch gestellt und von da aus auch die Konfiguration synchronisiert werden, würde die erste Maschine automatisch zum Spare degradiert und die vormals Spare-UTM zum Master.
|-
| class="Leerzeile" colspan="3" | {{mobil|<hr>}}<br>'''Cluster aktivieren'''<br>{{Menu|Netzwerk | Clusterkonfiguration}} {{Reiter|Einstelungen}}
|-
| colspan="3" | Externe Interfaces an das DSL-Modem anschließen || class="bild" rowspan="4" | {{bild|UTM11_BP_Cluster_pic20.png|hochkant=1.5|Abb.: 1.14}}
|-
| {{b|Cluster:}} || {{ButtonAn|Ein}} ||
Dieser Schritt muss auf '''beiden UTMs''' ausgeführt werden.
|-
| rowspan="2" | {{b| Clusterstatus }} || Auf der Master-UTM: <span style="color:{{Farbe|#3EAB30;}}">⬤</span> || Der Cluster ist nun in Betrieb und der Master des Clusters hat unsere virtuelle IP-Adresse 192.168.200.1 auf dem internen Interface.
|-
| Auf der Spare-UTM: <span style="color:{{Farbe|#E9C321;}}">⬤</span> || Die Spare-UTM läuft als Hot-Standby im Backup-Modus im Hintergrund
|}




[[Datei:UTM11_BP_Cluster_pic10.png|600px|Abb.: 1.4]]
Sollte der Status nicht sofort aktualisiert werden, kann das auch hier wieder über die Schaltfläche zum Aktualisieren manuell ausgelöst werden.


----


=== Beispiel Konfiguration: Externer Router ===
In diesem Beispiel wird eine Konfiguration mit einem externen Router beschrieben. Der Router ist das Gateway zum Internet. Eventuell wurde vom Provider ein öffentliches Netz zur Verfügung gestellt. In diesem Beispiel wird ein privates Netz verwendet. Die Vorgehensweise ist dann analog zum öffentlichen Netz. Hier werden nun zwei HA-Schnittstellen konfiguriert. Eine für die interne und eine für die externe Schnittstelle.


Im nächsten Schritt öffnen Sie den Cluster-Dialog (Netzwerk -> Clusterkonfiguration) und starten sie den Cluster-Setup-Wizard, wählen die Hotwire-Schnittstelle aus und geben die IP-Adresse der Hotwire-Gegenstelle an.


==== Netzwerkkonfiguration: ====


[[Datei:UTM11_BP_Cluster_pic11.png|600px|Abb.: 1.5]]
'''Erstes Mitglied des Clusters (UTM 1, Master)'''<br />
''eth0:'' Externe IP Adresse (zom Router) 192.168.175.102/24<br>
''eth1:'' Interne IP-Adresse: 192.168.100.2/24<br>
''eth2:'' Hotwire-IP-Adresse:192.168.180.2/24


'''Zweites Mitglied des Clusters (UTM 2, Spare)'''<br />
''eth0:'' Externe IP Adresse (zom Router) 192.168.175.103/24<br>
''eth1:'' Interne IP-Adresse:192.168.100.3/24<br>
''eth2:'' Hotwire-IP-Adresse:192.168.180.3/24


In "Step 2" des Wizards wählen sie das zukünftige HA-Interface aus. In unserem Fall ist das die interne Schnittstelle. Die virtuelle IP-Adresse soll 192.168.175.1 sein. Sie können auf eine HA-Schnittstelle auch mehrere virtuelle IP-Adressen setzen. Diese IP-Adressen müssen nicht in der gleichen Broadcast Domain<ref name="ftn2">[http://de.wikipedia.org/wiki/Broadcast_Domain http://de.wikipedia.org/wiki/Broadcast_Domain]</ref> der anderen IP-Adressen liegen. Nachdem sie den Wizard durchlaufen haben, können auch weitere HA-Schnittstellen konfiguriert werden.
Die virtuellen IP-Adressen, die sich beide Mitglieder des Clusters teilen werden, sind die IP-Adressen 192.168.200.1/24 für die internen Schnittstellen und 192.168.175.103/24 für die extern Schnittstellen (zum Router).<br>
Die virtuelle IP-Adresse 192.168.200.1 ist das Standard-Gateway des internen Netzwerks.


----


[[Datei:UTM11_BP_Cluster_pic12.png|600px|Abb.: 1.6]]
==== Inbetriebnahme der UTMs ====
Zur Inbetriebnahme des UTM-Clusters wird zunächst der Installationsassistent verwendet. Diese Einrichtung wird auf jeder UTM separat durchgeführt. Die Konfiguration der beiden UTMs unterscheidet sich bis zu diesem Zeitpunkt allein durch die interne und externe IP-Adresse. Im letzten Schritt des Installationsassistenten wird die Cluster-Lizenz ausgewählt. Nach Abschluss des Assistenten werden die UTMs neu gestartet.
----
==== Hotwire-Schnittstelle ====
Die UTMs werden nun physikalisch über die Hotwire-Schnittstelle verbunden. Diese muss auf den Maschinen den gleiche Port belegen, zum Beispiel LAN3/eth2.
----
==== Cluster Konfiguration ====




Im "Step 3" des Wizards werden die Schnittstellen definiert, die auf dem Backup-System (auch Spare genannt) nicht hochgefahren werden. In unserer Konfiguration wollen wir das nicht für ppp0 (DSL Interface). Die Einwahl soll nur durch die gerade aktive UTM im Cluster (Master) erfolgen. So ist es Ihnen möglich, beide externen Interfaces der UTM an das DSL Modem anzuschließen. Falls ihr Modem nur einen LAN Port besitzt, verwenden sie einen separaten Switch.
{| class="sptable2 pd5"
 
|+ Cluster-Konfiguration
 
|-
[[Datei:UTM11_BP_Cluster_pic13.png|600px|Abb.: 1.7]]
! colspan="3" | {{h5| Master-UTM |Master-UTM}}
 
|-
 
| class="Leerzeile" colspan="3" | '''IP-Adresse der zukünftigen Hotwire-Schnittstelle'''<br>{{Menu|Netzwerk | Netzwerkkonfiguration}} {{ic|eth2}} → {{Button||w}} {{Reiter|IP-Adressen}}
Im nächsten Schritt können sie Applikationen definieren, die auf dem Backup System nicht aktiv sein sollen. Das Verhalten entspricht dem "Step 3". Wir wählen hier die Applikation DHCP Server aus, falls die UTM auch als DHCP Server agieren soll, also den Clients im internen Netz IP-Adressen vergeben soll. Falls sie eine UTM verwenden, die auch als Access Point dient, deaktivieren sie hier auch die Applikation WLAN-Server.
|-
 
| {{b|IP-Adressen:}} || style="min-width: 165px" |{{ic|{{cb|192.168.180.2/24}} |pd=5px 5px 2em 5px|lh=2em}} || In der Clickbox wird die IP-Adresse der zukünftigen Hotwire-Schnittstelle hinzugefügt. <br>Im Beispiel bekommt LAN3/eth2 die IP-Adresse 192.168.180.2/24. || rowspan="1" class="bild" | {{bild|UTM v11.8.7 Cluster Schnittstelle1.png|hochkant=1.5|l=Abb.}}
 
|-
[[Datei:UTM11_BP_Cluster_pic14.png|600px|Abb.: 1.8]]
| class="hrzeile"|  {{hrzeile}}<br> Start des Cluster-Setup-Wizard unter {{Menu|Netzwerk|Clusterkonfiguration}} {{button|Cluster Assistent|+}}<br>'''Cluster Assistent Schritt 1'''
 
|-
 
| {{b| Hotwire Schnittstelle}} || {{Button|eth2: 192.168.180.2/24|dr}} || {{Hinweis|!|r}} Auf beiden Geräten muss die gleiche Schnitstelle gewählt werden! || rowspan="3" class="bild" | {{bild| UTM_v11.8.7_Cluster-Assistent_Schritt1.png | hochkant=1.5 | l=Abb.: 1.5}}
Im letzten Schritt des Wizards legen sie die Passphrase für die Kommunikation der beiden UTMs auf den HA-Schnittstellen fest (VRR Protokoll) und die Priorität der aktuellen Appliance. Wir möchten, dass diese UTM die höhere Priorität hat, also im Regelfall Master ist.
|-
 
| {{b| Lokale IP&#8209;Adresse: }} || {{ic| 192.168.180.2/24}} || IP-Adresse der Master-UTM
 
|-
[[Datei:UTM11_BP_Cluster_pic15.png|600px|Abb.: 1.9]]
| {{b| Remote IP&#8209;Adresse:}} ||  {{ic | 192.168.180.3 }} || IP-Adresse der Hotwire-Gegenstelle (Spare-UTM)
 
|-
 
| class="Leerzeile" colspan="3"| {{mobil|<hr>|<br>}}'''Cluster Assistent Schritt 2'''
Die Konfiguration sieht nun wie folgt aus. Der Clusterstatus zeigt noch keinen Zustand an, weil der Cluster noch nicht auf aktiv geschaltet ist. Der Synchronisationsstatus steht auf rot, weil die Gegenstelle nicht erreichbar ist.
|-
 
| {{ b| Schnittstelle: }} || {{Button|eth1|dr}} || Das zukünftige HA-Interface. Im Beispiel die interne Schnittstelle. || rowspan="3" class="bild" | {{bild|UTM_v11.8.7_Cluster-Assistent_Schritt2.png|hochkant=1.5 | l=Abb.: 1.6}}
 
|-
[[Datei:UTM11_BP_Cluster_pic16.png|600px|Abb.: 1.10]]
| {{b| Virtuelle IP&#8209;Adresse: }} || {{ic|192.168.200.1/24}} || Die virtuelle IP-Adresse soll 192.168.200.1 sein. Es können auf einer HA-Schnittstelle auch mehrere virtuelle IP-Adressen liegen.
 
|-
 
|colspan="3" | {{Hinweis | !|r}} Bei Verwendung der UTM als DHCP-Server dürfen diese IP-Adressen müssen nicht in der gleichen [http://de.wikipedia.org/wiki/Broadcast_Domain Broadcast Domain ] der anderen IP-Adressen liegen.{{hoover|{{spc|io|o|-}}|Der DHCP-Server würde sich sonst beim Fallback auf die Physische Adresse der Spare-UTM schlüsseln und die Leases nicht synchronisieren.}} <br>{{Hinweis|!|g}} Nachdem der Wizard durchlaufen wurde, können auch weitere HA-Schnittstellen konfiguriert werden.
Unter dem Punkt Einstellungen erzeugen sie nun einen SSH Public Key und kopieren ihn in die Zwischenablage.
|-
 
| class="Leerzeile" colspan="3"| {{mobil|<hr>|<br>}}'''Cluster Assistent Schritt 3''' || class="noborder" |
 
|-
[[Datei:UTM11_BP_Cluster_pic17.png|600px|Abb.: 1.11]]
| colspan="2" | {{b|Deaktivierte Schnittstellen während das Gerät im Backup Modus ist:}} <span style="float:inline-end;">{{ic| {{cb|wan0|-}}|pd=5px 5px 2em 5px|lh=2em }}</span>|| Schnittstellen, die auf dem Backup-System, der Spare-UTM, '''nicht''' hochgefahren werden. <!--********-->In dieser Konfiguration ist das '''nicht erforderlich''' || rowspan="1" class="bild" | {{bild| UTM_v11.8.7_Cluster-Assistent_Schritt3b.png|hochkant=1.5 | l=Abb.: 1.7}}
 
|-
 
| class="Leerzeile" colspan="3" | {{mobil|<hr>|<br>}}'''Cluster Assistent Schritt 4'''
Nun wird es Zeit, die zweite UTM im Cluster zu konfigurieren. Loggen sie sich über die IP-Adresse 192.168.175.3 auf das Web-Interface ein. Öffnen Sie den Dialog Clusterkonfiguration und bearbeiten Sie die Schnittstelle eth2, um Sie als Hotwire zu kennzeichnen. Geben sie in dem Dialog als lokale IP-Adresse 192.168.180.3/24 und als Gegenstelle die bereits konfigurierte UTM mit der IP-Adresse 192.168.180.2 ein.
|-
 
| colspan="2" | {{b|Deaktivierte Anwendungen während das Gerät im Backup Modus ist:}}{{ic| {{cb|Clientless VPN|-}} {{cb|DHCP Server|-}} {{cb|Greylisting Filter|-}} {{cb|HTTP Proxy|-}} {{cb|IPSEC|-}} {{cb|L2TP VPN|-}} {{cb|Mailrelay|-}} {{cb|POP3 Proxy|-}} {{cb|Routing Daemon|-}} {{cb|SPF Filter|-}} {{cb|SSL-VPN|-}} {{cb|Spamfilter|-}} {{cb|WLAN Server|-}} |pd=5px}}<small>'''Default'''</small>  || Per Default sind hier Anwendungen aufgeführt, die, sofern sich die Spare-UTM im Backup-Modus befindet, deaktiviert sein sollen || rowspan="1" class="bild" | {{bild| UTM_v11.8.7_Cluster-Assistent_Schritt4.png|hochkant=1.5 |l=Abb.: 1.8}}
 
|-
[[Datei:UTM11_BP_Cluster_pic18.png|600px|Abb.: 1.12]]
| class="Leerzeile" colspan="3" | {{mobil|<hr>|<br>}}'''Cluster Assistent Schritt 5'''
 
|-
 
| {{b|Priorität}} || {{Button|Hoch|dro}} || Die Master-UTM erhält die Priorität »hoch«. || rowspan="3" class="bild" | {{bild| UTM_v11.8.7_Cluster-Assistent_Schritt5.png|hochkant=1.5 |l=Abb.: 1.9}}
Wechseln sie danach in den Dialog Clusterkonfiguration -> Einstellungen und generieren dort ebenfalls einen SSH Key. Kopieren sie den SSH Key von der ersten UTM aus der Zwischenablage in das Feld „SSH-Schlüssel der Gegenstelle“. Wechseln sie auf die erste UTM und kopieren sie den SSH Key der zweiten UTM in das Feld „SSH-Schlüssel der Gegenstelle“. Auf beiden Seiten sollte sich nun ein lokaler SSH Schlüssel und jeweils der SSH Schlüssel der Gegenstelle gefinden. Speichern sie die Einstellungen auf beiden UTMs in diesem Dialog durch Betätigung der „Speichern“ Schaltfläche. Der Synchronisationsstatus sollte nun von rot zu orange wechseln. Das bedeutet, die beiden UTMs sehen sich über die Hotwire-Schnittstelle, jedoch ist die Konfiguration noch nicht synchronisiert.
|-
 
| {{b|Passphrase: }} || {{ic|insecure}} || Die Passphrase für die Kommunikation der beiden UTMs auf den HA-Schnittstellen (VRR Protokoll)
Beachten Sie bitte, dass der Status in bestimmten Intervallen aktualisiert wird. Wenn Sie in dem Dialog „Schnittstellen“ die Aktualisierungs-Schaltfläche betätigen, können Sie den Vorgang beschleunigen.
|-
 
| class="hrzeile" colspan="3" | Cluster Assistent abschließen mit {{Button| Fertig }}
 
|-
[[Datei:UTM11_BP_Cluster_pic19.png|600px|Abb.: 1.13]]
| class="hrzeile"|  {{hrzeile}}<br>{{Menu|Netzwerk | Clusterkonfiguration}} {{Reiter|Schnittstellen}}
 
|-
 
| {{ic|eth1|bc=#EAE0E0;| c=#444444;}} || Schnittstelle benutzt für '''High Availability''' || Virtuelle IP 192.168.200.1/24<br>IP-Adresse: 192.168.100.2/24 || rowspan="5" class="bild" | {{bild|UTM_v11.8.7_Cluster_Konfig-exr.png|hochkant=1.5|l=Abb.: 1.10}}
Loggen Sie sich nun aus dem aus der zweiten Maschine aus und wechseln Sie wieder in das Webinterface der ersten UTM, unserem Master. Betätigen Sie nun den Button "Konfiguration synchronisieren" zum ersten Mal. Wenn die Synchronisation erfolgreich abgeschlossen wurde, steht jetzt der Synchronisationsstatus auf grün. Die beiden UTMs sind abgeglichen. Alles was Sie auf dem Master bereits konfiguriert haben, befindet sich jetzt auch auf der Backup-Maschine. Sie können dies überprüfen, indem Sie sich auf der Backup-Maschine einloggen und die entsprechenden Dialoge öffnen. Da wir von der von uns definierten Master-UTM die Synchronisation durchgeführt haben, wird die Cluster Priorität der zweiten Maschine (Backup) automatisch auf niedrig gestellt.
|-
 
| {{ic|eth2|bc=#EAE0E0;| c=#444444;}} || Schnittstelle wird benutzt als '''Hotwire''' || IP-Adresse 192.168.180.2/24
 
|-
Würden Sie die Priorität auf der jetzigen Backup-UTM auf hoch stellen und von da aus auch die Konfiguration synchronisieren, würde die erste Maschine automatisch zum Backup degradiert und die vormals Backup-UTM zum Master.
| {{ic|wan0|bc=#EAE0E0;| c=#444444;}} || Schnittstelle ist '''beim Backup deaktiviert''' ||
 
|-
 
| {{b|Clusterstatus:}} || <span style="color:{{Farbe|#515151;}}">⬤</span> ||  Der Clusterstatus zeigt noch keinen Zustand an, weil der Cluster noch nicht auf aktiv geschaltet ist.
Im letzen Schritt aktivieren Sie den Cluster. Schliessen Sie die externen Interfaces an das DSL-Modem an. Im Dialog Clusterkonfiguration, wechseln Sie auf den Punkt Einstellungen und aktivieren Sie den Cluster. Dieser Schritt muss auf beiden UTMs getrennt ausgeführt werden. Ihr Cluster ist nun in Betrieb und der Master des Clusters hat unsere virtuelle IP-Adresse 192.168.175.1 auf dem internen Interface.
|-
 
| {{b|Synchronisationsstatus:}} || <span style="color:{{Farbe|#DD463E;}}">⬤</span> || Der Synchronisationsstatus steht auf rot, weil die Gegenstelle nicht erreichbar ist.
 
|-
[[Datei:UTM11_BP_Cluster_pic20.png|600px|Abb.: 1.14]]
| class="Leerzeile" colspan="3"| {{mobil|<hr>|<br>}}<br>{{Menu|Netzwerk | Clusterkonfiguration}} {{Reiter|Einstelungen}}
 
|-
 
| rowspan="2" | {{b|Lokaler SSH&#8209;Schlüssel:}} || {{Button | Neuen lokalen SSH-Schlüssel generieren}} || Im Reiter {{ Reiter | Einstellungen}} wird ein SSH Public Key erzeugt. || rowspan="2" class="bild" | {{bild| UTM_v11.8.7_Netzwerk_Cluster-Config_Einstellungen.png | hochkant=1.5 | l=Abb.: 1.11}}
Sollte der Status nicht sofort aktualisiert werden, können Sie auch hier wieder die Schaltfläche zum Aktualisieren drücken.
|-
 
| {{ic| <nowiki>ssh-rsa</nowiki><br><nowiki>AAAAB3Nz […] zE0SU=</nowiki><br>''<nowiki>root@master.cluster.local</nowiki>''}} || SSH-Schlüssel in die Zwischenablage kopieren
= Beispiel Konfiguration: Externer Router =
|-
In diesem Beispiel wird eine Konfiguration mit einem externen Router beschrieben. Der Router ist das Gateway zum Internet. Eventuell wurde von Provider ein öffentliches Netz zur Verfügung gestellt. In diesem Beispiel wird ein privates Netz verwendet. Die Vorgehensweise ist dann analog zum öffentlichen Netz. Hier werden nun zwei HA-Schnittstellen konfiguriert. Eine für die interne und eine für die externe Schnittstelle.
| class="Leerzeile noborder" colspan="4"| <hr>
 
|-
 
! colspan="3"| {{h5|Spare-UTM | Spare UTM}} </td><td class="noborder" style="border-top: 0;">
Netzwerkkonfiguration:
|-
 
| colspan="3" class="Leerzeile" | <br>Login über die IP-Adresse 192.168.180.3 auf das Web-Interface der Spare-UTM.<br>{{Menu| Netzwerk| Clusterkonfiguration}} {{Reiter|Schnittstellen}}
 
|-
== Erstes Mitglied des Clusters UTM 1: ==
| {{b|Name:}} || eth2 || {{ic|eth2}} {{b| |w}} Schnittstelle bearbeiten || rowspan="4" class="bild" | {{bild|UTM_v11.8.7_Netzwerk_Cluster-Config_UTM2_eth2.png|hochkant=1.5 |l=Abb.: 1.12}}
Interne IP-Adresse:192.168.175.2/24
|-
 
| {{b|Verwendung:}} || {{ button|Schnittstelle als Hotwire benutzen|dr}} || Die Schnittstelle eth2 der Spare-UTM wird als Hotwire gekennzeichnet.
Externe IP-Adresse:172.16.0.105/24
|-
 
| {{b| Lokale IP-Adresse: }} || {{ic|192.168.180.3/24}} || IP-Adresse der Spare-UTM, die für Hotwire verwendet werden soll.
Hotwire IP-Adresse:192.168.180.2/24
|-
 
| {{b| Remote IP-Adresse: }} || {{ic|192.168.180.2}} || IP-Adresse der bereits konfigurierten Master-UTM, die als Hotwire angesprochen werden soll.
 
|-
== Zweites Mitglied des Clusters UTM 2: ==
| class="Leerzeile noborder" colspan="4"| {{mobil|<hr>|<br>}}{{Menu | Netzwerk |Clusterkonfiguration}} {{Reiter| Einstellungen}}
Interne IP-Adresse: 192.168.175.3/24
|-
 
| rowspan="2" | {{b|Lokaler SSH&#8209;Schlüssel:}} || {{Button | Neuen lokalen SSH-Schlüssel generieren}} || SSH Public Key für die ''Spare-UTM'' erzeugen || rowspan="4" class="bild" | {{bild| UTM_v11.8.7_Netzwerk_Cluster-Config_Einstellungen-Spare.png | hochkant=1.5 | l=Abb.: 1.13}}
Externe IP-Adresse:172.16.0.106/24
|-
 
| {{ic| <nowiki>ssh-rsa</nowiki><br><nowiki>AAAAB3Nz […] Q1/k=</nowiki><br>''<nowiki>root@spare.cluster.local</nowiki>''}} || SSH-Schlüssel '''noch nicht''' in die Zwischenablage kopieren
Hotwire IP-Adresse:192.168.180.3/24
|-
 
| {{b| SSH&#8209;Schlüssel der Gegenstelle: }} || {{ic| <nowiki>ssh-rsa</nowiki><br><nowiki>AAAAB3Nz […] zE0SU=</nowiki><br>''<nowiki>root@master.cluster.local</nowiki>''}} || Public-SSH-Key der ''Master-UTM'' aus der Zwischenablage einfügen
 
|-
Die virtuellen IP-Adressen, die sich beide Mitglieder des Clusters teilen werden, sind die IP-Adressen 192.168.175.1/24 für intern und 172.16.0.107/24 für extern. Die IP-Adresse 192.168.175.1 ist das Standard-Gateway des internen Netzwerks.
| {{b|Lokaler SSH&#8209;Schlüssel:}} || colspan="2" | '''Jetzt''' den lokalen Public-SSh-Key der Spare-UTM in die Zwischenablage einfügen.<br>Wechsel auf die ''Master-UTM'' und dort einfügen unter {{b| SSH&#8209;Schlüssel der Gegenstelle: }} (Auf der ''Master-UTM'' ist entspicht die ''Spare-UMT'' der Gegenstelle)
 
|-
== Inbetriebnahme der UTMs ==
| colspan="3" class="Leerzeile" | {{mobil|<hr>}}Auf beiden Seiten sollte sich nun ein lokaler SSH Schlüssel und jeweils der SSH Schlüssel der Gegenstelle gefinden. Speichern der Einstellungen auf beiden UTMs in diesem Dialog durch Betätigung der {{Button|Speichern}} Schaltfläche.
Zur Inbetriebnahme des UTM-Clusters wird zunächst der  Installationsassistent verwendet. Diese Einrichtung wird auf jeder UTM separat durchgeführt. Die Konfiguration der beiden UTMs unterscheidet sich bis zu diesem Zeitpunkt allein durch die interne und externe IP-Adresse. Im letzten Schritt des Installationsassistenten wird die Cluster-Lizenz ausgewählt. Nach Abschluss des Assistenten werden die UTMs neu gestartet.
|-
 
| {{b|Synchronisationsstatus}} ||<span style="color:{{Farbe|#E9C321;}}">⬤</span> ||colspan="2" |  Der Synchronisationsstatus sollte nun von rot zu orange wechseln. Das bedeutet, die beiden UTMs sehen sich über die Hotwire-Schnittstelle, jedoch ist die Konfiguration noch nicht synchronisiert. <br>{{Hinweis|!|g}} Der Status wird {{f|in bestimmten Intervallen§nämlich welchen?}} aktualisiert. In dem Reiter {{Reiter |Schnittstellen}} kann die Aktualisierung mit der Synchronisieren-Schaltfläche {{button||refresh}} manuell ausgelöst werden.
== Hotwire-Schnittstelle ==
|-
Die UTMs werden nun physikalisch über die Hotwire-Schnittstelle verbunden. Diese muss auf den Maschinen den gleiche Port belegen, zum Beispiel LAN3/eth2.
| class="Leerzeile" colspan="3"| {{button|Konfiguration synchronisieren}}
 
|-
== Cluster Konfiguration ==
| {{b|Synchronisationsstatus}} || <span style="color:{{Farbe|#3EAB30;}}">⬤</span>||colspan="2" |  Wenn die Synchronisation erfolgreich abgeschlossen wurde, steht jetzt der Synchronisationsstatus auf grün. Die beiden UTMs sind abgeglichen.<br>Dieser Vorgang kann überprüft werden, indem auf der Spare-UTM eine Konfiguration aufgerufen wird, die im Master verändert wurde.<br>
Die UTMs haben innerhalb des Clusters eine unterschiedliche Priorität. Die höhere Priorität hat der Master, die niedrigere das Backup-System. Die UTM mit der eindeutigen internen IP-Adresse 192.168.175.2 ist Master. Im Webinterface unter Netzwerk -> Netzwerkkonfiguration wird die IP-Adresse des zukünftigen Hotwire-Interfaces hinzugefügt. In diesem Fall erhält LAN3/eth2 die IP-Adresse 192.168.180.2/24.
Die Cluster {{b|Priorität}} {{Menu|Netzwerk|Clusterkonfiguration}} {{Reiter|einstellungen}} der Spare-UTM (Backup) wurde automatisch auf niedrig gestellt.<br>
{{Hinweis|!|g}} Würde die Priorität auf der jetzigen Spare-UTM auf hoch gestellt und von da aus auch die Konfiguration synchronisiert werden, würde die erste Maschine automatisch zum Spare degradiert und die vormals Spare-UTM zum Master.
|-
| class="Leerzeile" colspan="3" | {{mobil|<hr>}}<br>'''Cluster aktivieren'''<br>{{Menu|Netzwerk | Clusterkonfiguration}} {{Reiter|Einstelungen}}
|-
| colspan="3" | Externe Interfaces an das DSL-Modem anschließen || class="bild" rowspan="4" | {{bild|UTM11_BP_Cluster_pic20.png|hochkant=1.5|Abb.: 1.14}}
|-
| {{b|Cluster:}} || {{ButtonAn|Ein}} ||
Dieser Schritt muss auf '''beiden UTMs''' ausgeführt werden.
|-
| rowspan="2" | {{b| Clusterstatus }} || Auf der Master-UTM: <span style="color:{{Farbe|#3EAB30;}}">⬤</span> || Der Cluster ist nun in Betrieb und der Master des Clusters hat unsere virtuelle IP-Adresse 192.168.200.1 auf dem internen Interface.
|-
| Auf der Spare-UTM: <span style="color:{{Farbe|#E9C321;}}">⬤</span> || Die Spare-UTM läuft als Hot-Standby im Backup-Modus im Hintergrund
|}
----
----
Die UTMs haben innerhalb des Clusters eine unterschiedliche Priorität. Die höhere Priorität hat der Master, die niedrigere das Backup-System. Die UTM mit der eindeutigen internen IP-Adresse 192.168.100.2 ist Master. Im Webinterface unter Netzwerk -> Netzwerkkonfiguration wird die IP-Adresse des zukünftigen Hotwire-Interfaces hinzugefügt. In diesem Fall erhält LAN3/eth2 die IP-Adresse 192.168.180.2/24.




Zeile 333: Zeile 421:




Im Step 3 des Wizards werden Schnittstellen definiert, die auf dem Backup System (auch Spare genannt) nicht hochgefahren werden. In unserer Konfiguration haben wir keine solche Schnittstelle. Falls sie die Einwahl über ein DSL Modem machen wollen, welches direkt an der UTM terminiert ist, beachten sie bitte die Konfiguration im Abschnitt „Beispiel-Konfiguration: Externes DSL-Modem“.  
Im Step 3 des Wizards werden Schnittstellen definiert, die auf dem Backup System (auch Spare genannt) nicht hochgefahren werden. In unserer Konfiguration haben wir '''keine''' solche Schnittstelle. Falls sie die Einwahl über ein DSL Modem machen wollen, welches direkt an der UTM terminiert ist, beachten sie bitte die Konfiguration im Abschnitt „Beispiel-Konfiguration: Externes DSL-Modem“.  





Version vom 27. November 2019, 16:34 Uhr




























Securepoint Cluster Konfiguration
Best Practice

Letzte Anpassung zur Version: 11.8.7


Neu:

  • Erweiterte Hinweise zu DHCP
  • Artikelanpassung


Vorherige Versionen: 11.7



Wichtige Information

Aktuelle Software
Installieren Sie immer die neueste Version der Software. Nur in der aktuellen Version sind die neusten Funktionen, Sicherheits-Erweiterungen und Fehlerkorrekturen enthalten.


Einsatzgebiete

Die UTM wird, durch die Umwandlung in einen Hot-Standy UTM-Cluster, aufgewertet und sichert geschäftskritische Prozesse gegen den Ausfall einer UTM ab. Securepoint stellt dazu einen Aktiv-/Passiv-Cluster zur Verfügung. Die UTMs innerhalb des Clusters überwachen sich gegenseitig und schalten bei Bedarf automatisch auf das Gerät mit dem besten Status um. Ein Eingriff des Administrators nicht notwendig.

Cluster-01.jpg
Abb.: 1.1

Einrichtung

Bei der Einrichtung des UTM-Clusters werden zwei UTMs mit identischer Firmware über eine Hotwire-Schnittstelle verbunden. Die Installation mit dem „Cluster Setup Wizard“ wird auf der Ursprungs-UTM ausgeführt, die im dann erstellen Cluster der MASTER sein wird. Mit dieser UTM wird die Synchronisierung der Konfiguration durchgeführt. Auf der Spare-UTM, die im Cluster das BACKUP sein wird, werden bei der Installation die Hotwire-Schnittstelle definiert sowie ein SSH-Schlüssel erzeugt. Auch wird auf der Spare der SSH-Schlüssel des MASTER eingetragen.

Die aktive UTM im Cluster, hat die höhere Priorität und wird als MASTER bezeichnet.

Die UTM mit der niedrigeren Priorität, die passive UTM, ist das BACKUP.


Voraussetzungen

Zum Cluster-Betrieb sind folgende Voraussetzungen notwendig:


  • Eine Cluster-Lizenz

    Zur Konfiguration und den Betrieb des UTM-Clusters wird eine gültige Cluster-Lizenz benötigt, die im Securepoint Reseller Portal beantragt werden kann:

    Endkunden wenden sich bitte an Ihren autorisierten Securepoint Reseller.

    Die Menüpunkte zur Cluster-Konfiguration sind sichtbar, sobald eine Cluster-Lizenz eingespielt ist.

  • Zwei identische Appliances mit mindestens 3 Ethernet Schnittstellen und gleicher Firmware

    Im kleinsten Szenario (siehe Abbildung 1.1) sind eine Eingangs-Schnittstelle (internes LAN) und eine Ausgangs-Schnittstelle (externes LAN) sowie die dritte freie Schnittstelle vorhanden. Diese, im Folgenden auch als Hotwire-Schnittstelle bezeichnet, wird für den Abgleich der Konfiguration und das Connection-Tracking benötigt. Sie kann keine weitere Netzwerkfunktion übernehmen.

  • Die eingesetzten Switches und Router unterstützen gratuitous ARP

    Kommt es im UTM-Cluster zum Master-/Backup-Wechsel, sendet die jetzt aktive UTM gratuitous ARP Pakete an ihre Umgebung, um die neuen MAC-Adresse bekannt zu geben.
    Unterstützen die Switches bzw. Router diese Funktion nicht, können sie nur verzögert über die aktive UTM kommunizieren.



Funktionsweise des Clusters

Funktionsweise des Clusters
Abb.: 1.2


Der Cluster verwendet eindeutige IP- und MAC-Adressen für die beiden Mitglieder des Clusters sowie virtuelle IP-Adressen für den Cluster selber. Die virtuellen IP-Adressen sind allein auf dem aktiven Mitglied des UTM-Clusters aktiv. Fällt das aktive Mitglied des Clusters ganz oder teilweise aus, so wechseln die virtuellen IP-Adressen zum zweiten Mitglied des Clusters.

Für die Clients und Server in einer Clusterkonfiguration, ist die virtuelle IP-Adresse der Kommunikationspartner im Routing (also zum Beispiel das Standard Gateway, siehe Abb. 1.2).



Das Cluster VRR Protokoll

Das Cluster VRR Protokoll
UTM11 BP Cluster pic6.png


VRRP (Virtual Router Redundancy Protocol) ist das Kommunikationsprotokoll des Clusters. Es ist einzig auf den Schnittstellen aktiv, die als High-AvailibilitySchnittstelle konfiguriert sind. Über dieses Protokoll versendet der Master des UTM-Clusters Datenpakete an das Backup. Empfängt das Backup keine Datenpakete, so stuft es sich zum Master hoch.

Mit Hilfe von tcpdump können sie das Protokoll auf einer HA-Schnittstelle sichtbar machen (siehe Abb.)

Es sind keine speziellen Firewall Regeln notwendig, um die Kommunikation mit dem VRR-Protokoll zu ermöglichen.


Umschalten des Clusters

Das Umschalten innerhalb des Clusters kann unter folgenden Bedingungen passieren:

  • Das aktive Mitglied eines Clusters wird neu gestartet oder ganz heruntergefahren.
  • Ein oder mehrere HA-Schnittstellen haben keinen physikalischen Link mehr.
  • Der Link einer HA-Schnittstelle ist aktiv, aber aufgrund eines defekten oder falsch konfigurierten Switches kommen die VRRP Pakete nicht beim Cluster Partner an.
  • Die Cluster Funktion wird auf dem aktiven Cluster-Partner durch den Administrator deaktiviert.


Sind mehr als zwei HA-Schnittstellen aktiviert, besteht im Fehlerfall die Möglichkeit, dass eine unterschiedliche Anzahl von HA-Schnittstellen nicht mehr kommunizieren können. In diesem Fall wird die UTM das aktive Mitglied werden, auf der die meisten Schnittstellen einen Link haben, solange sich die UTMs über wenigstens einer HA-Schnittstelle noch sehen. Sehen sich die UTMs auf keiner Schnittstelle mehr, gehen beide davon aus, dass das zweite Mitglied des Clusters nicht mehr vorhanden ist und beide werden zum Master.


Tabelle, Verhalten im Cluster, Beispiel zwei HA-Schnittstellen:

HA-Schnittstelle 1 HA-Schnittstelle 2 UTM 1 Status UTM 2 Status
UTM 1 UP
, UTM 2 UP
UTM 1 UP
, UTM 2 UP
Aktiv
Passiv
UTM 1 DOWN
, UTM 2 UP
UTM 1 UP
, UTM 2 UP
Passiv
Aktiv
UTM 1 DOWN
, UTM 2 DOWN
UTM 1 UP
, UTM 2 UP
Aktiv
Passiv
UTM 1 DOWN
, UTM 2 DOWN
UTM 1 UP
, UTM 2 DOWN
Aktiv
Aktiv
UTM 1 DOWN
, UTM 2 DOWN
UTM 1 DOWN
, UTM 2 DOWN
Aktiv
Aktiv


Hierbei ist zu beachten, dass UTM-1 eine höhere Priorität als UTM-2 hat. Ist der Zustand in der Tabelle aktiv und als rot gekennzeichnet bedeutet das, dass sich die beiden Mitglieder des Clusters nicht mehr sehen und davon ausgehen, dass der jeweils andere Partner nicht mehr vorhanden ist. Beide Mitglieder des Clusters sind dann aktiv. Eine Netzwerkkommunikation ist dann allerdings generell nicht mehr möglich, da das Problem in der Umgebung liegt.


Hotwire-Schnittstelle

Hotwire-Schnittstelle
Abb.: 1.3


Die Hotwire-Schnittstelle ist eine exklusive Schnittstelle, die nur zum Synchronisieren der Konfiguration der Cluster-Mitglieder und Abgleich der laufenden Verbindungen (Connection-Tracking) verwendet wird. Diese Schnittstelle hat exklusiv diese Aufgabe. Bei der Auswahl der Appliances muss darauf geachtet werden, daß für das Hotwire-Netz jeweils eine Schnittstelle frei sein ist.

Für die Synchronisation der Konfiguration wird das SSH-Protokoll (TCP/22) verwendet. Das Connection-Tracking wird über den Port 3780 (UDP) abgeglichen. Ist eine Ethernet-Schnittstelle als Hotwire gekennzeichnet, werden die Regeln für die Kommunikation automatisch generiert. Für die SSH-Verbindung müssen öffentliche Schlüssel zwischen den Mitgliedern des UTM-Clusters ausgetauscht werden. Der Abgleich der Konfiguration kann in beide Richtungen zwischen den Mitgliedern des Clusters erfolgen. Das Connection-Tracking wird immer automatisch vom Master im Cluster zum Backup übertragen (Abb. 1.3).

Die Hotwire-Verbindung soll immer über eine direkte Kabelverbindung erfolgen (kein Switch etc. dazwischen). Stellen sie bitte sicher, dass niemand zu dem Zeitpunkt administrativ das Mitglied des Clusters verwendet, zu dem sie synchronisieren möchten.


Konfiguration abgleichen

Über die Hotwire-Schnittstelle wird die Konfiguration synchronisiert. Änderungen, die auf einer Maschine im Cluster gemacht wurden, werden über diese Schnittstelle auf das andere Gerät übertragen. In der Regel wird die Konfiguration, nach der Inbetriebnahme des Clusters, allein auf einer UTM durchgeführt. Wir empfehlen den Master zu verwenden. Der Abgleich erfolgt immer manuell. Der Administrator entscheidet, wann er die Konfiguration im UTM-Cluster abgleichen möchte.


Folgende Teile der Konfiguration werden nicht abgeglichen:

  1. IP-Adressen die eindeutig zu einer Maschine gehören und die auf Ethernet- oder VLAN- Schnittstellen konfiguriert wurden.
    Das sind die IP-Adressen, die im Webinterface unter dem Punkt → Netzwerk →Netzwerkkonfiguration eingestellt werden. Wird ein Ethernet- oder VLAN-Schnittstelle neu erzeugt, wird dies zwar übertragen, jedoch nicht die Information über die IP-Adressen dieser Schnittstellen. Diese müssen bei Bedarf manuell auf dem Cluster-Mitglied konfiguriert werden, denn sie sind immer eindeutig einer UTM zugewiesen. Diese IP-Adressen sollen nicht mit virtuellen IP-Adressen auf einer HA-Schnittstelle verwechselt werden, die sich beide Maschinen im Cluster teilen.

  2. Active Directory-Appliance-Account.
    Dieser Account ist immer eindeutig im AD. Man erstellt unterschiedliche Namen auf beiden Maschinen und meldet jede separat am Active Directory an.

Es ist nicht zwingend notwendig, eindeutige IP-Adressen auf Schnittstellen zu konfigurieren, auf dem eine HA-Schnittstelle mit virtuellen IP-Adressen betrieben wird. Soll über diese Schnittstelle das Mitglied des UTM-Clusters eindeutig identifiziert werden, ist dies jedoch erforderlich. In dem Fall gelangt man über die virtuelle IP-Adresse auf die UTM, die in dem Augenblick der Master ist.


Beispiel-Konfiguration: Externes DSL-Modem

In diesem Beispiel wird eine Konfiguration aufgezeigt, mit der Sie einen UTM-Cluster an einer DSL-Leitung betreiben können. Die Einwahl erfolgt direkt durch die UTM.

Netzwerkkonfiguration:

Erstes Mitglied des Clusters (UTM 1, Master)
eth0: Externe DSL Verbindung mittels PPPoE.
eth1: Interne IP-Adresse: 192.168.100.2/24
eth2: Hotwire-IP-Adresse:192.168.180.2/24

Zweites Mitglied des Clusters (UTM 2, Spare)
eth0: Externe DSL Verbindung mittels PPPoE.
eth1: Interne IP-Adresse:192.168.100.3/24
eth2: Hotwire-IP-Adresse:192.168.180.3/24

Als virtuelle IP-Adresse wird 192.168.200.1/24 definiert.
Diese IP-Adresse ist das Standard-Gateway des internen Netzwerks.
Bei Verwendung des DHCP-Servers, darf die Virtuelle IP-Adresse nicht im gleichen Netz wie die physische IP Adresse der Schnittstelle sein. Der DHCP-Server würde sich sonst beim Fallback auf die Physische Adresse der Spare-UTM schlüsseln und die Leases nicht synchronisieren.


Inbetriebnahme der UTMs

Zur Inbetriebnahme des UTM-Clusters wird zunächst der Installationsassistent verwendet. Um eine Doppeleinwahl zu unterbinden, soll das DSL-Modem nicht angeschlossen sein. Die Konfiguration der beiden UTMs unterscheidet sich bis zu diesem Zeitpunkt allein durch die interne und externe IP-Adresse. Im letzten Schritt des Installationsassistenten wird die Cluster-Lizenz ausgewählt. Nach Abschluss des Assistenten werden die UTMs neu gestartet.


Hotwire-Schnittstelle

Die UTMs werden nun physikalisch über die ausgewählte Hotwire-Schnittstelle verbunden. Diese muss auf den Maschinen den gleichen Port belegen - zum Beispiel LAN3/eth2.


Cluster-Konfiguration



























Die UTMs haben innerhalb des Clusters eine unterschiedliche Priorität. Die höhere Priorität hat der Master, die niedrigere das Backup-System. In unserem Beispiel wird die UTM mit der eindeutigen internen IP-Adresse 192.168.100.2 Master sein. Login über das Webinterface mit dieser IP und dem Port für Administration (Default: 11115).

Cluster-Konfiguration
Master-UTM
Master-UTM
IP-Adresse der zukünftigen Hotwire-Schnittstelle
→ Netzwerk →Netzwerkkonfiguration eth2 IP-Adressen
IP-Adressen: »192.168.180.2/24 In der Clickbox wird die IP-Adresse der zukünftigen Hotwire-Schnittstelle hinzugefügt.
Im Beispiel bekommt LAN3/eth2 die IP-Adresse 192.168.180.2/24.
UTM v11.8.7 Cluster Schnittstelle1.png
Abb.


Start des Cluster-Setup-Wizard unter → Netzwerk →Clusterkonfiguration Cluster Assistent
Cluster Assistent Schritt 1
Hotwire Schnittstelle eth2: 192.168.180.2/24 Auf beiden Geräten muss die gleiche Schnitstelle gewählt werden! UTM v11.8.7 Cluster-Assistent Schritt1.png
Abb.: 1.5
Lokale IP‑Adresse: 192.168.180.2/24 IP-Adresse der Master-UTM
Remote IP‑Adresse: 192.168.180.3 IP-Adresse der Hotwire-Gegenstelle (Spare-UTM)


Cluster Assistent Schritt 2
Schnittstelle: eth1 Das zukünftige HA-Interface. Im Beispiel die interne Schnittstelle. UTM v11.8.7 Cluster-Assistent Schritt2.png
Abb.: 1.6
Virtuelle IP‑Adresse: 192.168.200.1/24 Die virtuelle IP-Adresse soll 192.168.200.1 sein. Es können auf einer HA-Schnittstelle auch mehrere virtuelle IP-Adressen liegen.
Bei Verwendung der UTM als DHCP-Server dürfen diese IP-Adressen müssen nicht in der gleichen Broadcast Domain der anderen IP-Adressen liegen.<span

class="mw-collapsible mw-collapsed icon hover" data-expandtext="" data-collapsetext="" id="mw-customcollapsible-hover" >Der DHCP-Server würde sich sonst beim Fallback auf die Physische Adresse der Spare-UTM schlüsseln und die Leases nicht synchronisieren.
Nachdem der Wizard durchlaufen wurde, können auch weitere HA-Schnittstellen konfiguriert werden.



Cluster Assistent Schritt 3
Deaktivierte Schnittstellen während das Gerät im Backup Modus ist: ×wan0 Schnittstellen, die auf dem Backup-System, der Spare-UTM, nicht hochgefahren werden.
Im Beispiel wan0 (das DSL Interface). Die Einwahl soll nur durch die gerade aktive Master-UTM im Cluster erfolgen. <span

class="mw-collapsible mw-collapsed icon hover" data-expandtext="" data-collapsetext="" id="mw-customcollapsible-hover"

>Dadurch ist es möglich, beide externen Interfaces der UTMs an das DSL Modem anzuschließen. Falls das Modem nur einen LAN Port besitzt, ist ein separater Switch zu verwenden.
|| rowspan="1" class="bild" | UTM v11.8.7 Cluster-Assistent Schritt3.png
Abb.: 1.7


Cluster Assistent Schritt 4
Deaktivierte Anwendungen während das Gerät im Backup Modus ist:×Clientless VPN ×DHCP Server ×Greylisting Filter ×HTTP Proxy ×IPSEC ×L2TP VPN ×Mailrelay ×POP3 Proxy ×Routing Daemon ×SPF Filter ×SSL-VPN ×Spamfilter ×WLAN ServerDefault Per Default sind hier Anwendungen aufgeführt, die, sofern sich die Spare-UTM im Backup-Modus befindet, deaktiviert sein sollen UTM v11.8.7 Cluster-Assistent Schritt4.png
Abb.: 1.8


Cluster Assistent Schritt 5
Priorität Hoch Die Master-UTM erhält die Priorität »hoch«. UTM v11.8.7 Cluster-Assistent Schritt5.png
Abb.: 1.9
Passphrase: insecure Die Passphrase für die Kommunikation der beiden UTMs auf den HA-Schnittstellen (VRR Protokoll)
Cluster Assistent abschließen mit Fertig


→ Netzwerk →Clusterkonfiguration Schnittstellen
eth1 Schnittstelle benutzt für High Availability Virtuelle IP 192.168.200.1/24
IP-Adresse: 192.168.100.2/24
UTM v11.8.7 Cluster Konfig.png
Abb.: 1.10
eth2 Schnittstelle wird benutzt als Hotwire IP-Adresse 192.168.180.2/24
wan0 Schnittstelle ist beim Backup deaktiviert
Clusterstatus: Der Clusterstatus zeigt noch keinen Zustand an, weil der Cluster noch nicht auf aktiv geschaltet ist.
Synchronisationsstatus: Der Synchronisationsstatus steht auf rot, weil die Gegenstelle nicht erreichbar ist.



→ Netzwerk →Clusterkonfiguration Einstelungen
Lokaler SSH‑Schlüssel: Neuen lokalen SSH-Schlüssel generieren Im Reiter Einstellungen wird ein SSH Public Key erzeugt. UTM v11.8.7 Netzwerk Cluster-Config Einstellungen.png
Abb.: 1.11
ssh-rsa
AAAAB3Nz […] zE0SU=
root@master.cluster.local
SSH-Schlüssel in die Zwischenablage kopieren

Spare-UTM
Spare UTM

Login über die IP-Adresse 192.168.180.3 auf das Web-Interface der Spare-UTM.
→ Netzwerk →Clusterkonfiguration Schnittstellen
Name: eth2 eth2 Schnittstelle bearbeiten UTM v11.8.7 Netzwerk Cluster-Config UTM2 eth2.png
Abb.: 1.12
Verwendung: Schnittstelle als Hotwire benutzen Die Schnittstelle eth2 der Spare-UTM wird als Hotwire gekennzeichnet.
Lokale IP-Adresse: 192.168.180.3/24 IP-Adresse der Spare-UTM, die für Hotwire verwendet werden soll.
Remote IP-Adresse: 192.168.180.2 IP-Adresse der bereits konfigurierten Master-UTM, die als Hotwire angesprochen werden soll.


→ Netzwerk →Clusterkonfiguration Einstellungen
Lokaler SSH‑Schlüssel: Neuen lokalen SSH-Schlüssel generieren SSH Public Key für die Spare-UTM erzeugen UTM v11.8.7 Netzwerk Cluster-Config Einstellungen-Spare.png
Abb.: 1.13
ssh-rsa
AAAAB3Nz […] Q1/k=
root@spare.cluster.local
SSH-Schlüssel noch nicht in die Zwischenablage kopieren
SSH‑Schlüssel der Gegenstelle: ssh-rsa
AAAAB3Nz […] zE0SU=
root@master.cluster.local
Public-SSH-Key der Master-UTM aus der Zwischenablage einfügen
Lokaler SSH‑Schlüssel: Jetzt den lokalen Public-SSh-Key der Spare-UTM in die Zwischenablage einfügen.
Wechsel auf die Master-UTM und dort einfügen unter SSH‑Schlüssel der Gegenstelle: (Auf der Master-UTM ist entspicht die Spare-UMT der Gegenstelle)

Auf beiden Seiten sollte sich nun ein lokaler SSH Schlüssel und jeweils der SSH Schlüssel der Gegenstelle gefinden. Speichern der Einstellungen auf beiden UTMs in diesem Dialog durch Betätigung der Speichern Schaltfläche.
Synchronisationsstatus Der Synchronisationsstatus sollte nun von rot zu orange wechseln. Das bedeutet, die beiden UTMs sehen sich über die Hotwire-Schnittstelle, jedoch ist die Konfiguration noch nicht synchronisiert.
Der Status wird Nur für interne Prüfzwecke aktualisiert. In dem Reiter Schnittstellen kann die Aktualisierung mit der Synchronisieren-Schaltfläche manuell ausgelöst werden.
Konfiguration synchronisieren
Synchronisationsstatus Wenn die Synchronisation erfolgreich abgeschlossen wurde, steht jetzt der Synchronisationsstatus auf grün. Die beiden UTMs sind abgeglichen.
Dieser Vorgang kann überprüft werden, indem auf der Spare-UTM eine Konfiguration aufgerufen wird, die im Master verändert wurde.

Die Cluster Priorität → Netzwerk →Clusterkonfiguration einstellungen der Spare-UTM (Backup) wurde automatisch auf niedrig gestellt.
Würde die Priorität auf der jetzigen Spare-UTM auf hoch gestellt und von da aus auch die Konfiguration synchronisiert werden, würde die erste Maschine automatisch zum Spare degradiert und die vormals Spare-UTM zum Master.



Cluster aktivieren
→ Netzwerk →Clusterkonfiguration Einstelungen
Externe Interfaces an das DSL-Modem anschließen UTM11 BP Cluster pic20.png
Abb.: 1.14
Cluster: Ein

Dieser Schritt muss auf beiden UTMs ausgeführt werden.

Clusterstatus Auf der Master-UTM: Der Cluster ist nun in Betrieb und der Master des Clusters hat unsere virtuelle IP-Adresse 192.168.200.1 auf dem internen Interface.
Auf der Spare-UTM: Die Spare-UTM läuft als Hot-Standby im Backup-Modus im Hintergrund


Sollte der Status nicht sofort aktualisiert werden, kann das auch hier wieder über die Schaltfläche zum Aktualisieren manuell ausgelöst werden.


Beispiel Konfiguration: Externer Router

In diesem Beispiel wird eine Konfiguration mit einem externen Router beschrieben. Der Router ist das Gateway zum Internet. Eventuell wurde vom Provider ein öffentliches Netz zur Verfügung gestellt. In diesem Beispiel wird ein privates Netz verwendet. Die Vorgehensweise ist dann analog zum öffentlichen Netz. Hier werden nun zwei HA-Schnittstellen konfiguriert. Eine für die interne und eine für die externe Schnittstelle.


Netzwerkkonfiguration:

Erstes Mitglied des Clusters (UTM 1, Master)
eth0: Externe IP Adresse (zom Router) 192.168.175.102/24
eth1: Interne IP-Adresse: 192.168.100.2/24
eth2: Hotwire-IP-Adresse:192.168.180.2/24

Zweites Mitglied des Clusters (UTM 2, Spare)
eth0: Externe IP Adresse (zom Router) 192.168.175.103/24
eth1: Interne IP-Adresse:192.168.100.3/24
eth2: Hotwire-IP-Adresse:192.168.180.3/24

Die virtuellen IP-Adressen, die sich beide Mitglieder des Clusters teilen werden, sind die IP-Adressen 192.168.200.1/24 für die internen Schnittstellen und 192.168.175.103/24 für die extern Schnittstellen (zum Router).
Die virtuelle IP-Adresse 192.168.200.1 ist das Standard-Gateway des internen Netzwerks.


Inbetriebnahme der UTMs

Zur Inbetriebnahme des UTM-Clusters wird zunächst der Installationsassistent verwendet. Diese Einrichtung wird auf jeder UTM separat durchgeführt. Die Konfiguration der beiden UTMs unterscheidet sich bis zu diesem Zeitpunkt allein durch die interne und externe IP-Adresse. Im letzten Schritt des Installationsassistenten wird die Cluster-Lizenz ausgewählt. Nach Abschluss des Assistenten werden die UTMs neu gestartet.


Hotwire-Schnittstelle

Die UTMs werden nun physikalisch über die Hotwire-Schnittstelle verbunden. Diese muss auf den Maschinen den gleiche Port belegen, zum Beispiel LAN3/eth2.


Cluster Konfiguration

Cluster-Konfiguration
Master-UTM
Master-UTM
IP-Adresse der zukünftigen Hotwire-Schnittstelle
→ Netzwerk →Netzwerkkonfiguration eth2 IP-Adressen
IP-Adressen: »192.168.180.2/24 In der Clickbox wird die IP-Adresse der zukünftigen Hotwire-Schnittstelle hinzugefügt.
Im Beispiel bekommt LAN3/eth2 die IP-Adresse 192.168.180.2/24.
UTM v11.8.7 Cluster Schnittstelle1.png
Abb.


Start des Cluster-Setup-Wizard unter → Netzwerk →Clusterkonfiguration Cluster Assistent
Cluster Assistent Schritt 1
Hotwire Schnittstelle eth2: 192.168.180.2/24 Auf beiden Geräten muss die gleiche Schnitstelle gewählt werden! UTM v11.8.7 Cluster-Assistent Schritt1.png
Abb.: 1.5
Lokale IP‑Adresse: 192.168.180.2/24 IP-Adresse der Master-UTM
Remote IP‑Adresse: 192.168.180.3 IP-Adresse der Hotwire-Gegenstelle (Spare-UTM)


Cluster Assistent Schritt 2
Schnittstelle: eth1 Das zukünftige HA-Interface. Im Beispiel die interne Schnittstelle. UTM v11.8.7 Cluster-Assistent Schritt2.png
Abb.: 1.6
Virtuelle IP‑Adresse: 192.168.200.1/24 Die virtuelle IP-Adresse soll 192.168.200.1 sein. Es können auf einer HA-Schnittstelle auch mehrere virtuelle IP-Adressen liegen.
Bei Verwendung der UTM als DHCP-Server dürfen diese IP-Adressen müssen nicht in der gleichen Broadcast Domain der anderen IP-Adressen liegen.<span

class="mw-collapsible mw-collapsed icon hover" data-expandtext="" data-collapsetext="" id="mw-customcollapsible-hover" >Der DHCP-Server würde sich sonst beim Fallback auf die Physische Adresse der Spare-UTM schlüsseln und die Leases nicht synchronisieren.
Nachdem der Wizard durchlaufen wurde, können auch weitere HA-Schnittstellen konfiguriert werden.



Cluster Assistent Schritt 3
Deaktivierte Schnittstellen während das Gerät im Backup Modus ist: ×wan0 Schnittstellen, die auf dem Backup-System, der Spare-UTM, nicht hochgefahren werden. In dieser Konfiguration ist das nicht erforderlich UTM v11.8.7 Cluster-Assistent Schritt3b.png
Abb.: 1.7


Cluster Assistent Schritt 4
Deaktivierte Anwendungen während das Gerät im Backup Modus ist:×Clientless VPN ×DHCP Server ×Greylisting Filter ×HTTP Proxy ×IPSEC ×L2TP VPN ×Mailrelay ×POP3 Proxy ×Routing Daemon ×SPF Filter ×SSL-VPN ×Spamfilter ×WLAN ServerDefault Per Default sind hier Anwendungen aufgeführt, die, sofern sich die Spare-UTM im Backup-Modus befindet, deaktiviert sein sollen UTM v11.8.7 Cluster-Assistent Schritt4.png
Abb.: 1.8


Cluster Assistent Schritt 5
Priorität Hoch Die Master-UTM erhält die Priorität »hoch«. UTM v11.8.7 Cluster-Assistent Schritt5.png
Abb.: 1.9
Passphrase: insecure Die Passphrase für die Kommunikation der beiden UTMs auf den HA-Schnittstellen (VRR Protokoll)
Cluster Assistent abschließen mit Fertig


→ Netzwerk →Clusterkonfiguration Schnittstellen
eth1 Schnittstelle benutzt für High Availability Virtuelle IP 192.168.200.1/24
IP-Adresse: 192.168.100.2/24
UTM v11.8.7 Cluster Konfig-exr.png
Abb.: 1.10
eth2 Schnittstelle wird benutzt als Hotwire IP-Adresse 192.168.180.2/24
wan0 Schnittstelle ist beim Backup deaktiviert
Clusterstatus: Der Clusterstatus zeigt noch keinen Zustand an, weil der Cluster noch nicht auf aktiv geschaltet ist.
Synchronisationsstatus: Der Synchronisationsstatus steht auf rot, weil die Gegenstelle nicht erreichbar ist.



→ Netzwerk →Clusterkonfiguration Einstelungen
Lokaler SSH‑Schlüssel: Neuen lokalen SSH-Schlüssel generieren Im Reiter Einstellungen wird ein SSH Public Key erzeugt. UTM v11.8.7 Netzwerk Cluster-Config Einstellungen.png
Abb.: 1.11
ssh-rsa
AAAAB3Nz […] zE0SU=
root@master.cluster.local
SSH-Schlüssel in die Zwischenablage kopieren

Spare-UTM
Spare UTM

Login über die IP-Adresse 192.168.180.3 auf das Web-Interface der Spare-UTM.
→ Netzwerk →Clusterkonfiguration Schnittstellen
Name: eth2 eth2 Schnittstelle bearbeiten UTM v11.8.7 Netzwerk Cluster-Config UTM2 eth2.png
Abb.: 1.12
Verwendung: Schnittstelle als Hotwire benutzen Die Schnittstelle eth2 der Spare-UTM wird als Hotwire gekennzeichnet.
Lokale IP-Adresse: 192.168.180.3/24 IP-Adresse der Spare-UTM, die für Hotwire verwendet werden soll.
Remote IP-Adresse: 192.168.180.2 IP-Adresse der bereits konfigurierten Master-UTM, die als Hotwire angesprochen werden soll.


→ Netzwerk →Clusterkonfiguration Einstellungen
Lokaler SSH‑Schlüssel: Neuen lokalen SSH-Schlüssel generieren SSH Public Key für die Spare-UTM erzeugen UTM v11.8.7 Netzwerk Cluster-Config Einstellungen-Spare.png
Abb.: 1.13
ssh-rsa
AAAAB3Nz […] Q1/k=
root@spare.cluster.local
SSH-Schlüssel noch nicht in die Zwischenablage kopieren
SSH‑Schlüssel der Gegenstelle: ssh-rsa
AAAAB3Nz […] zE0SU=
root@master.cluster.local
Public-SSH-Key der Master-UTM aus der Zwischenablage einfügen
Lokaler SSH‑Schlüssel: Jetzt den lokalen Public-SSh-Key der Spare-UTM in die Zwischenablage einfügen.
Wechsel auf die Master-UTM und dort einfügen unter SSH‑Schlüssel der Gegenstelle: (Auf der Master-UTM ist entspicht die Spare-UMT der Gegenstelle)

Auf beiden Seiten sollte sich nun ein lokaler SSH Schlüssel und jeweils der SSH Schlüssel der Gegenstelle gefinden. Speichern der Einstellungen auf beiden UTMs in diesem Dialog durch Betätigung der Speichern Schaltfläche.
Synchronisationsstatus Der Synchronisationsstatus sollte nun von rot zu orange wechseln. Das bedeutet, die beiden UTMs sehen sich über die Hotwire-Schnittstelle, jedoch ist die Konfiguration noch nicht synchronisiert.
Der Status wird Nur für interne Prüfzwecke aktualisiert. In dem Reiter Schnittstellen kann die Aktualisierung mit der Synchronisieren-Schaltfläche manuell ausgelöst werden.
Konfiguration synchronisieren
Synchronisationsstatus Wenn die Synchronisation erfolgreich abgeschlossen wurde, steht jetzt der Synchronisationsstatus auf grün. Die beiden UTMs sind abgeglichen.
Dieser Vorgang kann überprüft werden, indem auf der Spare-UTM eine Konfiguration aufgerufen wird, die im Master verändert wurde.

Die Cluster Priorität → Netzwerk →Clusterkonfiguration einstellungen der Spare-UTM (Backup) wurde automatisch auf niedrig gestellt.
Würde die Priorität auf der jetzigen Spare-UTM auf hoch gestellt und von da aus auch die Konfiguration synchronisiert werden, würde die erste Maschine automatisch zum Spare degradiert und die vormals Spare-UTM zum Master.



Cluster aktivieren
→ Netzwerk →Clusterkonfiguration Einstelungen
Externe Interfaces an das DSL-Modem anschließen UTM11 BP Cluster pic20.png
Abb.: 1.14
Cluster: Ein

Dieser Schritt muss auf beiden UTMs ausgeführt werden.

Clusterstatus Auf der Master-UTM: Der Cluster ist nun in Betrieb und der Master des Clusters hat unsere virtuelle IP-Adresse 192.168.200.1 auf dem internen Interface.
Auf der Spare-UTM: Die Spare-UTM läuft als Hot-Standby im Backup-Modus im Hintergrund


Die UTMs haben innerhalb des Clusters eine unterschiedliche Priorität. Die höhere Priorität hat der Master, die niedrigere das Backup-System. Die UTM mit der eindeutigen internen IP-Adresse 192.168.100.2 ist Master. Im Webinterface unter Netzwerk -> Netzwerkkonfiguration wird die IP-Adresse des zukünftigen Hotwire-Interfaces hinzugefügt. In diesem Fall erhält LAN3/eth2 die IP-Adresse 192.168.180.2/24.


Abb.: 1.15


Im Cluster Dialog (Netzwerk -> Clusterkonfiguration) wird jetzt der "Cluster Setup Wizard" gestartet. In "Step 1" wird die Hotwire-Schnittstelle ausgewählt und die IP-Adresse der Hotwire-Gegenstelle angegeben.


Abb.: 1.16


In "Step 2" des Wizards wird eine zukünftige HA-Schnittstelle ausgewählt. Es wird die interne Schnittstelle ausgewählt. Die virtuelle IP-Adresse soll 192.168.175.1/24 sein. Eine HA-Schnittstelle kann mehrere virtuelle IP-Adressen erhalten. Diese IP-Adressen müssen nicht in derselben Broadcast-Domain der anderen IP-Adressen sein. Nachdem der Wizard durchlaufen wurde, können weitere HA-Schnittstellen konfiguriert werden.


Abb.: 1.17


Im Step 3 des Wizards werden Schnittstellen definiert, die auf dem Backup System (auch Spare genannt) nicht hochgefahren werden. In unserer Konfiguration haben wir keine solche Schnittstelle. Falls sie die Einwahl über ein DSL Modem machen wollen, welches direkt an der UTM terminiert ist, beachten sie bitte die Konfiguration im Abschnitt „Beispiel-Konfiguration: Externes DSL-Modem“.


Abb.: 1.18

Im nächsten Schritt können sie Applikationen definieren die auf dem Backup System nicht aktiv sein sollen. Das Verhalten entspricht dem Schritt 3. Wir wählen hier die Applikation DHCP Server aus, falls die UTM auch als DHCP Server agieren soll, sprich den Clients im internen Netz IP-Adressen vergeben soll. Falls sie eine UTM verwenden, die auch als Access Point dient, deaktivieren sie hier auch die Applikation WLAN-Server.


Abb.: 1.19


Im letzten Schritt des Wizards legen sie die Passphrase für die Kommunikation der beiden UTMs auf den HA Schnittstellen fest (VRR-Protokoll) und die Priorität. Wir möchten das diese UTM die höhere Priorität hat, sprich im Regelfall Master ist.


Abb.: 1.20


Die Konfiguration sieht nun wie folgt aus. Der Clusterstatus zeigt noch keinen Zustand an, weil der Cluster noch nicht auf aktiv geschaltet ist. Der Synchronisationsstatus steht auf rot, weil die Gegenstelle nicht erreichbar ist.


Abb.: 1.21


Unter dem Punkt Einstellungen erzeugen sie nun einen SSH Public Key und kopieren ihn in die Zwischenablage.


Abb.: 1.22


Nun wird es Zeit, die zweite UTM im Cluster zu konfigurieren. Loggen sie sich über die IP-Adresse 192.168.175.3 auf das Web-Interface ein. Öffnen sie den Dialog Clusterkonfiguration und bearbeiten sie die Schnittstelle eth2 um sie als Hotwire zu kennzeichnen. Geben sie in dem Dialog als lokale IP-Adresse 192.168.180.3/24 und als Gegenstelle die bereits konfigurierte UTM mit der IP-Adresse 192.168.180.2 ein.


Abb.: 1.23


Wechseln sie danach in den Dialog Clusterkonfiguration -> Einstellungen und generieren dort ebenfalls einen SSH Key. Kopieren sie den SSH Key von der ersten UTM aus der Zwischenablage in das Feld „SSH-Schlüssel der Gegenstelle“. Wechseln sie auf die erste UTM und kopieren sie den SSH Key der zweiten UTM in das Feld „SSH-Schlüssel der Gegenstelle“. Auf beiden Seiten sollte sich nun jeweils ein lokaler SSH Schlüssel und der SSH Schlüssel der Gegenstelle befinden. Speichern sie die Einstellungen auf beiden UTMs in diesem Dialog durch betätigen der „Speichern“ Schaltfläche. Der Synchronisationsstatus sollte nun von rot auf orange wechseln. Das bedeutet, die beiden UTMs sehen sich über die Hotwire Schnittstelle, aber die Konfiguration ist nicht synchronisiert.

Beachten sie bitte, dass der Status in bestimmten Intervallen aktualisiert wird. Wenn sie in dem Dialog „Schnittstellen“ die Aktualisierungs-Schaltfläche betätigen, können sie den Vorgang beschleunigen.


Abb.: 1.24


Loggen sie sich nun aus dem aus der zweiten Maschine aus und wechseln sie wieder in das Web-Interface der ersten UTM, unserem Master. Betätigen sie nun den Button Konfiguration synchronisieren das erste Mal. Wenn die Synchronisation erfolgreich abgeschlossen wurde, steht jetzt der Synchronisationsstatus auf grün. Die beiden UTMs sind abgeglichen. Alles was sie auf der Master bereits konfiguriert haben, befindet sich jetzt auch auf der Backup Maschine. Sie können dies überprüfen, indem sie sich auf der Backup Maschine einloggen und die entsprechenden Dialoge öffnen. Da wir von der von uns definierten Master UTM die Synchronisation durchgeführt haben, wird die Cluster Priorität der zweiten Maschine (Backup) automatisch auf niedrig gestellt.


Würden Sie die Priorität auf der jetzigen Backup UTM auf Hoch stellen und von da aus auch die Konfiguration synchronisieren, würde die erste Maschine automatisch zum Backup degradiert und die vormals Backup UTM zum Master.

Wechseln Sie nun auf den Punkt Einstellungen und aktivieren sie den Cluster. Dieser Schritt muss auf beiden UTMs getrennt ausgeführt werden. Ihr Cluster ist nun in Betrieb und der Master des Clusters hat unsere virtuelle IP-Adresse 192.168.175.1 auf dem internen Interface.


Abb.: 1.25


Nun muss noch die externe Schnittstelle auf HA Betrieb konfiguriert werden. Bearbeiten sie diese Schnittstelle in der Clusterkonfiguration und stellen sie das Interface im Dialog auf „Schnittstelle für High Availability benutzen“.


Abb.: 1.26


Im zweiten Reiter des Dialogs stellen sie die virtuelle IP-Adresse ein, die wir vorab ausgewählt haben.


Abb.: 1.27

Speichern sie die Einstellungen und synchronisieren sie den Cluster damit die zweite Maschine die gleiche Konfiguration besitzt. Die Konfiguration ist sofort aktiv und ihr Cluster konfiguriert.


Abb.: 1.28

NAT in der Cluster Konfiguration

In bestimmten Konstellationen ist es notwendig die NAT Einstellungen anzupassen. Wir beziehen uns hier auf das Beispiel „Cluster Konfiguration: Externer Router“.


Die externen IP-Adressen des Clusters sind in der selben Broadcast Domain und die Standardroute der UTMs zeigt auf den Router der die Internet Verbindung herstellt.


Externe IP UTM 1:172.16.0.105/24

Externe IP UTM 2:172.16.0.106/24

Virtuelle IP Cluster:172.16.0.107/24

IP des Routers:172.16.0.1/24


Die UTM 1 soll Master sein und besitzt die virtuelle IP-Adresse. Setzen wir nun einen ping aus dem internen Netz auf die IP-Adresse des Routers ab, sehen wir Folgendes im tcpdump der UTM1 auf dem externen Interface.


UTM11 BP Cluster pic29.png


Der Ping wird von unserem Client im Standard-Regelwerk nicht über die virtuelle IP-Adresse des Clusters geNATet, sondern über die dem Master eindeutige IP-Adresse 172.16.0.105. Das kommt zustande, weil die eindeutige IP-Adresse die erste IP auf der Schnittstelle ist und der Router sich in der gleichen Broadcast Domain befindet. Wechselt der Cluster auf das Backup System, wird dort nicht mehr die IP-Adresse 172.16.0.105 sondern die IP-Adresse 172.16.0.106 stehen.

Um das zu ändern erstellen wir unter Firewall -> Portfilter -> Netzwerkobjekte ein neues Objekt mit der virtuellen IP-Adresse auf dem Cluster Interface.


Abb.: 1.29


Wechseln sie in den Reiter Portfilter und bearbeiten sie die HideNAT Regel. In unserem Fall Regel Nummer 1.


Abb.: 1.30


Ersetzen sie das Objekt „external-interface“ durch ihr gerade erstelltes Objekt „HA-Externe-IP“. Speichern sie die Regel ab und aktualisieren sie das Regelwerk. Synchonisieren sie danach den Cluster.


Abb.: 1.31


Wenn sie den Ping Test wiederholen, sollten sie Folgendes sehen. Beachten sie: Wenn ihr Ping auf den Router ohne Unterbrechung lief, ist dieser noch im Conntrack gespeichert, der Ping wird also noch über die falsche IP-Adresse geNATet. Unterbrechen sie den Ping und warten sie mindestens 30 Sekunden. Starten sie den Ping dann neu.


UTM11 BP Cluster pic33.png


UMA20 AHB hinweispic.png Achtung!

Achten sie darauf, dass Sie für NAT Einstellungen immer eindeutige IP-Adressen in den Netzwerkobjekten benutzen, wenn das NAT über ein HA Interface konfiguriert wird. Das gilt nicht nur für HideNATs sondern auch Portweiterleitungen bzw. Destination NATs.


Applikationen in der Cluster Konfiguration

Ähnliches wie in dem Beispiel NAT in der Cluster Konfiguration kann auch für Applikationen zutreffen. Wir beziehen uns hier wieder auf die Cluster Konfiguration mit dem externen Router. Als Applikation nehmen wir uns das Mailrelay heraus.


Sie möchten E-Mails über das Mailrelay der UTMs verschicken und empfangen. Sie haben dazu entsprechende PTR, A, MX Records und SPF Einträge in den TXT Records ihrer Domain gemacht, die auf die externe virtuelle IP-Adresse des Clusters zeigen. Damit das Mailrelay nun auch E-Mails über diese virtuelle IP verschickt, müssen sie in der Applikation die ausgehende IP-Adresse korrekt einstellen. In unserem Fall die virtuelle IP 172.16.0.107.


Abb.: 1.32

Synchronisieren sie danach wieder die Cluster Konfiguration.


UMA20 AHB hinweispic.png Achtung!

Das Mailrelay kommuniziert jetzt immer mit der virtuellen IP-Adresse 172.16.0.107. Auch der interne Mailserver wird mit dieser IP als Absender kontaktiert. Bitte berücksichtigen Sie das bei der Konfiguration Ihres Mailservers, sollte dieser nur SMTP-Verbindungen von bestimmten IPs akzeptieren.


Kommunikation von Applikationen, die auf der Firewall laufen

Alle Applikationen, die von der Firewall selber eine Verbindung aufbauen, verwenden dafür (sofern nicht anders konfiguriert) die primären IPs der Schnittstellen. Sollten Sie Management-IPs aus der gleichen Broadcast-Domäne verwenden sind diese primären IPs nicht die virtuellen IP-Adressen.


Syslog

Das bedeutet, dass beispielsweise Syslog-Nachrichten von der Management-IP der Master verschickt werden, wenn diese die aktive Maschine im Cluster ist, und von der Management-IP der Spare wenn diese aktiviert wurde.

Folgende weitere Applikationen sind betroffen:


HTTP-Proxy

Sollte ein Parent-Proxy in Benutzung sein, der Verbindungen nur von einer bestimmten IP annimmt, muss diese unter „Anwendungen“ -> „HTTP-Proxy“ -> „Ausgehende Adresse“ angegeben werden.


Mailrelay

Bitte beachten Sie dazu die Hinweise im Abschnitt „Applikationen in der Cluster-Konfiguration“


RADIUS-/LDAP-/AD-Anbindung

Sollte der Server nur Verbindungen von bestimmten IPs zulassen, müssen auf dem Ziel-Server jeweils die Management-IPs beider Geräte freigegeben werden.


IPSec

Alle IPSec-Verbindungen müssen in Phase 1 so angepasst werden, dass im Feld „Local Gateway“ eine der virtuellen IPs fest eingetragen ist.


SSLVPN-Server

Alle SSLVPN-Server-Instanzen müssen so angepasst werden, dass unter „Einstellungen“ -> „Erweitert“ die Option „Multihome“ aktiviert ist.


SSLVPN-Clients

Alle SSLVPN-Client-Instanzen müssen so angepasst werden, dass Sie eine der virtuellen IPs zum Verbindungsaufbau verwenden. Führen Sie dazu folgende CLI-Befehle aus:


Zum Feststellen der ID der SSLVPN-Verbindung:

firewall> openvpn get


Zum Setzen der lokalen Adresse;

firewall> openvpn set id <ID> local_addr <VIRTUELLE-IP> local_port <FREIER-PORT>


Zum Aktivieren der Einstellungen:

firewall> appmgmt restart application openvpn


POP3 Proxy

Der POP3-Proxy kommuniziert immer mit der Management-IP, sofern diese in der gleichen Broadcast-Domain wie das Default-Gateway ist. Dies ist bei der Beschränkung des Zugriffs auf POP3-Server auf bestimmte IP-Adressen in deren Konfiguration zu beachten.


Clientless VPN

Verbindungen zu RDP/VNC-Servern werden immer mit den Management-IPs aufgebaut. Dies ist bei der Beschränkung des Zugriffs auf RDP/VNC-Server auf bestimmte IP-Adressen in deren Konfiguration zu beachten.


Nameserver

Verbindungen zu DNS-Servern werden immer mit den Management-IPs aufgebaut. Dies ist bei der Beschränkung des Zugriffs auf DNS-Server auf bestimmte IP-Adressen in deren Konfiguration zu beachten.

CLI Befehle

Im folgenden werden Befehle für die Securepoint CLI beschrieben.


CLI Befehle: cluster info


Ausgabe:


cluster_state:backup/master/none


Der Cluster State gibt an wer im Cluster gerade Master oder Backup ist oder ob der Cluster überhaupt aktiv ist. Die Ausgabe bezieht sich immer auf die Maschine, auf der dieser Befehl ausführt wird.


sync_state:synchronized/pending/error


Im welchen Zustand befindet sich die Konfiguration. Dabei bedeutet „synchronized“, das sie auf beiden UTMS des Clusters gleich ist. Der Zustand „pending“ bedeutet, die UTMs haben einen unterschiedlichen Stand. In beiden Fällen können die Mitglieder miteinander kommunizieren. Der Zustand „error“ weist darauf hin das sie keine Daten austauschen können. Das könnte der Fall sein, wenn kein Hotwire Interface konfiguriert ist, die Verkabelung nicht korrekt ist, die SSH Keys nicht ausgetauscht wurden, oder falsche SSH Keys verwendet werden.


hotwire_dev:ethx


Auf welchen Interface ist das Hotwire Interface konfiguriert.


CLI Befehl: system config synchronize


Durch diesen Befehl kann die Konfiguration über die Hotwire Schnittstelle an den Cluster Partner übertragen werden. Dabei wird die Konfiguration von der UTM verwendet, auf der sie den Befehl ausführen. Falls sie in der CLI eine Konfigurationsänderung durchgeführt haben, speichern sie diese erst lokal durch den CLI Befehl „system config save name <Name ihrer Konfiguration>“. Erst dann synchronisieren die Konfiguration des Clusters. Ansonsten wird die Änderung nicht übertragen.


CLI Befehl: extc value get application "securepoint_firewall" variable "UPDATE_TRIGGER_DELAY"


Zeigt den Delay in Sekunden an, bevor im Fehlerfall, von Master auf Backup geschaltet wird. Der Standardwert ist 2 Sekunden.


CLI Befehl: extc value set application "securepoint_firewall" variable "UPDATE_TRIGGER_DELAY" value 2


Verändert den Delay, für den Fehlerfall, das von Master auf Backup geschaltet wird. Der Standardwert ist 2 Sekunden und sollte nicht niedriger eingestellt werden. Falls ihre Appliances im Cluster eine hohe Grundlast haben sollten, stellen sie den Wert höher ein. Die Einstellung ist sofort aktiv und kann via „system config synchronize“ auf den Partner übertragen werden.


Einschränkungen

DHCP-Client mit HA-Schnittstelle kombinieren

Konfigurieren sie kein HA Interface auf einem Ethernet oder VLAN Interface auf dem sie DHCP Client konfiguriert haben, also die UTM auf dem Interface eine IP-Adresse dynamisch zugewiesen bekommt. Sollte der DHCP Server nicht erreichbar sein nachdem sie die UTM gestartet haben und ist sie in dem Augenblick auch der Master im Cluster, wird die virtuelle IP-Adresse vom Interface entfernt sobald der DHCP Server wieder erreichbar ist und die UTM eine neue IP-Adresse vom DHCP Server empfängt.

DHCP-Server in einer Clusterumgebung

In einem UTM-Cluster ist grundsätzlich davon abzuraten den DHCP-Server der UTM zu verwenden, da die DHCP-Kommunikation mit dem Client über die Management-IP der UTM abgewickelt wird und die Leases nicht synchronisiert werden. Es wird empfohlen einen externen DHCP-Server bzw. das DHCP-Relay der UTM zu verwenden.




<references/>