Archiv der Kategorie: Linux

OpenVPN Server unter MikroTik RouterOS

Ja ja – lange nichts mehr geschrieben. Aber ich lebe noch und habe gerade eine OpenVPN Odyssee mit MikroTik Routern hinter mich gebracht. Warum? Ihr kennt es: Man googelt hoch motiviert nach einem knackigen Howto und entdeckt lauter Blogs, die mit viel Halbwissen gefüllt sind. Man merkt das die meisten noch nie ein OpenVPN unter Linux konfiguriert haben, geschweige denn den Unterschied zwischen TUN und TAP kennen. Sei es drum. Du hast diese Doku gefunden und sollst nicht enttäuscht werden, denn sie funktioniert 🙂
Erst mal die Zertifikate und Schlüssel mit OpenSSL bauen. Zu kompliziert? Stimmt. Dafür gibt es ja auch Easy-RSA. Zuerst die Datei „vars“ editieren und die gewünschten Parameter anpassen:

Dann bosseln wir schnell die benötigten Certs und Keys mit den folgenden Befehlen zusammen:

Zuerst importieren wir die Zertifikate. Die Certs am besten mit WinSCP auf den MikroTik Router kopieren:

OpenVPN-Server-Files-WinSCP

In der Winbox ins System importieren (System > Files > Import):

OpenVPN-Server-Files

Der Buchstabe „K“ erscheint sobald der Key zum passenden Zertifikat gefunden wurde:

OpenVPN-Server-Cert-Import

Jetzt legen wir ein Profil für OpenVPN Server an. Damit bestimmen wir die lokale Server-IP für den OpenVPN Adapter (TUN/TAP) und den IP-Pool der Remote Clients (PPP > Profiles):

OpenVPN-Server-Profiles

IP Pool. Gute Sache. Bevor man diesen auswählen kann, muss er erzeugt werden (IP > Pool):

OpenVPN-Server-IP-Pool

Jetzt kann der eigentliche OpenVPN Server aktiviert werden (PPP > OVPN Server):

OpenVPN-Server-Setup

Zum Einwählen fehlt noch ein Benutzer mit Passwort (PPP > Secrets):

OpenVPN-Server-Secrets

Das war’s jetzt auf dem MikroTik Router. Nun geht’s auf dem WIndows Client weiter. Folgende Dateien und Config in den Programmordner von OpenVPN kopieren:

OpenVPN-Server-Client-1

Hier meine Beispielkonfiguration:

Verbinden uns loslegen:

OpenVPN-Server-Client-1-Einwahl

Kleiner Ping aufs Gateway und das war’s:

Einwahl-mit-zwei-Testclients-Client2

OpenVSwitch Experiment mit Ubuntu und VMware Workstation

openvswitch-logoMotivation? Ich wollte mich etwas in OpenVSwitch einarbeiten. „Nice to know“ halt und dümmer wird man ja auch nicht. Dazu habe Ich auf einem Rechner mit zwei Netzwerkkarten einen Ubuntu LTS 14.04 Server aufgesetzt und diesen mit einem Enlightenment E20 Desktop ausgestattet. Anschliessend noch OpenVSwitch und VMware Workstation installiert. Die Netzwerkschnittstellen wurden in einem einem Bond0 an einen HP Switch als LACP active Trunk angebunden. Zwei interne Ports wurden angelegt, die als Access Port für ein VLAN dienen. Diese dann anschliessend als „vmnet0“ in die virtuelle Ubuntu Test-VM unter Vmware Workstation eingebunden. Hier ein Screenshot vom Setup:
Ubuntu_Test_1

Ich habe erst mal ein Interface in die Bridge eingebunden. Dazu musste ich einen OpenVSwitch  mit dem Hardwareinterface „em1“ erzeugen und dann „vlan100“ und „vlan151“ als interne Ports konfigurieren:
ovs-vsctl add-br br0
ovs-vsctl add-port br0 em1
ovs-vsctl set port em1 trunks=100,151 # wenn man nur spezielle VLANS erlauben will
ovs-vsctl add-port br0 vlan100 tag=100 — set interface vlan100 type=internal

ovs-vsctl add-port br0 vlan151 tag=151 — set interface vlan151 type=internal

Nun kann man sich den VSwitch und seine Konfiguration anzeigen lassen. In diesem Screenshot sieht man die erst später erzeugte Bond/Trunk Konfiguration:
ovs-vsctl show
Ubuntu_Test_2_lacp

Danach das gleiche Setup mit zweitem Interface und LACP zum HP Switch konfigurieren. Dazu muss das bereits hinzugefügte Interface „em1“ zuerst entfernt und neu im „bond0“ hinzugefügt werden:
ovs-vsctl del-port br0 em1
ovs-vsctl add-bond br0 bond0 eth0 em1 lacp=active  

Nun wieder die erstellte Konfiguration anzeigen lassen und prüfen mit
ovs-appctl lacp/show bond0

Auf dem HP Switch wird der LACP Trunk sofort als aktiv angezeigt:
Ubuntu_Test_4_lacp Ubuntu_Test_3_lacp

