Hier wieder eine kleine Quickdoku wie man einen APU2C4 Bausatz assembliert und mit pfSense installiert. So wird der Bausatz geliefert und los geht’s:
Kühlung anbringen:
mSATA einsetzen:
Jetzt kann das System installiert werden. Dazu benötigen wir von der Webseite des Herstellers das „TinyCore Linux“ , welches mittels USB Stick gebootet wird. Zuerst muss die Datei „apu2-tinycore6.4-usb-installer.exe“ geladen und ausgeführt werden. Das Setup wird das TinyCore Linux auf einem leeren USB Stick installieren. Das Image von pfSense wird im Anschluss auf den USB Stick kopiert und nach dem booten des TinyCore Linux auf die mSATA geschrieben. Der Bootvorgang und die erste Bedienung des Boards erfolgt mit der seriellen Schnittstelle (115200 Baud 8n1). Als Terminalprogramm nutze ich Teraterm.
Mit „fdisk -l“ lassen wir uns die Partitionen anzeigen. In meinem Fall wird die mSATA unter /dev/sda gefunden:
Nun das Image mit dem Befehl „gzip -dc pfSense-CE-2.3.2-RELEASE-4g-amd64-nanobsd.img.gz | dd of=/dev/sda bs=1M“ auf die mSATA Partition schreiben:
Wenn das Image geschrieben worden ist, das System mit „poweroff“ herunterfahren, den USB Stick entfernen und die pfSense Firewall zum ersten Mal starten und mit der Grundeinrichtung beginnen….. Leider muss die pfSense Firewall beim ersten Bootvorgang mit dem Internet verbunden sein, denn sonst wird die Prüfung des Paketmanagers in einer Schleife „hängen“ bleiben. Zum Glück hatte ich gerade noch einen Mikrotik Router am Netz hängen den ich schnell als Gateway bereitstellen konnte:
Das wars….. Nun können wir das System über die WebGUI verwalten:
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:
|
1 2 3 4 5 6 7 8 9 |
# These are the default values for fields # which will be placed in the certificate. # Don't leave any of these fields blank. export KEY_COUNTRY="DE" export KEY_PROVINCE="Saarland" export KEY_CITY="Saarbruecken" export KEY_ORG="MikroTik Router" export KEY_EMAIL="noreply@mikrotik.local" export KEY_OU="IT" |
Dann bosseln wir schnell die benötigten Certs und Keys mit den folgenden Befehlen zusammen:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
cd /usr/share/easy-rsa/ source vars NOTE: If you run ./clean-all, I will be doing a rm -rf on /usr/share/easy-rsa/keys ./build-ca # CA erstellen ./build-key-server mikrotik # Server Zertifikat ./build-key client1 # Client Zertifikat (am besten mehrere erstellen) Inhalt von "Keys": /snip/ 538098 -rw-r--r-- 1 root root 1809 Jul 11 11:33 ca.crt 538097 -rw------- 1 root root 1704 Jul 11 11:33 ca.key 538108 -rw-r--r-- 1 root root 5591 Jul 11 11:34 client1.crt 538107 -rw-r--r-- 1 root root 1094 Jul 11 11:34 client1.csr 538106 -rw------- 1 root root 1704 Jul 11 11:34 client1.key 538113 -rw-r--r-- 1 root root 5591 Jul 11 11:34 client2.crt 538096 -rw-r--r-- 1 root root 1094 Jul 11 11:34 client2.csr 538094 -rw------- 1 root root 1708 Jul 11 11:34 client2.key 538101 -rw-r--r-- 1 root root 5715 Jul 11 11:33 mikrotik.crt 538100 -rw-r--r-- 1 root root 1094 Jul 11 11:33 mikrotik.csr 538099 -rw------- 1 root root 1704 Jul 11 11:33 mikrotik.key |
Zuerst importieren wir die Zertifikate. Die Certs am besten mit WinSCP auf den MikroTik Router kopieren:
In der Winbox ins System importieren (System > Files > Import):
Der Buchstabe „K“ erscheint sobald der Key zum passenden Zertifikat gefunden wurde:
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):
IP Pool. Gute Sache. Bevor man diesen auswählen kann, muss er erzeugt werden (IP > Pool):
Jetzt kann der eigentliche OpenVPN Server aktiviert werden (PPP > OVPN Server):
Zum Einwählen fehlt noch ein Benutzer mit Passwort (PPP > 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:
Hier meine Beispielkonfiguration:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
remote 10.1.1.65 1194 proto tcp-client dev tun resolv-retry infinite nobind persist-key persist-tun tls-client ca ca.crt cert client1.crt key client1.key auth-user-pass ping 10 verb 3 cipher AES-256-CBC auth SHA1 pull # Hier die lokalen Routen eintragen die in den Tunnel gehen sollen route 10.8.111.0 255.255.255.0 10.8.10.1 |
Verbinden uns loslegen:
Kleiner Ping aufs Gateway und das war’s:
Sophos UTM mit IPsec „Hub and Spoke“
Um die Realisierbarkeit eines Projektes zu überprüfen, habe ich einen Testaufbau mit einem „Hub and Spoke“ Szenario durchgeführt. Bei „Hub and Spoke“ wird der Traffic von einer per IPsec angebundenen Außenstelle (Remote Office) zur anderen über eine Zentrale Instanz (Main Office) weitergeleitet. Hier der schnell entworfene Plan und danach die Umsetzung:
Man muss lediglich das entfernte Remote Office in die Remote IPsec Konfiguration einfügen. Bei der Definition im Main Office als auch bei der Außenstelle muss das Netzwerk der entfernten Außenstelle eingetragen werden. Zum Beispiel wenn der Traffic von Sophos-3 zu Sophos-2 über Sophos-1 geleitet werden soll.
Hier die Definition im Main Office als Respond Only:
Die Definition auf Sophos-3 mit Initiate Connection:
Nun wird der Tunnel aufgebaut und die IPsec SA für die entfernte Außenstelle ist enthalten:
Im Main Office sind zwei Tunnel zu den Außenstellen aufgebaut. Der Traffic von Sophos-2 zu Sophos-3 wird durch den IPSEC Tunnel über das Main Office Sophos-1 geleitet:
OpenVSwitch Experiment mit Ubuntu und VMware Workstation
Motivation? 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:
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
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:
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/