Fortigate – Migration Multiple VDOM Konfig in Single VDOM Konfig
Eine Herausforderung war eine Migration eines Fortigate 100D Clusters, bei welcher VDOMs aktiviert waren. Normalerweise gibt es keine Möglichkeit, die aktivierte VDOM Konfig unterbrechungsfrei wieder zu deaktivieren, da eine aktivierte VDOM Konfiguration etliche Parameter und Konfigurationseinstellungen beeinflusst. Insofern ist die offizielle Variante, das gesamte System neu zu integrieren. Bei einer komplexen Konfiguration, kann das Tage Arbeit und vor allem ein nerviges Troubleshooting nach sich ziehen. Da es sich hier aber um ein Cluster handelte, kam mir die Idee eines der Systeme vorzubereiten und anschließend mit dem alten System das Cluster wiederherzustellen. Das ging natürlich nur, da für den Zeitraum der Umbauten und Änderungen (bei mir etwa 3 Tage) auf die HA Funktion verzichtet werden konnte (besser musste).
Grundsätzlich der Plan:
- Altes Cluster mit nur einem System weiterbetreiben
- Abgehängtes System in den Werkszustand versetzen
- Konfiguration von Multiple VDOM auf Single VDOM „umbauen“
- Überarbeitete Single VDOM Konfig am „neuen“ System importieren
- Umstellen des Netzwerks auf das neue Single VDOM System
- Alles testen und ggfs. Fehler abstellen
- Altes Cluster System in den Werkszustand versetzen
- Altes Cluster System dem neuen Single VDOM System als Slave hinzufügen
Wir befanden dies für die beste Lösung, vor allem hinsichtlich der notwendigen Downtimes und Fehlerquellen und vorab, wir kamen so mit einer effektiven Downtime von ca. 30 Minuten aus.
Die Steps im Detail:
- Secondary vom Cluster trennen, herunterfahren und das Cluster nur mit der Primary Unit betreiben. Es meckert zwar die ganze Zeit, aber wir wussten ja warum.
Achtung! Bitte unbedingt nach einem evtl. Failover die korrekte Funktion der Firewall testen! Ich habe HA Cluster gesehen, bei denen die Konfiguration nicht korrekt synchronisiert war. - Die „alte“ Secondary Unit in den Werkszustand versetzen. Damit sollte der Zugriff auf Port1 via https://10.1.1.1 möglich sein.
- Backup der Konfiguration des Clusters via GUI, unverschlüsselt, damit ich sie editieren kann. Ich habe die globale und separat noch einmal die entsprechende VDOM-Konfig exportiert (gesichert).
- Vorbereitend die betreffenden Ports von der alten Konfig an der „neuen“ planen und die Interfaces neu zuordnen.
Meine Beispielkonfig:- WAN1 (WAN Uplink Internet Provider)
- Port1 (Transit Interface zum Core Switch – IRF Stack)
- Lab-Netz (VLAN an Port1)
- DMZ
- DMZ3 (VLAN am DMZ Interface)
- Port2 (DMZ 2)
- BYOD WLAN (VLAN an Port3)
- Gast WLAN (VLAN an Port3)
- ha1 und ha2 lasse ich aktiv, aber völlig unkonfiguriert (für späteres Clustern)
- Die gesicherte (Cluster) Konfig im Editor Deiner Wahl öffnen. Ich habe Notepad++ verwendet, da ich hier die Syntax für das Ersetzen diverser Zeichenketten und die Zeilenoperationen kenne.
- Den kompletten Header entfernen, bis zum Teil config sytem interface.
- Die „alten“ Interface-Namen durch die neuen „ersetzen“, falls erforderlich. Achtung hier immer „Alle ersetzen…“, denn natürlich werden die Namen der Interfaces in der gesamten Konfig „irgendwo“, wie bspw. bei IPSec Tunneln, in den SSL-VPN Einstellungen, bei Adressobjekten (wenn der Parameter Interface nicht auf ANY) steht und natürlich in allen Policies als Source bzw. Target Interface verwendet.
- Jetzt muss man die entsprechenden IP’s, ebenfalls durch reines „Ersetzen“ auf den Interfaces anpassen, falls erforderlich.
- Bei den Interfaces (Achtung, hier ggfs. auf das Global Backup zurückgreifen, da in der VDOM evtl. nicht alle Interfaces enthalten sind!) ist jetzt der Parameter set vdom zu entfernen. Mit Notepad++ habe ich hier beschrieben, wie das relativ fix geht. Beim Zurückspielen der Konfiguration als Script, ist der Parameter „set vdom“ nicht erforderlich, denn das System setzt diesen Parameter by default auf root, wenn nichts anderes angegeben wird.
- Jetzt gilt es sämtliche Konfigurationsparameter bezüglich HA zu entfernen, dazu einfach nach config system ha suchen und den ganzen Block entfernen, denn die HA config machen wir später…
- nachdem alle notwendigen Anpassungen gemacht sind, die „neue“ Single VDOM Konfiguration als *.conf File speichern.
- Jetzt an der neu konfigurierten Firewall die aktuelle Konfiguration sichern. (für einen schnellen Fallback, falls etwas schief geht)
- Über den Script Import jetzt die neue Konfig laden
- Nach ein paar Tests und Prüfungen sollte jetzt eine „Single VDOM Konfig“ existieren
- Klar, auch wir mussten danach ein paar manuelle Anpassungen vornehmen, aber 99% waren so bereits erledigt…
- Danach setzt man die „alte“ Secondary Unit, die übergangsweise unsere Master Unit war, in den Werkszustand und fügt sie als Secondary Unit dem neuen Single VDOM Cluster hinzu