Archiv für den Monat: März 2015

Fortigate VM Laborsetup mit Multi-WAN und IPSEC Failover mit OSPF

fortinet-logo2Da ich wohl in Zukunft vermehrt mit Produkten von Fortinet arbeiten werde, habe ich mich entschlossen ein Laborsetup unter VMware zu installieren und Fortigate als VM Appliance ausgiebig zu testen. Der geneigte Leser kennt sicherlich meine Vorliebe für Multi-WAN, IPSEC und OSPF basierende Testaufbauten 😉 Warum also hier was anderes als Spielwiese nehmen? Als erste Hürde muß man jedoch erst mal einen Testkey über einen Fortinet-Partner besorgen. Denn ohne das man einen Key im Portal registriert, kann man die VM nicht downloaden.
Nach erfolgreichem Download war ich überrascht, dass gerade mal schlanke 33 MB OVF Vorlage ausreichen sollten, um eine virtuelle Firewall zu erzeugen. Das Bereitstellen war ein Kinderspiel und schon in wenigen Sekunden war die erste Fortigate Appliance bereit für die Grundeinrichtung. Hierzu schnell eine kleine Textbox wie man die IP, DNS und Gateway über die CLI einstellt. Dies ist sehr wichtig, denn die Fortigate Firewall will den Registrierungskey über das Internet auf den Fortinetservern überprüfen. Vorher kann man mit der Appliance nicht arbeiten. Der erste Login ist „admin“ mit leerem Passwort.

Nun kann man sich über die HTTP Weboberfläche anmelden und den Lizenzkey uploaden. In vielen Setups werden die Firewalls direkt mit einem L2 Netz verbunden um das WAN zu simulieren. Ich nutze hier wie immer eine Ubuntu VM als virtuellen L3 Router mit vier Interfaces und vier getrennten Subnetzen. Nur so kann man testen ob IPSEC und OSPF richtig zusammenarbeiten. Ich hatte schon öfters gesehen das OSPF über die normale L2 Verbindung geroutet hat und die Admins in dem falschen Glauben waren es würde über den IPSEC Tunnel gehen. Bauen wir zunächst zwischen den beiden Fortigates eine VPN Verbindung auf. Der Wizard macht das zum Kinderspiel:

VPN-Wizard

Nach der Konvertierung in einen „Custom Tunnel“ bleiben jedoch keine Wünsche offen. Hier kann der advanced Admin alles Einstellen was das Herz begehrt:

VPN-Wizard-2

Nachdem wir zwei Tunnel zwischen jeweils zwei WAN Interfaces erstellt haben können wir fortfahren….. Für OSPF benötigt man immer ein L2 Device. Dieses wird meistens durch einen GRE Tunnel bereitgestellt. Nach dem der VPN Tunnel über den Wizard erstellt wurde, findet man unter System > Network > Interfaces ein „Tunnel-1“ Interface. Ich nehme an, das es sich hierbei um ein GRE Interface handelt. Bitte korrigiert mich über die Kommentarfunktion!

Interface_Tunnel1

Diesem Interface muß natürlich noch eine Point-2-Point Adresse konfiguriert werden:

Interface_Tunnel1-p2p

Nun haben wir zwischen den beiden Fortigates einen IPSEC Tunnel mit zwei Tunnelendpunkten. Diese werden im nächsten Schritt für das OSPF benötigt. Unter Router > Dynamic > OSPF legen wir einfach mal eine Backbone Area an und nehmen die Interfaces des Tunnels und vom internen Netz darin auf. Warum an das Tunnel Netzwerk unter Networks anlegen muß erschliesst sich mir noch nicht so ganz. Dadurch das das Interface in der Area vorhanden ist, sollte dieses Netzwerk automatisch redistributiert werden. Achja – wir wählen Connected bei Redistribute an, damit werden die internen Netze ins OSPF weitergegeben:

OSPF-1

Nun hat man ein redundantes IPSEC VPN mit dynamischem Routing aufgebaut. Viel Spaß beim Testen! Nachlesen kann man das ganze in der KB von Fortinet. Hier muß ich mal ein Lob aussprechen: Die Dokumentation ist gegenüber anderen Anbietern vorbildlich geführt und mit vielen Beispielen versehen (Hallo Sophos!).
Authorisierter Fortinet Partner im Saarland ist die KFK GmbH. Bitte fragen Sie hier nach Testkeys und Angeboten für die Umsetzung in ihrem Netzwerk:

KFK-Logo

Linux High Availability Cluster mit Corosync, Pacemaker und GlusterFS

HA-PacemakerNach langer Zeit habe ich mal wieder ein High Availability Projekt mit Linux HA auf dem Operationstisch. Diesmal verwende ich Corosync und Pacemaker zur Umsetzung und GlusterFS als distributed Filesystem um die Configs bereitzustellen. Sonst erledigt das DRBD, aber ich wollte halt mal was anderes ausprobieren. Dazu benötigen wir natürlich erst mal zwei Ubuntu Server. Logisch. Für den Anfang wählen wir das einfache Active/Passive Setup.

Zunächst installieren wir auf dem ersten Node das GlusterFS:

Die beiden Memberserver des HA Clusters sollten in der /etc/hosts Datei hinterlegt werden, falls DNS Abfragen nicht möglich sind.

Nun erzeugen wir einen Mountpoint wo GlusterFS seine Daten ablegt. In diesem Verzeichnis darf nichts geschrieben werden! Es wird nur von GlusterFS bedient!

Diese Einstellungen müssen natürlich auch auf dem zweiten Host vorgenommen werden. Nun erstellen wir ein gespiegeltes Volume mit Namen configstore:

Da der Mountpoint im Filesystem liegt muss der Parameter force genutzt werden. Eine kurze Statusabfrage gibt uns alle Infos zum GlusterFS Dateisystem:

Dieses gespiegelte Volume können wir mit dem glusterfs-client einbinden:

Im Ordner /mnt legen wir einen Ordner config an, den wir nachher mit Symlinks als Speicherort für die Konfigurationen nutzen. Dorthin mounten wir das GusterFS Volume:

Jetzt gehts weiter mit dem eigentlichen HA Cluster. Auf beiden Nodes wird „Pacemaker“ installiert. Corosync wird als Abhängigkeit mitinstalliert und dienst als Kommunikationsdienst für Pacemaker der die Clusterressourcen verwaltet:

Die einzige Anpassung für Corosync nehmen wir in der /etc/corosync/corosync.conf vor. Und zwar das Interface auf dem Corosync laufen/hören soll:

Anschliessend „yes“ in der Corosync Default Datei setzen für den Autostart:

Und schon können wir Corosync mit service corosync start starten. Das gleiche wieder auf dem zweiten Node durchführen. Klar, oder? Kurzer Check ob alles läuft mit crm_mon -1. Der Parameter -1 ruft den Status nur einmal auf.

Wie man sieht habe ich jetzt schon etwas vorgegriffen. Der Mailserver „Postfix“ läuft als Dienst auf beiden Nodes und es kommt eine virtuelle shared IP zum Einsatz. Pacemaker als Clusterdienst wird ganz einfach (gegenüber Heartbeat V1)  per CLI konfiguriert. Man nehme crm configure und los gehts:

Der Postfix Dienst muß natürlich aus allen Runleveln entfernt werden. Darum kümmert sich ab jetzt Pacemaker. Die Ressource-Scripte liegen im Ordner /usr/lib/ocf/resource.d/heartbeat. Man sieht schon wie der Syntax in der Config aufgebaut ist: ocf:heartbeat:postfix. In diesem Ordner kann man auch eigene Scripte hinterlegen die man in Pacemaker einbinden kann.

Damit Postfix seine Konfiguration von beiden Knoten aus abrufen kann, setzt man einen symbolischen Link in das GlusterFS Volume:

Nun liegt die Konfiguration zentral im shared Volume unter /mnt/config/etc/postfix und kann bei einem Ausfall des Primärknotens vom Backupknoten aufgerufen werden. Unter /mnt/config/etc/ könnte man nun weitere Konfigurationen für andere Dienste bereitstellen die mit Pacemaker abgesichert sind. Auch Daten wie Webseiten für Apache oder IMAP Maildirs für Mailserver. Bei Datenbanken würde ich dann doch eher zum blockbasierenden  DRBD raten. Ich hoffe das war ein kurzer inspirierender Ausflug in die Welt von High Availability unter Linux. Jetzt gilt es: ausprobieren, ausprobieren und nochmal ausprobieren! So leicht das auch aussieht – man sollte seinen Cluster kennen und im Notfall auch routiniert bedienen können.