Ein gut gemachter Lehrgang bei IKU Systems wurde erfolgreich beendet. Ab heute darf ich mich Sophos UTM Certified Engineer nennen 🙂
Archiv für den Monat: März 2015
Fortigate VM Laborsetup mit Multi-WAN und IPSEC Failover mit OSPF
Da 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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
config system interface edit port1 set ip 10.1.1.62 255.255.255.0 append allowaccess http end config router static edit 1 set device port1 set gateway 10.1.1.1 end config system dns set primary <Primary DNS server> set secondary <Secondary DNS server> end |
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:
Nach der Konvertierung in einen „Custom Tunnel“ bleiben jedoch keine Wünsche offen. Hier kann der advanced Admin alles Einstellen was das Herz begehrt:
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!
Diesem Interface muß natürlich noch eine Point-2-Point Adresse konfiguriert werden:
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:
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:
Linux High Availability Cluster mit Corosync, Pacemaker und GlusterFS
Nach 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:
|
1 2 |
apt-get update apt-get install glusterfs-server |
Die beiden Memberserver des HA Clusters sollten in der /etc/hosts Datei hinterlegt werden, falls DNS Abfragen nicht möglich sind.
|
1 2 3 |
root@glusterfs1:~ > cat /etc/hosts 10.1.1.109 glusterfs1.domain.com glusterfs1 10.1.1.142 glusterfs2.domain.com glusterfs2 |
Nun erzeugen wir einen Mountpoint wo GlusterFS seine Daten ablegt. In diesem Verzeichnis darf nichts geschrieben werden! Es wird nur von GlusterFS bedient!
|
1 |
mkdir -p /mnt/glusterfs |
Diese Einstellungen müssen natürlich auch auf dem zweiten Host vorgenommen werden. Nun erstellen wir ein gespiegeltes Volume mit Namen configstore:
|
1 |
gluster volume create configstore replica 2 transport tcp glusterfs1:/mnt/glusterfs glusterfs2:/mnt/glusterfs force |
Da der Mountpoint im Filesystem liegt muss der Parameter force genutzt werden. Eine kurze Statusabfrage gibt uns alle Infos zum GlusterFS Dateisystem:
|
1 2 3 4 5 6 7 8 9 10 |
root@glusterfs1:/ > gluster volume status Status of volume: configstore Gluster process Port Online Pid ------------------------------------------------------------------------------ Brick glusterfs1:/mnt/glusterfs 49152 Y 949 Brick glusterfs2:/mnt/glusterfs 49152 Y 951 NFS Server on localhost 2049 Y 954 Self-heal Daemon on localhost N/A Y 960 NFS Server on 10.1.1.142 2049 Y 956 Self-heal Daemon on 10.1.1.142 N/A Y 961 |
Dieses gespiegelte Volume können wir mit dem glusterfs-client einbinden:
|
1 |
apt-get install glusterfs-client |
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:
|
1 2 |
mkdir -p /mnt/config mount -t glusterfs glusterfs1:configstore /mnt/config |
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:
|
1 |
apt-get install pacemaker |
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:
|
1 2 3 4 5 6 7 |
interface { # The following values need to be set based on your environment ringnumber: 0 bindnetaddr: 10.1.1.109 mcastaddr: 226.94.1.1 mcastport: 5405 } |
Anschliessend „yes“ in der Corosync Default Datei setzen für den Autostart:
|
1 2 3 |
root@glusterfs1:~ > cat /etc/default/corosync # start corosync at boot [yes|no] START=yes |
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
root@glusterfs1:/ > crm_mon -1 Last updated: Tue Mar 17 14:54:46 2015 Last change: Tue Mar 10 15:30:01 2015 via crm_resource on glusterfs2 Stack: corosync Current DC: glusterfs2 (167838094) - partition with quorum Version: 1.1.10-42f2063 2 Nodes configured 2 Resources configured Online: [ glusterfs1 glusterfs2 ] postfix (ocf::heartbeat:postfix): Started glusterfs1 virtual-ip (ocf::heartbeat:IPaddr2): Started glusterfs1 |
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:
|
1 2 3 4 5 6 |
primitive postfix ocf:heartbeat:postfix meta target-role="Started" primitive virtual-ip ocf:heartbeat:IPaddr2 params ip="10.1.1.251" nic="eth0" cidr_netmask="24" op monitor interval="10s" meta is-managed="true" property stonith-enabled=false no-quorum-policy="ignore" |
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:
|
1 2 3 |
cd /etc/ mv postfix postfix-original ln -s /mnt/config/etc/postfix . |
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.