Let’s Encrypt unter Ubuntu mit Apache / Postfix / Dovecot

Kurz notiert für die Freunde der SSL Verschlüsselung: Let’s Encrypt ist am Start in der Public Beta. Ich habe mir direkt mal ein Zertifikat für klehr.de ausstellen lassen und eingebunden. Dazu wird ein Client installiert mit dem man den CSR ausstellt. Die Anforderung muss von der Server-IP gesendet werden, worauf der A-Record der Domaine.tld zeigt! Alles andere wird mit einem „urn:acme:error:unauthorized :: The client lacks sufficient authorization“ abgelehnt.

Zuerst benötigt man GIT auf dem Server:
apt-get install git
Dann zieht man sich das aktuelle Letsencrypt Verzeichnis:
git clone https://github.com/letsencrypt/letsencrypt
Nun wechselt man in das angelegte Verzeichnis und führt das „letsencrypt-auto“ Script aus:
./letsencrypt-auto certonly –standalone -d domaine.tld -d www.domaine.tld -d mail.domaine.tld
Es wird nun unter /etc ein Ordner „letsencrypt“ erzeugt mit dem Zertifikat und privaten Schlüssel:
root@ubuntu / # l /etc/letsencrypt/live/domaine.tld/
1575405 lrwxrwxrwx 1 root root   32 Dec  4 08:43 cert.pem -> ../../archive/domaine.tld/cert1.pem
1575407 lrwxrwxrwx 1 root root   33 Dec  4 08:43 chain.pem -> ../../archive/domaine.tld/chain1.pem
1575408 lrwxrwxrwx 1 root root   37 Dec  4 08:43 fullchain.pem -> ../../archive/domaine.tld/fullchain1.pem
1575406 lrwxrwxrwx 1 root root   35 Dec  4 08:43 privkey.pem -> ../../archive/domaine.tld/privkey1.pem

Jetzt kann man seinen Apache Webserver und/oder Mailserver mit diesen neuen Zertifikaten bestücken. z.B. in der Apache SSL Konfiguration:
SSLCertificateFile      /etc/apache2/sites-available/domaine.tld/cert.pem
SSLCertificateKeyFile   /etc/apache2/sites-available/domaine.tld/privkey.pem
SSLCACertificateFile /etc/apache2/sites-available/domaine.tld/fullchain.pem

Mehr Infos unter https://letsencrypt.org/howitworks/

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.

Docker – First Steps Tutorial

Docker-VMwareDocker ist eine Open-Source-Software, die beim Linux-Betriebssystem dazu verwendet werden kann, Anwendungen mithilfe von Betriebssystemvirtualisierung in Containern zu isolieren. Dies vereinfacht einerseits die Bereitstellung von Anwendungen, weil sich Container, die alle nötigen Pakete enthalten, leicht als Dateien transportieren und installieren lassen. Andererseits gewährleisten Container die Trennung der auf einem Rechner genutzten Ressourcen, sodass ein Container keinen Zugriff auf Ressourcen anderer Container hat (Quelle: Wikipedia). Beginnen wir mit der Installation der aktuellen Docker Version:

Den ersten Container erzeugen wir, in dem wir eine BASH im Container starten:

Da das Image von Ubuntu noch nicht vorhanden ist, wird dieses per PULL von Docker.io gezogen und anschließend durch die Parameter -i und -t eine Shell geöffnet. In dieser Shell installieren wir nun per APT-GET den Apache2 Webserver:

Diese jetzt getätigten Änderungen müssen in das Baseimage gesichert werden durch einen Commit. Ich Vergleiche hier Docker gerne mit Subversion für das Betriebssystem 😉 Den letzten laufenden Container kann man sich mit docker ps -l anzeigen lassen. Diese ID commited man nun und erzeugt so sein eigenes Image:

Die installierte Software (Apache2) in dem jetzt erzeugten Image kann man nun starten:

Die Besonderheit: Apache2 kann nicht über das Startscript in /etc/init.d ausgeführt werden, sondern nur über apache2ctl. Stopt man nun diesen Container, sind die erzeugten Daten (z.B. von WordPress) im /var/www Ordner weg. Damit das nicht passiert, kann man in Docker „Volumes“ einbinden, die solche Änderungen lokal im System speichern. Dazu erzeugen wir einen Ordner im Filesystem der über docker run in den Container „gemounted“ wird.

Zur Überprüfung, ob der lokale Ordner auch genutzt wird, legen wir im lokalen Speicher eine „index.html“ ab. Diese sollte dann bei einem Seitenaufruf angezeigt werden.

docker-datastore

Wenn unser Container zufriedenstellend läuft, kann man ihn ex- und auf einem anderen System importieren. Unabhängig von dem genutzten Linux auf dem Host!

Hier noch ein interessanter Link zu einem Artikel in den VMware Blogs zu Docker. Für die ersten Schritte empfehle ich das wirklich gut gemachte online Tutorial auf der Webseite von Docker.