Ich und andere Autoren des IT-Kitchens sind regelmäßige Nutzer von Docker. Es erlaubt uns auf einfache Art und Weise viele Serverprogramme und sonstige Tools ohne komplizierte Installationsprozesse und isoliert in ihrer eigenen Laufzeitumgebung aufzusetzen.

Voraussetzung für das einfache Aufsetzen von Programmen ist jedoch, dass für diese Programme ein sogenanntes Image existiert. In diesem Image ist zusammen mit dem Programm auch alles vorinstalliert was das Programm braucht um ihren Job zu erfüllen. Wenn man Glück hat, gibt es so ein Image bereits vorgebaut in einem Repository wie dem Docker Hub. Ansonsten muss man selber so ein Image bauen, und das ist nun mal ein Prozess für sich.

In diesem Beitrag geht es um den Teil des Prozesses, der sich damit befasst, ein eigens geschriebenes Image zu optimieren, so dass wirklich nur das was man braucht und nicht mehr vorinstalliert ist. Ein typisches Szenario wäre zum Beispiel das Bauen einer JavaScript-basierten Web-App vom Quelltext.

Unsere App die wir bauen wollen benötigt eine Installation von Node.js und dessen Paketverwaltung NPM. Mit NPM werden alle in der App notierten Abhängigkeiten nachinstalliert, die für das Erzeugen von HTML-, JavaScript- und CSS-Dateien für den Browser benötigt werden. Diese Tools sind allerdings nur zur Bauzeit, und nicht zur Laufzeit notwendig!

Alte Methode: Step by step

Es gibt mehrere Wege dieses Problem nun anzugehen. Entweder baut man einmal die App und schifft dann das komplette Verzeichnis mit, ohne sich weiter Gedanken darum zu machen. Das hat den offensichtlichen Nachteil, dass der gesamte Quelltext samt nun unnötiger Entwicklungsumgebung und sonstigen eventuell übergroßen Ressourcen in dem Image mitgeliefert werden. Wir haben auch das Problem, dass wir uns zwischen dem nginx und dem node Image als Basis entscheiden müssen - das Nginx-Image bringt mit sich, dass wir Node und NPM extra nachinstallieren müssen mit potenziellem Verlust von Versionsfixierung, und das Node-Image würde wieder erzwingen, dass wir einen Teil der Entwicklungsumgebung im Image mitliefern und der Webserver muss auch noch extra mitinstalliert werden.

FROM nginx:stable

# Installiere Node.js (mit NPM) - benötigt curl und gnupg
RUN apt-get update
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y curl gnupg
RUN curl -sL https://deb.nodesource.com/setup_8.x | DEBIAN_FRONTEND=noninteractive bash -
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y nodejs

WORKDIR /source/

# Kopiere Quelldateien aus aktuellem Ordner nach /source/ wo wir jetzt drin sind
COPY . .

# Installiere Abhängigkeiten
RUN npm install

# Baue die App mittels eines NPM-Skripts mit Namen "build:production"
RUN npm run build:production

# Erzeugte Dateien an richtige Stelle verschieben
RUN rm -r /usr/share/nginx/html/
RUN mv dist /usr/share/nginx/html

Alte Methode: Alles in einem Layer

Man kann aber auch alle Befehle um das Image zu bauen in einen einzigen Schritt zusammenfassen, aus dem nachher nur ein zusätzliches Layer auf dem Basis-Image generiert wird. Zusätzlich zu den nun zusammengefassten Bauschritten werden aber nun auch Aufräumbefehle wie apt-get clean oder rm -r /path/to/source angehängt, um unnötige Dateien loszuwerden. Damit verlieren wir aber die Möglichkeit unsere Bauschritte zu cachen um zukünftige Builds schneller und inkrementell laufen zu lassen, und die Probleme von oben schleppen wir immer noch mit uns herum. Außerdem können wir nun unsere Schritte nicht mehr zeilengenau in Form von Kommentaren dokumentieren und müssen uns mit Backslash-basierten Abtrennungen zufrieden geben.

FROM nginx:stable

# 1. Installiere Node (mit NPM) - benötigt curl und gnupg
# 2. Installiere Abhängigkeiten & baue App
# 3. Verschiebe dist-Dateien zu Nginx-HTML-Dokumentenpfad
# 4. Aufräumen des Images

COPY . src/
RUN export DEBIAN_FRONTEND=noninteractive \
    && apt-get update \
    && apt-get install -y curl gnupg \
    && (curl -sL https://deb.nodesource.com/setup_8.x | bash -) \
    && apt-get install -y nodejs \
\
    && (cd ./src \
        && npm install \
        && npm run build:production \
    ) \
\
    && rm -r /usr/share/nginx/html/ \
    && mv ./src/dist /usr/share/nginx/html \
\
    && apt-get autoremove -y --purge nodejs \
    && apt-get clean \
    && rm -rf \
        ./src \
        /var/tmp/* \
        /tmp/* \
        /var/lib/apt/lists/* \
        /var/cache/apt/archives/*.deb \
        /var/cache/apt/archives/partial/*.deb \
        /var/cache/apt/*.bin

Neue Methode: Bauen in zwei Teilen

Das war bis zu einem bestimmten Zeitpunkt die Standardroutine… bis Docker 17.05 endlich Multi-Stage Builds einführte!

Mit Multi-Stage Builds können wir unser Image jetzt in zwei Sektionen aufspalten, die wir beide wie Images behandeln können. Die erste Sektion ist nur zuständig für die Installation der Entwicklungsumgebung und das Bauen der App. Die zweite Sektion ist dann unser eigentliches Image indem wir nur noch die korrekten COPY-Befehle brauchen um alles an die richtige Stelle zu kopieren. Implizit können wir damit alle Dateien einfach aus dem finalen Image ausschließen, die wir nicht brauchen, und können trotzdem vollständig von dem Caching für jeden Bauschritt Nutzen machen.

In unserem Fall würde das Dockerfile dann so aussehen:

# # # Build-Sektion # # #

FROM node:8 AS builder

# Kopiere Quelldateien und arbeite in neuem source-Ordner
WORKDIR /source/
COPY . .

# Installiere Abhängigkeiten der App und baue die App
RUN npm install
RUN npm run build:production

# # # Finales Image # # #

FROM nginx:stable

# Kopiere Dateien an die richtige Stelle
COPY --from=builder /source/dist/ /usr/share/nginx/html/

Wir sagen Docker damit, dass unsere App in der ersten Sektion mittels dem node-Image auf Versions-Tag 8 gebaut werden soll, und geben dieser Sektion den Namen builder für später. Nachdem wir mit Bauen fertig sind, starten wir eine neue Sektion auf Basis des nginx-Images mit dem Versions-Tag stable indem wir einfach nochmal den FROM-Befehl nutzen. Der einzige Schritt der hier noch ausgeführt wird, ist ein COPY von unserer builder-Sektion den wir mit dem --from-Argument referenzieren. Damit werden unsere fertig gebauten Dateien aus dem dist-Ordner in den Standardpfad für die Nginx-HTML-Dokumente eingefügt und wir haben unser fertiges Image welches nur noch aus dem Basis-Image und unserem Layer mit den kopierten Dateien besteht.

Presto! Ein einfaches, durchoptimiertes Image mit einem sauber geschriebenen Dockerfile.

Da Georg IPv6 auf Proxmox laufen hat und ich soweit nur via Hurricane Electric einen IPv6 Anschluss auf der PfSense realisiert habe, habe ich einen Tipp von einem Freund bekommen wie das nun auch mit ESXi funktioniert!

Hinweis

Solltet ihr bereits andere Tutorials probiert haben, so entfernt bitte alle Änderungen die ihr durch diese gemacht habt.

Diese Anleitung bezieht sich auf ein ESXi 6.5 Host mit Build 5310538, gehostet bei online.net und mit der Standard Konfiguration.
Das Standard Netzwerk Interface ist vmbr0 das auf eth0 bridged.

Wir verwenden hierbei den von online.net zugewiesenen /48 Block bzw. den davon abgeleiteten /56

In dieser Anleitung verwenden wir folgenden IPv6-Block:

2001:bc8:36df:ff00:: /56

Noch bevor wir am Host arbeiten können müssen wir uns, falls noch nicht geschehen ein IPv6 Block kostenfrei ordern und davon ein /56 Subnet. Wie? Hierzu verweise ich auf das online.net Wiki.

1. DUID Datei generieren

Da online.net mit DUIDs arbeitet, müssen wir die DUID, die im Controlpanel angezeigt wird konvertieren.
Am Besten funktioniert dies mit einer Linux Maschine:
echo 00:03:XX:XX:... | awk '{ gsub(":"," "); printf "0: 0a 00 %s\n", $0 }' | xxd -r > dhcp6c_duid

Am Schluss überträgt man die Datei via SFTP auf die pfSense in den Ordner /var/db

2. Einstellungen von pfSense

Da es nicht so viel einzustellen gibt, habe ich ein paar Screenshots von meinem Setup gemacht. Diese am Besten anschauen und entsprechend anpassen (IPs und Regeln).

Wichtig hierbei ist, dass IPv6 aktiviert ist. Dies könnt ihr unter System->Advanced->Networking nachschauen:

Nun meine WAN und LAN Konfiguration:

Nun noch sichern und es sollte funktionieren.

Um nun Regeln anzulegen müsst ihr diese Regeln in WAN einpflegen:

In diesem Beitrag gehe ich darauf ein wie man zwischen einer IPFire und einem Raspberry Pi eine OpenVPN Netz-zu-Netz-Verbindung herstellt.

Mein Anwendungszweck

Vorweg ich habe Zuhause eine Fritz!Box und habe auch nicht vor mir eine IPFire Hardware-Appliance anzuschaffen, weil ich für mich persönlich keinen Mehrwert darin sehe, welcher die ca. 200€ teure Hardware rechtfertigen würde.
Ich betreibe eine virtualisierte Serverumgebung hinter einer IPFire und möchte auf diese zugreifen können, ohne jedes mal die VPN-Verbindung von meinem PC aus aufbauen zu müssen.

Vorbereitung

• RaspberryPi mit Raspian und root Zugriff
• Fritz!Box o.ä. (Muss Port Forwarding und statisches Routing beherrschen, ggf. DynDNS)
• root Zugriff auf die IPFire (mit statischer öffentlicher IP-Adresse) und OpenVPN Server konfiguriert

Anmerkung

Anstatt des Raspberry PI’s kann auch ein (alter) PC mit Debian o.ä. benutzt werden.

Theorie

Wir haben auf der einen Seite eine IPFire (in meinem Fall virtuell).

Red0 ist als externes Interface konfiguriert, mit einer öffentlichen IP-Adresse. An green0 liegt das lokale Netz mit der Netzadresse 10.0.0.0/24 an.

Auf der anderen Seite einen Raspberry PI hinter einer Fritz.Box. Ankommende TCP und UDP Pakete bei der Fritz!Box auf Port 1195 werden an den Pi geforwarded. Anschließend wird eine statische Route eingetragen welche darauf verweist das alle Pakete mit dem Ziel 10.0.0.0/24 an den Pi geschickt werden.

Nach erfolgreicher Konfiguration werden die Pakete folgenden Weg nehmen:

PC ➔ Fritz!Box ➔ Raspberry PI –Open VPN Tunnel➔ IPFire ➔ Ziel

Rückweg:

Quelle ➔ IPFire –OpenVPN Tunnel ➔ Raspberry PI ➔ PC

Die lokalen IP-Adressbereiche werden im jeweils anderen LAN geroutet.

Kein Source-NAT etc…

RaspberryPi

Zunächst benötigt der Pi eine statische IP-Adresse, dies kann über 2 Methoden realisiert werden

• Statische IP-Adresse am Pi festlegen

    bash:~$ nano -w /etc/network/interfces
  

• Den Inhalt der Datei durch folgenden ersetzen:

    auto lo eth0
    iface lo inet loopback
  
    iface eth0 inet static
    address 192.168.2.100
    netmask 255.255.255.0
    network 192.168.2.254
    broadcast 192.168.2.255
    gateway 192.168.2.1
  

Anmerkung: Die Adressen sind entsprechend anzupassen.

• DHCP anweisen diesem Gerät jedes mal die gleiche IP-Adresse zuzuweisen (Beispiel FRITZ!Box)
• Webinterface der FRITZ!Box aufrufen (fritz.box)
• Heimnetz ➔ Netzwerk

In dieser Liste dann den Pi heraussuchen, er sollte am Hostname erkennbar sein.
Dann diesen Eintrag bearbeiten und den Haken bei Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen. setzen.


Anschließend wird noch die Paketliste aktualisiert und OpenVPN + Screen installiert. Dies erledigen wir mit folgendem Befehl:

bash:~$ apt-get update && apt-get install openvpn screen -y

Zuletzt und ganz wichtig muss im Kernel noch das Routing aktiviert werden. Dazu öffnen wir die Kernel Konfigurationsdatei:

bash:~$ nano -w /etc/sysctl.conf

Fügen folgende Zeile hinzufügen:

net.ipv4.ip_forward = 1

Und dann die Konfiguration des Kernels neu laden mit folgendem Befehl:

bash:~$ sysctl -p /etc/sysctl.conf

Fritz!Box

Nun passen wir unsere Fritz!Box (o.ä.) an, ich werde nur auf die Konfiguration bei der Fritz!Box eingehen.

• Was muss getan werden?
• Statische Route
• Port-Forwarding
• Falls benötigt DynDNS

Beginnen wir mit dem Routing.

Wozu statisches Routing?

Weil, alle Clients im Heimnetzwerk als Gateway die Fritz!Box angegeben haben. Nun möchten wir an unserem PC z.B. eine SSH-Verbindung zu unserer IPFire herstellen.
Wir geben in unserem SSH-Klienten unsere Ziel-IP ein z.B. 10.0.0.1 nun sieht der PC „Hey, das Ziel befindet sich nicht in meinem LAN, also ab zum Standardgateway (Fritz!Box) mit meinem Paket“.
Genau hier tritt das statische Routing ein, dadurch weiß nämlich die Fritz!Box „Hey, das schicke ich nicht ins Internet, sondern zu der und der IP (in unserem Fall der Raspberry Pi)“.
Dann ist unser Paket dort angelangt wo es hin soll.

Alternativ kann man auch eine statische Route am PC eintragen und diese mit einem Script bei jedem Start des PC’s ausführen lassen, aber wir machen es mit statischem Routing an der Fritz!Box, somit kommt man auch wenn man mal am Laptop ist überall drauf ohne Routen einzutragen.

Nach so viel Theorie ab zur Praxis!

Port-Forwarding

Unser Pi muss unter den öffentlichen IP-Adresse der Fritz!Box erreichbar sein, deshalb leiten wir Port 1195 TCP und UDP auf den Pi.

• Webinterface der FRITZ!Box aufrufen (fritz.box)
• Internet
• Freigaben
• Neue Portfreigabe
  
  Das Feld an Computer anpassen, dort müsst Ihr den Hostnamen eures PI’s her raussuchen, die IP-Adresse wird dann automatisch angepasst.
  

Selbiges dann nochmal für TCP.

Dyn-DNS

Dynamic-DNS ist von Nöten wenn ihr keine statische IP-Adresse besitzt. Wenn ihr euch sicher seit, dass ihr eine statische IP-Adresse habt dann könnt ihr diesen Part überspringen.

FritzOS bringt von Haus aus einen DynDns mit um diesen zu aktivieren geht man wie folgt vor:

• Webinterface der FRITZ!Box aufrufen (fritz.box)
• Internet
• Freigaben
• Fritz!Box-Dienste
• Internetzugriff
  
  Dort setzt Ihr den Toggle bei Internetzugriff auf die Fritz!Box für HTTPS aktiviert
  Daraufhin speichern, dann wird euch in der Zeile Internetadresse Ihrer FRITZ!Box eure DynDns Domain angezeigt.
  Das https:// ist für uns uninteressant, wir brauchen nur xxxxxxxxxxxxxxxxxx.myfritz.net.

IPFire

• Webinterface der IPFire öffnen

• Dienste

• OpenVPN

• Hinzufügen
  
  Wir wollen eine Netz zu Netz Verbindung, also klicken wir dementsprechend den RadioButton und anschließend auf hinzufügen.
  
  Danach muss die Verbindung konfiguriert werden.

• Name: Wie gewünscht, in den Beispielen verwende ich den Namen „n2n“

• Konfiguriert als: OpenVPN-Server

• Lokales Subnet: Ist das Subnet in der sich die IPFire befindet

• OpenVPN Subnet: Kann frei gewählt werden (darf sich aber nicht mit Lokalen- oder Remotesubnet überschneiden)

• Ziel-Port: 1195

• Remote Host/IP: Statische externe IP der Fritz.Box oder DynDyn der Fritz.Box (xxxxxxxxx.myfritz.net)

• Remote Subnet: Subnet in dem sich euer Pc und eure Fritz.Box befindet

• Protokoll: UDP

• Management Port: 1195

Daraufhin speichern. Ihr sehr dann die OpenVPN Oberfläche. Jetzt ladet ihr das Clientpaket in .ZIP Form herunter und entpackt es. Dann habt ihr 2 Dateien (n2n.conf und n2n.p12), welche ihr auf Pi kopiert. Dies kann mit FileZilla oder jedem anderen beliebigen SFTP Klienten gemacht werden. Ich habe mir in /etc/openvpn ein Ordner n2n angelegt und dann diese beiden Dateien dort abgelegt.

Nun starten wir eine SSH-Verbindung zum Pi und loggen uns ein.

bash:~$ cd /etc/openvpn/n2n
bash:~$ openssl pkcs12 -in XXX.p12 -clcerts -nokeys -nodes -out user.pem
bash:~$ openssl pkcs12 -in XXX.p12 -nocerts -nodes -out key.pem
bash:~$ openssl pkcs12 -in XXX.p2 -cacerts -nodes -out ca.pem

Anschließend editieren wir das Config-File:

bash:~$ nano -w n2n.conf

Ihr ersetzt das

pkcs12 n2n.p12

Durch

ca /etc/openvpn/n2n/ca.pem
cert /etc/openvpn/n2n/user.pem
key /etc/openvpn/n2n/key.pem

Und setzt ein # vor folgende Zeilen um diese auszukommentieren, damit diese wie folgt aussehen

#user nobody
#group nobody
#daemon XXXX
#writepid /var/run/XXX.pid

Das Ganze speichern STRG + O & STRG + X zum Schließen.
Wir haben oben die Zeilen auskommentiert, die diese Verbindung als Deamon gestartet hätte.

Warum?

Weil wir sie dann im Screen starten um so auch zu sehen was passiert. (Erleichtert vor Allem das Troubleshooting um einiges falls was nicht funktioniert.)

Dazu schreiben wir ein Bash Script:

bash:~$ nano -w vpnconnect.sh

#!/bin/bash
modprobe tun
screen -AmdS N2NVPN openvpn --config /etc/openvpn/n2n/n2n.conf

Wenn ihr wollt das eure Verbindung immer beim Start des Pi’s aufgebaut wird ist der einfachste und schnellste Weg ein /etc/rc.local Eintrag.

bash:~$ nano -w /etc/rc.local

In der Text-Datei einfach eine Zeile über exit 0 folgendes schreiben:

bash:~$ /etc/openvpn/n2n/vpnconnect.sh

Das Ganze speichern STRG + O & STRG + X zum Schließen.
Das Script ausführbar machen:

bash:~$ chmod +x vpnconnect.sh

Damit wäre die Konfiguration geschafft.

Verbindung aufbauen

Zum einen müsst ihr am Pi die Client Seite starten:
bash:~$ ./etc/openvpn/n2n/vpnconnect.sh

Zum Anderen unter IPFire Webfrontend ➔ Dienste ➔ OpenVPN den Toggle der Standortverbindung setzten. Um zu überprüfen was geschieht kann man dann den Screen am Pi öffnen. Ist der Verbindungsaufbau erfolgreich kann man noch einmal den jeweils anderen Router/Firewall anpingen um die Funktion noch zu überprüfen. Ansonsten kann man aus dem Screen Informationen auslesen, welche zur Problemlösung beitragen.

Ich möchte euch heute eine Möglichkeit zeigen, wie ihr IPfrire und eine FortiGate Firewall über einen IPsec Tunnel verbinden könnt.
Wir kennen das Drama, man möchte 2 Geräte von Unterschiedlichen Herstellern über ein VPN miteinander verbinden.
IPsec ist hier die wohl Beste Wahl da so gut wie jeder VPN Router / Firewall damit umgehen kann. Folgend werde ich euch zeigen wie ihr einen Site2Site IPsec VPN aufbauen könnt.

Als vorausetzung für die funktion gehe ich von Statischen IP-Adressen oder DynDNS in beiden Standorten aus.

Ich Beginne mit der Konfiguration auf der FortiGate.

FortiGate Konfiguration:

Wir melden uns auf dem FortiGate Webinterface an und Navigieren zu

Mit einem Klick auf Create New landen wir in einem Wizard, diesen wir jedoch nicht verwenden werden.
Wir vergeben unserem VPN einen Namen z.b. VPN-Standort2 klicken auf Custom VPN Tunnel (No Template)

Network:

(Remote Gateway: Hier könnt ihr unteranderem einen Dialup User für Einwählende IPsec Verbindungen von Dynamischen IP Adressen einrichten, oder einen Dynamic DNS auswählen.
Im Feld IP Adresse Tragen wir die Statische öffentliche IP-Adresse von unserem Standort2 ein.)

Authentication:

(Im Feld Method: kann man zwischen einem Pre-shared Key oder einem Zertifikat wählen.
In meinem Fall verwende ich ein Pre-shared Key und trage diesen in das Vorgegeben Feld ein.
Die IKE Version lassen wir auf 1 und belassen IKE Mode auf Main (ID protection)

Phase 1:

Es sollte bei der Encryption und Authentication eine gute Wahl getroffen werden Ich belasse meine Tunnel meist auf AES256 und SHA256.

XAUTH:
Unseren XAUTH Type belassen wir auf Disabled

Phase 2:

(Im Punkt Local Address vergeben wir das Lokale Subnetz das wir Routen möchten.
Technisch sind hier auch sogenannte 0.0.0.0 Netze möglich womit es recht einfach ist mehrere Subnetze über eine Phase 2 zu verbinden.
Als Encryption setze ich wieder AES256 und SHA256 für die Authentication.)

Soweit die IPsec Konfiguration, der nächste Schritt ist es in der FortiGate die benötigten Policys für Intern --> VPN-Standort2 und VPN-Standort2 --> Intern anzulegen.
Damit der Tunnel auch online gehen kann benötigen wir abschließend noch eine Statische Route die uns sagt wo wir das Remote Subnetz finden.

Ipfire Konfiguration:

Wir melden uns bei Standort-B auf dem Ipfire Web Interface an und Navigieren zu Services/IPsec.
Da wir bei unserer IPsec Verbindung mit einem Pre-shared Key arbeiten benötigen wir kein Zertifikat.
Um IPsec auf dem Red0 Interface zu aktivieren reicht es ein Hacken bei Enabled zu setzen und dies zu speichern.
Unter Connection Status and -Control fügen wir uns jetzt mit einem Klick auf Add einen neuen IPsec Tunnel hinzu.

(wir wählen Net-to-Net Virtual Private Network und klicken auf Add)

Durch einen Klick auf Save landen wir in der advanced settings Einstellung.

(Grouptype: Da wir auf der FortiGate Seite bereits hohe Sicherheits Einstellungen vorgenommen haben und sich IPsec auf der IPfire Seite selbständig an die Verschlüsselung der Gegenseite anpasst. Können wir hier ohne Bedenken alles markieren werden.
Lifetime: Wir sollten achten das die Zeit auf beiden Standorten identisch ist.)

Die VPN verbindung sollte jetzt online sein:

Aus gegebenen Anlass habe ich mich dazu entschlossen, ein Beitrag zu diesem Thema zu schreiben.
Es soll darum gehen, wie man sich bei StartSSL ein gültiges Zertifikat anfordern kann und dieses im NGINX konfiguriert.

Generieren von 4096 Bit SHA2 Key + Erzeugung von Request File:

Als Erstes generieren wir unser 4096 Bit SHA2 Keyfile example.org.key und dessen dazugehöriges Request File example.org.csr.

Das Keyfile ist das Herz unserer SSL/TLS Verschlüsslung und darf deshalb niemals in fremde Hände geraten!

openssl req -nodes -newkey rsa:4096 -sha256 -keyout example.org.key -out example.org.csr
(Es können alle nachfolgenden Abfragen mit Enter bestätigt werden, da diese bei StartSSL nicht berücksichtigt werden.)
Wir setzen die Berechtigung am besten auf chmod 600 example.org.key.
Somit ist unser Schlüssel nur für unseren User lesbar.

Einreichen von Certificate Signing Request file:

Im nächsten Schritt müssen wir unser example.org.csr Request File bei StartSSL einreichen. StartSSL bietet uns hier zwar die Möglichkeit uns unseren Privat Key zu erstellen. Das sollten wir jedoch, wie wir eben gelernt haben, niemals machen.
Oder gibst du wildfremden Menschen deinen Hausschlüssel?
Wir überspringen somit diesen Punkt und importieren unser zuvor selbst erstelltes Request File.
Wir werden anschließend nach einer Sub-Domain gefragt. Dort tragen wir, wenn wir ausschließlich für example.org ein Zertifikat ausstellen möchten, www ein.
Nach Abschluss können wir uns unser Zertifikat im ZIP Bundel herunterladen. (Wir benötigen ausschließlich die Datei im Unterordner NGINX)
Dieses Zertifikat öffnen wir in einem Editor, löschen das unterste Zertifikat heraus und speichern das Zertifikat als ssl.crt (Aus Gründen die mir nicht bekannt sind, verteilt StartSSL hier das falsche Intermediate Zertifikate wodurch wir händisch nacharbeiten müssen)

Herunterladen von Intermediate Zertifikate:

Anschließend benötigen wir das richtige StartCom Class 1 DV Server CA(pem)(SHA-2) File von startssl.
Dieses downloaden wir uns hier https://www.startssl.com/certs/sca.server1.crt
oder: https://www.startssl.com/root, unter Intermediate CA Certificates/StartCom Class 1 DV Server CA(pem)(SHA-2)

Wir haben jetzt alle Zertifikate und kommen zur eigentlichen Konfiguration des NGINX web Servers.

Aneinanderhängen von Public Keys

Bevor NGINX mit unseren Zertifikaten etwas anfangen kann, müssen wir unser ssl.crt und das
(Intermediate CA Certificates)sca.server1.crt von StartSSL zusammenfügen. Das machen wir mit
cat ssl.crt sca.server1.crt > ssl-unified.crt.
Das erstellte ssl-unified.crt ist absofort unser Public Key für NGINX

Erstellung von Diffie-Hellman Parameters:

openssl dhparam -out dhparam.pem 4096
(wem 4096 Bit zu paranoid erscheint kann auch auf 2048 Bit umstellen)

NGINX SSL Konfiguration

nano /etc/nginx/sites-available/example.org.conf

    ssl on;  
    ssl_certificate /var/www/it-schley.eu/ssl/ssl-unified.crt;
    ssl_certificate_key /var/www/it-schley.eu/ssl/it-schley.eu.key;	
    ssl_dhparam /var/www/it-schley.eu/ssl/dhparam.pem;

    ssl_protocols TLSv1.1 TLSv1.2 TLSv1;

    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    ssl_session_timeout 10m;
    add_header Strict-Transport-Security max-age=31536000;

Nach Abschluss der Konfiguration sollte unser Zertifikat eine A+ Bewertung bekommen (Stand 10.10.2015)
Testen kann man das unter https://www.ssllabs.com/ssltest/

Änderung: 14.02.2016

• änderungen von StartSSL eingetragen.

Gehen wir von folgender Situation aus: Wir haben eine Webseite auf einem Server mit PHP-FPM aufgesetzt, die PHP-Software, die die Website betreibt, ist auf der aktuellsten Version. Leider wurde erst letztens eine Sicherheitslücke in dem Code von der Software gemeldet, die noch nicht geschlossen wurde und den Hacker bereits ausnutzen können um Zugriff auf das Dateisystem des Servers zu bekommen. Deswegen haben wir sichergestellt, dass wir ein Backup haben für den Fall, dass die Webseite komplett von einem Angriff ruiniert wird und neu installiert werden muss. Aber geht es nicht auch irgendwie, den Server außerhalb der Webseite zumindest abzusichern, dass wir nicht sämtliche Software oder gar den Server komplett neu installieren/konfigurieren müssen nach einem Angriff? Die Antwort ist ein Chroot unter einem separaten Unix-Benutzer zur Einschränkung der Zugriffsrechte.

In diesem Artikel wird eine Möglichkeit der Umsetzung eines sogenannten Chroot-Jails für PHP-FPM vorgestellt, kombiniert mit separatem User zum Ausführen von PHP-Skripts. Es ist durchaus möglich, dass es bessere Methoden gibt um eine PHP-Webseite abzusichern, z.B. die Webseite in einen Docker-Container zu packen; einen Artikel dazu werde ich noch nachreichen.

Eigenen Benutzer zur PHP-Ausführung

Zu aller erst werden wir einen eigenen Systemuser erstellen um Zugriffsrechte für PHP-Skripte einzuschränken. Das ist für den Fall, dass es eventuell in Linux auch einen Exploit geben könnte um den Chroot zu durchbrechen, dass dann trotzdem Dateien von anderen Webseiten nicht ruiniert und optional auch nicht ausgelesen werden können. Wir brauchen dafür Root-Rechte.

root@example:~# adduser --system --no-create-home --home /var/www/example.org www-example-org
Adding system user `www-example-org' (UID 113) ...
Adding new user `www-example-org' (UID 113) with group `nogroup' ...
Not creating home directory `/var/www/example.org'.
root@example:~# 

Wir haben den Benutzer hier www-example-org genannt und das Webseitenverzeichnis /var/www/example.org als dessen Homeverzeichnis übergeben was optional aber sauberer ist. Punkte vertragen sich im Übrigen nicht immer gut mit Unix-Benutzernamen, also habe ich zur Sicherheit stattdessen Bindestriche verwendet.

Konfiguration des PHP-Pools mit Chroot

Schauen wir jetzt mal was PHP selbst direkt bietet um einen Chroot aufzusetzen. Dafür werfen wir einen Blick auf die Konfigurationsdateien für PHP-Pools in PHP-FPM. Auch hier brauchen wir Root-Rechte.

root@example:~# cd /etc/php5/fpm/pool.d/
root@example:/etc/php5/fpm/pool.d# ls
www.conf
root@example:~# 

Standardmäßig findet sich in dem Ordner für die Poolkonfigurationen nur eine Konfiguration für den www-Pool der ein Socket aufsetzt über den Webserver (sowohl Apache als auch Nginx) mit PHP kommunizieren können.

Wir wollen aber nun einen separaten Pool für jede Webseite aufsetzen der so eingestellt ist, dass PHP-Skripte in diesem Pool in einer Chroot-Umgebung "eingesperrt" sind. Dafür erstellen wir eine neue Konfigurationsdatei, entweder durch Kopieren von www.conf und Hinzufügen/Auskommentieren/Bearbeiten entsprechender Zeilen oder einfach durch erstellen einer leeren Datei, je nach aktuellem Setup. Am bequemsten zu verwalten sind diese Konfigurationsdateien meiner Meinung nach wenn man sie gleich der Domain oder dem Verzeichnisnamen von der Webseite benennt, hier nennen wir es mal chroot-example.org.conf. Hier das Template mit Erklärung:

[chroot-example.org]

; Der Unixsocket auf dem dieser Pool auf den Webserver hört
listen = /var/run/php5-fpm-chroot-example.org.sock

; Das Verzeichnis unter dem PHP laufen wird
prefix = /var/www/example.org

; Das obere Verzeichnis wird unser Chroot-Ziel!
chroot = $prefix

; Wir wollen im neuen Wurzelverzeichnis arbeiten
chdir = /

; Der User und die Gruppe unter der PHP laufen wird, gemäß dem User den wir vorher erstellt haben
user = www-example-org
group = www-data

; Der Besitzer und die Gruppe des Sockets.
; Als Besitzer nehmen wir den User, den wir vorhin angelegt haben und als Gruppe nehmen wir die gleiche Gruppe unter der unser Webserver läuft.
; Mit dem Zugriffsmodus (660) kombiniert stellt das sicher, dass nur der Webserver Zugriff auf diesen Socket hat.
listen.owner = www-example-org
listen.group = www-data 
listen.mode = 0660

; Ein Ordner in der Chroot-Umgebung in dem wir alle PHP-Sessions sicher ablegen
php_value[session.save_path] = /sessions

; Optional, ein paar Performance-Einstellungen für diesen Pool
pm=dynamic
pm.max_children=5
pm.start_servers=2
pm.min_spare_servers=1
pm.max_spare_servers=3

Zusammengefasst erstellen wir also hier einen Pool der unter dem gerade angelegten User www-example-org läuft in dem von uns gewollten Chroot. Außerdem ist dieser Pool dann nur für den Webserver zugänglich, über die Gruppe www-data.

So ähnlich wird auch mit jeder anderen Seite vorgegangen für die wir einen isolierten Chroot haben wollen. Dabei bekommt jeder Chroot einen eigenen Socketpfad (listen), einen eigenen Benutzer (listen.owner/user) und den entsprechenden eigenen prefix.

DNS-Auflösung im Chroot via nscd

Bevor wir fortfahren muss ich kurz erwähnen, dass in einer Chroot Umgebung PHP üblicherweise nicht ohne Probleme in der Lage ist DNS-Anfragen über gethostbyname oder gethostbyaddr aufzulösen. Damit das funktioniert wird man DNS-Anfragen aus dem Chroot irgendwie herausführen müssen da Linux-Programme das üblicherweise über Systemaufrufe erledigen die von Systemdateien abhängen die wir eventuell nicht in der Chroot-Umgebung haben wollen. Stattdessen verwenden wir eine Chroot-sichere Lösung die sich nscd ("Name Service Cache Daemon") nennt. Dieser Daemon stellt einen speziellen Socket bereit den DNS-Anfragen via Systemaufrufe alternativ nutzen um die Abfragezeit zu beschleunigen (daher "Cache"). Diesen Socket können wir später via mount in den Chroot durchgeben.

Die Installation läuft normalerweise sehr einfach und bequem über apt-get: (Nicht vergessen davor ein apt-get update auszuführen!)

root@example:~# apt-get install nscd -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  nscd
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/242 kB of archives.
After this operation, 355 kB of additional disk space will be used.
Selecting previously unselected package nscd.
(Reading database ... 53350 files and directories currently installed.)
Preparing to unpack .../nscd_2.19-18+deb8u1_amd64.deb ...
Unpacking nscd (2.19-18+deb8u1) ...
Processing triggers for systemd (215-17+deb8u2) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up nscd (2.19-18+deb8u1) ...
Processing triggers for systemd (215-17+deb8u2) ...
root@example:~# service nscd start
root@example:~# 

Der letzte Befehl stellt sicher, dass nscd auch wirklich bereits läuft. Danach sollte der Socket /var/run/nscd/socket existieren.

Chroot-Verzeichnisstruktur automatisch erstellen und abbauen

Als nächstes kümmern wir uns darum, dass die richtigen und nötigen Dateien in der Chroot-Umgebung existieren. Zur Verdeutlichung, meine Verzeichnisstruktur ist so, dass ich für jede Domain auf der eine Website läuft einen eigenen Ordner aufsetze in /var/www. Also als Tree-Ansicht:

├── example.org/                                     <= Soll im Chroot laufen
│   ├── htdocs/
│   │   └── index.php
│   ├── logs/
|   └── tmp/
├── sub.example.org/                                 <= Soll im Chroot laufen
│   ├── htdocs/
│   │   └── index.php
│   ├── logs/
|   └── tmp/
└── underconstruction.example.org/                   <= Das hier soll nachher nicht in einem Chroot laufen
    └── htdocs/
        └── index.html

Damit die Chroot-Umgebung anständig laufen kann müssen wir ein paar zusätzliche Ordner und Dateien freigeben auf die PHP dann von innen heraus zugreifen kann. mount --bind ist ein guter Weg um den Zugriff auf solche Dateien zu gewähren, das vermeidet vor allem zusätzliche Festplattenspeicherbelegung und es ist einfach generell eine sauberere Lösung.

Hier die Liste der Dateien und Ordner die ich freigebe samt Grund:

• /dev/null, /dev/random, /dev/urandom, /dev/zero um Grundfunktionalitäten zu gewährleisten.
• /usr/share/zoneinfo um die Zeitzonenberechnung in PHP nicht zu beeinträchtigen, praktisch für Foren etc.
• /etc/ssl/certs und der eigentliche Ordner mit den Zertifikaten /usr/share/ca-certificates um kein Drama mit gültigen SSL-Zertifikaten bei HTTP-Verbindungen zu verursachen.
• /var/run/mysqld für die Freigabe des MySQL Serversockets.
• /etc/hosts, /etc/resolv.conf und /var/run/nscd für die Freigabe des oben genannten nscd Sockets damit DNS-Anfragen problemlos ablaufen.

Allerdings kann es ein bisschen nervig sein das für jede Webseite manuell machen zu müssen, daher habe ich mir dafür ein sogenanntes LSB-Init-Skript geschrieben, das man in /etc/init.d einfügen kann und das dann beim Hochfahren und Herunterfahren des Systems mitstarten kann um bei neuen Webseiten einfach den Chroot automatisch aufzusetzen und sauber die Mounts wieder abzubauen bevor das System herunterfährt.

Den folgenden Inhalt habe ich unter /etc/init.d/php5-fpm-chroot-setup abgespeichert und dann mit chmod +x ausführbar gemacht. Required-Start: nscd stellt sicher, dass das Skript automatisch nach dem nscd hochfährt und die CHROOT_FILES-Variable enthält alle Ordner- und Dateipfade die in die Chroot-Umgebung gemountet werden sollen.

#!/bin/sh

### BEGIN INIT INFO
# Provides:          php5-fpm-chroot-setup
# Required-Start:    nscd
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Mounts needed sockets and other data into a previously set up chroot environment.
### END INIT INFO

# Hier die Dateien und Ordner die in die Chroot-Umgebung gemountet werden sollen
CHROOT_FILES="/etc/hosts /etc/resolv.conf /etc/ssl/certs /usr/share/ca-certificates /dev/null /dev/random /dev/urandom /dev/zero /var/run/mysqld /var/run/nscd /usr/share/zoneinfo"

case "$1" in
    restart|force-reload|start)
        # Aufräumen bevor wir aufbauen
        $0 stop 2>/dev/null

        for chrootdir in /var/www/*; do
            # Nur in Ordnern mit eigenem /tmp Verzeichnis als Markierung einen Chroot aufsetzen
            if [ -d "${chrootdir}/tmp" ]; then
                # Berechtigungen von /tmp korrigieren
                chmod 777 "${chrootdir}/tmp"
                chmod +t "${chrootdir}/tmp"

                echo "Setting up ${chrootdir}..."
                for f in $CHROOT_FILES; do
                    if [ -d "$f" ]; then
                        # $f ist ein Pfad zu einem Verzeichnis
                        mkdir -p "${chrootdir}${f}"
                        mount --bind -o ro "${f}" "${chrootdir}${f}"
                    else
                        # $f ist ein Pfad zu einer Datei
                        mkdir -p "${chrootdir}$(dirname "${f}")"
                        touch "${chrootdir}${f}"
                        mount --bind -o ro "${f}" "${chrootdir}${f}"
                    fi
                done
            fi
        done
    ;;

    stop)
        for chrootdir in /var/www/*; do
            if [ -d "${chrootdir}/tmp" ]; then
                echo "Destructing ${chrootdir}..."
                for f in $CHROOT_FILES; do
                    umount "${chrootdir}${f}"
                    if [ -d "${chrootdir}${f}" ] && [ ! $(ls -A "${chrootdir}${f}") ]; then
                        # Leerer Ordner, kann man löschen
                        rmdir "${chrootdir}${f}"
                    elif [ -f "${chrootdir}${f}" ]; then
                        # Datei, kann man löschen
                        rm "${chrootdir}${f}"
                    fi
                done
            fi
        done
    ;;

    *)
        echo "Usage: $N {start|stop|restart|force-reload}" >&2
        exit 1
    ;;
esac

exit 0

Klar kann dieses Skript ausgebaut werden, z.B. so, dass die Liste von Dateien die gemountet werden aus einer anderen Datei eingelesen wird, anstatt dass sie fest eingeschrieben wird. Außerdem wird hier einfach alles aus Sicherheitsgründen als "read-only" gemountet, was in manchen Situationen vielleicht unerwünscht ist. Aber als Basis funktioniert das wunderbar.

Zuletzt müssen wir, damit dieses Skript seine Arbeit automatisch beim Hoch- und Herunterfahren verrichtet, das Skript auch mittels update-rc.d installieren:

root@example:~# update-rc.d php5-fpm-chroot-setup defaults
root@example:~#

Das was jetzt noch manuell erstellt werden muss sind in jedem Chroot jeweils ein Ordner für die HTTP-Dokumente, einer für Logs, einer für PHP-Sessions und noch einer für temporäre Dateien. Ich habe das so gemacht im Chroot-Ordner:

• htdocs Unterordner für HTTP Dokumente mit eigenem persönlichen Unix Account als Besitzer, nur Unterordner/Dateien die Schreibrechte brauchen haben entsprechende Berechtigung via chown oder chmod.
• logs Unterordner für Webserverlogs mit dem vorher angelegten PHP-Benutzer als Besitzer.
• tmp Unterordner mit dem vorher angelegten PHP-Benutzer als Besitzer, wird vom Skript automatisch mit den richtigen Berechtigungen ausgestattet wird. PHP nutzt standardmäßig diesen Ordner wenn nichts anderes manuell als temporäres Verzeichnis gesetzt wurde.
• sessions Unterordner (weiter oben im PHP-Pool als Session-Speicherordner konfiguriert) mit oben angelegtem User als Besitzer und Modus 700 aus Sicherheitsgründen.

Oder kurz in ein paar Befehlen:

root@example:/var/www/example.org# mkdir -p htdocs logs tmp sessions
root@example:/var/www/example.org# chown icedream:icedream htdocs
root@example:/var/www/example.org# chown www-example-org:www-data logs
root@example:/var/www/example.org# chown www-example-org:www-data sessions
root@example:/var/www/example.org# chmod 700 sessions

Danach können wir /etc/init.d/php5-fpm-chroot-setup start ausführen und danach sollten wir sehen, dass das Skript in den Chroot-Ordnern die benötigten Sachen anständig gemountet hat:

root@example:~# /etc/init.d/php5-fpm-chroot-setup start
Destructing /var/www/example.org...
Destructing /var/www/sub.example.org...
Setting up /var/www/example.org...
Setting up /var/www/sub.example.org...
root@example:~# ls /var/www/example.org
dev  etc  htdocs  sessions  tmp  usr  var
root@example:~#

Die "Destructing" Meldung rührt daher, dass das Skript automatisch das Abbauen eines eventuellen fehlerhaften vorherigen Chroot-Setups probiert bevor er den Chroot neu aufbaut um inkonsistente Setups zu vermeiden. Dieses Abbauen kann manuell mittels /etc/init.d/php5-fpm-chroot-setup stop angestoßen werden um zum Beispiel vor Backups das Chroot-Verzeichnis zu reinigen.

Konfigurieren des Webservers

Als nächstes müssen wir unsere Webseite im Webserver so konfigurieren, dass sie auch durch den soeben konfigurierten PHP-Pool in der Chroot-Umgebung läuft. Hier benutze ich Nginx aber in Apache sollte das ebenfalls einfach zu machen sein.

Wir legen für jede Webseite die im Chroot laufen wird im /etc/nginx/sites-available Ordner eine eigene Konfigurationsdatei an, die so ähnlich wie diese aussieht:

server {
        listen 80;
        listen [::]:80;

        root /var/www/example.org/htdocs;

        index index.php index.html index.htm index.nginx-debian.html;

        server_name example.org;

        # Hier ist der wichtige Teil! Damit sagen wir Nginx, dass er den PHP-Pool, den wir
        # speziell für diese Seite aufgesetzt haben, auch benutzen soll.
        location ~ \.(php|php/.*)$ {
                include snippets/fastcgi-php.conf;
                fastcgi_param   SCRIPT_FILENAME /htdocs/$fastcgi_script_name;
                fastcgi_pass unix:/var/run/php5-fpm-chroot-example.org.sock;
        }
}

Seiten die nicht im Chroot laufen werden brauchen dann auch natürlich nicht die Sektion in der Konfiguration mit dem eigenen PHP-Socket.

Nicht vergessen die Konfiguration dann auch unter /etc/nginx/sites-enabled korrekt zu verlinken damit Nginx diese auch beim Laden miteinbezieht:

root@example:/etc/nginx/sites-enabled# ln -s ../sites-available/example.org

Letzte Schritte

Nach einem service php5-fpm restart sollte dann der neue Socket für den Pool in /var/run/php5-fpm-chroot-example.org.sock angelegt sein und ein anschließendes service nginx reload oder service nginx restart sollte den Nginx dazu bringen die neuen Webseitenkonfigurationen zu laden.

Da IPv4 Adressen zur Neige gehen und man nun bei jedem ordentlichen Hoster ein /64 oder sogar /48 IPv6 Block bekommt, stellt sich die Frage warum man nicht diese Option nutzt, um für die Zukunft gerüstet zu sein.

Ich stelle hier nun eine Möglichkeit vor, mit dem ihr kinderleicht ein /48 IPv6 Block mit eurem online.net Server einrichtet.

Anforderungen

• online.net Server
• root SSH Login

Zuerst müsst ihr euch auf euren Server via SSH mit dem root User aufschalten. Dafür könnt ihr z.B. PuTTY benutzen.
Anschließend erstellt ihr ein neues Script, das z.B ipv6.sh heißt. Der Inhalt dieses Scripts sieht folgendermaßen aus:

#/bin/bash

DUID=$1

skill -9 dibbler-client
dpkg -P dibbler-client
rm -rvf /etc/dibbler /var/log/dibbler /var/lib/dibbler

apt-get install -y wide-dhcpv6-client vim-common tcpdump

/etc/init.d/wide-dhcpv6-client stop

echo 'profile default { script "/etc/wide-dhcpv6/dhcp6c-script"; };' > /etc/wide/dhcpv6/dhcp6c.conf
echo 'id-assoc pd { prefix-interface eth0 { }; };' >> /etc/wide-dhcpv6/dhcp6c.conf
echo 'interface eth0 { send ia-pd 0; };' >> /etc/wide-dhcpv6/dhcp6c.conf
echo $DUID | awk '{ gsub(":"," "); printf "0: 0a 00 %s\n", $0 }' | xxd -r > /var/lib/dhcpv6/dhcp6c_duid

/etc/init.d/wide-dhcpv6-client start

Um das Script ausführbar zu machen, müsst ihr die Dateirechte verändern:

chmod +x ipv6.sh  

Nun braucht ihr die DUID des IPv6 Blocks aus dem Controlpanel. Geht auf die Serverliste, wählt euren Server aus und klickt auf den IPv6 Reiter auf der linken Seite.
Sucht oder erstellt euch einen Block und kopiert die DUID.
Anschließen führt ihr das Script mit folgendem Befehl aus:

./ipv6.sh DUID

Allerdings reicht das Script selbst nicht aus, also müsst ihr als nächstes den richtigen Gateway vom Router finden. Am Besten funktioniert das mit

tcpdump -i eth0 -n -s 4000 -v ip6

Um nun die Gateway IP zu finden muss man nach einer Zeile, die router advertisement beinhaltet suchen.
In meinem Fall wäre es
15:22:16.257672 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::e34f:6de3:bd24:42ff > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 32
In diesem Fall ist fe80::e34f:6de3:bd24:42ff die Gateway IP.

Öffnet /etc/network/interfaces mit eurem Lieblingseditor und tragt folgende Einstellungen ein:

iface eth0 inet6 static
address DEIN_IPv6_BLOCK::1
netmask 48
gateway DEINE_GATEWAY_IP
accept_ra 1

Damit der Linuxkernel noch die Anfragen annimmt und weiterschickt, muss folgendes in die /etc/sysctl.conf geschrieben werden:

net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.eth0.autoconf = 0
net.ipv6.conf.eth0.accept_ra=1

Anschließend mit sysctl -p die Datei neu einlesen.

Um den DHCPv6 Client bei jedem Neustart des Server zu starten, tragt einfach folgendes in eure /etc/rc.local ein:

/etc/init.d/wide-dhcpv6-client restart
ifdown eth0 && ifup eth0

Nun sollte alles funktionieren! Startet euren Netzwerkadapter mit ifdown eth0 && ifup eth0 neu und pingt eine IPv6 fähige IP an:

magic@ffmwu:~$ ping6 -c4  ipv6.google.com
PING google.com(par03s13-in-x08.1e100.net) 56 data bytes
64 bytes from par03s13-in-x08.1e100.net: icmp_seq=1 ttl=58 time=0.913 ms
64 bytes from par03s13-in-x08.1e100.net: icmp_seq=2 ttl=58 time=0.999 ms
64 bytes from par03s13-in-x08.1e100.net: icmp_seq=3 ttl=58 time=1.42 ms
64 bytes from par03s13-in-x08.1e100.net: icmp_seq=4 ttl=58 time=1.01 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 0.913/1.086/1.420/0.197 ms

Wichtig für das Ganze ist, dass Ihr in eurer Firewall Port 546 und 547 UDP freigibt

Wer aktuell mit einem Unitymedia oder einem Telekom Hybrid LTE Anschluss einen Standort mit seinem Hauptstandort verbinden möchte, wird früher oder später auf das Problem stoßen, dass man dank der IP Adressen Knappheit keine eigene IPv4 Adresse mehr von seinem Provider bekommt. Sondern über einen sogenannten DS-lite Tunnel, der sich hinter einem NAT-Gateway befindet, sich ins Internet Verbindet. Somit teilt man sich eine öffentliche IPv4-Adresse mit mehreren Leuten.
Es ist also keine Freigabe mehr von Ports über IPv4 möglich.
Ich habe sehr lange nach einer Lösung für dieses Problem gesucht und möchte diese hier einmal für euch Dokumentieren.

Vorwort

• Benötigt wird in beiden Standorten eine IPfire die dort auch als Gateway im Netzwerk fungiert.
• Es muss gewährleistet sein das beide Standorte sich in einem eigenen Subnetz befinden
• Der Hauptstandort benötigt eine Statische IPv4 Adresse, optional ein DynDNS

Konfiguration

Konfiguration von Hauptstandort:
Wir öffnen das Webinterface der Ipfire in meinem Fall ist dieses erreichbar unter https://10.0.0.1:444. Dort angekommen gehen wir auf Services/OpenVPN.
(Wenn wir das erste Mal die OpenVPN Konfigurationsseite öffnen, werden wir darauf hingewiesen ein Zertifikat zu generieren. Hier wählt ihr am besten einen 2048bit Schlüssel aus und warte ab bis dieser erstellt ist, was je nach Hardware einige Zeit dauern kann.)
Ist das abgeschlossen landen wir im eigentlichen Konfigurationsmenü von OpenVPN

Wir klicken auf Add und erstellen uns ein Net-to-Net Virtual Private Network

mit einem weiteren Klick auf Add kommt man in das Einstellung der N2N VPN Verbindung.

Name: Hier vergibt man am besten den Namen des Standorts, der für den Tunnel vorgesehen ist.
Act as: bleibt auf OpenVPN Server stehen.
Remote host/IP: dieses Feld wird hier leer gelassen, somit erlauben wir die Einwahl von jeder IP-Adresse (später kann dies mit Firewallregeln abgesichert werden)
Local subnet: Hier tragen das Subnetz unseres Hauptstandorts ein,
in meinem Fall: 10.0.0.0/24
Remote subnet: Hier tragen wir das Subnetz unseres standortB ein, in meinem Fall: 10.0.1.0/24
OpenVPN subnet: Wichtig ist hier eine IP Range zu wählen die zukünftig nicht in Verwendung ist, da wir hier nur 2 IP Adressen benötigen reicht uns eine /30 IP Range 172.30.60.0/255.255.255.252
Destination port: Hier vergeben wir einen Port über den später die VPN Verbindung abläuft. (Dieser Port ist unabhängig von den normalen OpenVPN Server Einstellungen, in meinem Fall: 9988)
Manage Port: Hier tragen wir den selben Port ein der auch bei Destination Port vergeben wurde.

MTU settings

Hier kann vorerst alles auf Standardeinstellungen gelassen werden.
Um später mit der Performanz noch etwas zu experimentieren, können hier die Einstellungen getestet werden. z.B. LZO-Compression

Cryptographic options

Encryption: AES-CBC (256 bit, Default)
Hash algorithm: SHA2 (512 bit)

Authentication

User's full name or system hostname: standortB

Zum Abschluss klicken wir auf Save.
Wir starten das VPN Interface mit dem Klick auf die Checkbox im Menüpunkt Action.

Um unser Zertifikat zu erhalten klicken wir bei OpenVPN Net-to-Net auf Download Client Package (zip). Hier erhalten wir unsere standortB-Client.zip, die wir in unserem nächsten Schritt benötigen.

Als nächstes melden wir uns auf der IPFire an standortB im Webinterface an. (Die eine Verbindung zu unserer Haupt- IPFire aufbauen soll.)

Dort Wechseln wir in die OpenVPN Konfiguration und klicken auf Add.
Hier laden wir unsere zuvor Heruntergeladene standortB-Client.zip hoch.

Ein Klick auf Add zeigt uns nochmals die von uns gesetzten Einstellungen. Wir akzeptieren das mit einem weiteren Klick auf Add.
Als letzten Schritt muss das eben von uns angelegte VPN-Interface mit einem Klick auf die Checkbox gestartet werden.
Die Statusleiste sollte uns jetzt Connected anzeigen. Somit steht unsere Verbindung!

Heute möchte ich mich damit beschäftigen wie man ein Ubuntu-System via PXE von einem iSCSI Target zum booten bringen kann.

Anwendungszweck

In meinem PC ist jedeglich eine SSD verbaut und ich habe keine große Lust die Partitionierung dieser zu ändern. Außerdem läuft bei mir im LAN schon ein PXE Server, weshalb also nicht einfach Ubuntu auf einem iSCSI Target installieren und via PXE davon booten?

Anmerkung: Ich setze für dieses Tutorial voraus das bereits ein korrekt konfigurierter PXE Server vorhanden ist, der in eine Syslinux-Umgebung bootet.

iSCSI am Server einrichten

Vorwort

Zu Beginn benötigen wir erstmal ein Medium das via iSCSI freigegeben werden soll, dafür kann man entweder eine komplette Festplatte verwenden, diese darf dann allerdings am Server nicht gemountet werden und kann somit auch nur noch für iSCSI verwendet werden.
Oder die zweite Möglichkeit, die ich auch bei mir angewandt habe, wir erstellen uns einen Festplatten Container und geben diesen frei.

Pakete installieren

bash:~$ apt-get update && apt-get install iscsitarget iscsitarget-dkms -y

Container erzeugen

bash:~$ mkdir /iscsi_disks && cd /iscsi_disks
bash:~$ dd if=/dev/zero of=ubuntu.disk count=0 bs=1 seek=80G

So erzeugen wir einen Container der später bis zu 80 GB groß werden darf, natürlich kann man die Größe beliebig anpassen.

Freigabe einrichten

bash:~$ nano -w /etc/default/iscsitarget
ISCSITARGET_ENABLE=true

bash:~$ nano -w /etc/iet/ietd.conf
# namens-regel: [iqn.jahr-monat.domain/ip:name]
Target iqn.2015-09.server.local:ubuntu
   Lun 0 Path=/iscsi_disks/ubuntu.disk,Type=fileio
   # Optional: ip des iSCSI Initiators, der sich verbinden darf (kann auch ein ganzes Netzwerk sein)
   initiator-address 192.168.2.0/24

bash:~$ /etc/init.d/iscsitarget restart

Freigabe überprüfen

bash:~$ ietadm --op show --tid=1
# Ausgabe:
Wthreads=8
Type=0
QueuedCommands=32
NOPInterval=0
NOPTimeout=0

Ubuntu installieren

Tip: Bevor man mit der Installation beginnt sollte man sicherheitshalber alle im PC verbauten Festplatten abklemmen.

Zuerst booten wir ein normales Ubuntu Live System (CD/USB-Stick/PXE), dort öffnen wir erstmal ein Terminal und installieren die benötigten Pakete:

bash:~$ sudo -i
bash:~$ apt-get update && apt-get install open-iscsi -y
bash:~$ /etc/init.d/open-iscsi start

iSCSI Laufwerk einhängen

bash:~$ iscsiadm -m discovery -t st -p server.local
# Ausgabe:
192.168.2.2:3260,1 iqn.2015-09.server.local:ubuntu

bash:~$ iscsiadm -m node --targetname "iqn.2015-09.server.local:ubuntu" --portal "server.local:3260" --login

Nun können wir den normalen Ubuntu-Installer starten, die Partitionierung erledigen wir manuell und erstellen eine Partition für unseren Swap (Empfehlung: 2GB) und eine weitere Partition für unser System (root), der wir den restlichen Speicher zuweisen. Dann fahren wir wie gewohnt mit der Installation fort.

Nachdem die Installation abgeschlossen ist starten wir nicht neu!

Damit unser firsch installiertes System booten kann sind noch ein paar Schritte nötig, wir müssen dazu mittels chroot in das System wechseln:

bash:~$ sudo -i
bash:~$ mount /dev/sda2 /mnt
bash:~$ chroot /mnt /bin/bash
bash:~/$ mount -t proc none /proc
bash:~/$ echo "nameserver 192.168.2.1" >> /etc/resolv.conf
bash:~/$ apt-get update && apt-get install initramfs-tools open-iscsi sysv-rc-conf -y
bash:~/$ echo "iscsi" >> /etc/initramfs-tools/modules
bash:~/$ echo "InitiatorName=iqn.2015-09.server.local:ubuntu-client1" > /etc/iscsi/initiatorname.iscsi
bash:~/$ touch /etc/iscsi/iscsi.initramfs
bash:~/$ update-initramfs -u
bash:~/$ nano -w /etc/network/interfaces
auto eth0
iface eth0 manual

# Kernel und Initialramdisk auf den PXE Server kopieren
bash:~/$ scp /vmlinuz /initrd.img root@server.local:/tftp/iscsi/

# Umgebung verlassen
bash:~/$ umount /proc
bash:~/$ exit

Damit sollte unser System nun in der Lage sein zu booten, nun müssen wir nur noch einen Eintrag in unserem Syslinux Menü anlegen:

label ubuntu-iscsi
    menu label Ubuntu (iSCSI)
    kernel iscsi/vmlinuz
    append initrd=iscsi/initrd.img ip=dhcp ISCSI_INITIATOR=iqn.2015-09.server.local:ubuntu-client1 ISCSI_TARGET=iqn.2015-09.server.local:ubuntu ISCSI_TARGET_IP=server.local ISCSI_TARGET_PORT=3260 root=UUID=5c0bd3d6-b43b-48d4-ac82-cc9b364f4544 rw

Anmerkung: Sollte der Domainname bei ISCSI_TARGET_IP nicht funktionieren, gibt man die IP-Adresse stattdessen an, außerdem ist bei root die UUID von /dev/sda2 auf unserem iSCSI Target gemeint auslesen kann man sie wie folgt:

bash:~$ sudo blkid /dev/sda2

Sollte man nach dem Boot nur einen schwarzen Bildschirm vorfinden hilft eventuell der Parameter nomodeset.

Somit sind wir nun fertig und können nun unser System via PXE booten.

Ich habe mich dazu entschlossen diesen Betrag zu schreiben da VMware seit ESXi 5.5 sehr viele Treiber für normale Hardware entfernt hat.
Ohne diese es jedoch nicht mehr ohne weiteres möglich ist ESXi 6.0 beispielsweiße auf einem Normalen PC / Server zu installieren

Vorbereitung

• ESXi-Customizer
• Net51-drivers.vib
• ESXi 6.0 ISO
• unetbootin (optional)

Durchführung

Wir starten die ESXi-Customizer Anwendung:

Wir wählen wie erwünscht oben unsere ESXi 6.0 ISO aus.
Im zweiten Bereich die gedownloadete VIB Datei mit allen enthaltenen ESXi 5.1 Treibern und klicken im letzten Schritt auf Run!

Die jetzt erstellte ISO Datei kann man sich jetzt entweder auf eine CD brennen, oder man erstellt sich einen bootbaren USB-Stick.
Ich werde mir hier einen bootbaren USB-Stick mit der Software unetbootin erstellen

Bei der Erstellung des USB-Sticks wird man gefragt ob einige Menü Dateien von UNetbootin überschrieben werden soll, das beantworten wir mit einem Ja.

Nachdem der USB-Stick erfolgreich erstellt wurde kann man mit der Installation beginnen!

Nachdem ich mir nun auch Zuhause eine IPFire hingestellt habe (vielen Dank an Kevin), wollte ich diese als Client für meine VPN-Verbindungen nutzen.

Info: Die IP-Adresse meiner IPFire lautet 192.168.2.1 somit ist mein green0 Netzwerk 192.168.2.0/24 (255.255.255.0).

Damit das Ganze funktioniert, muss man allerdings SSH auf der IPFire aktivieren.
Dieses geht im Webinterface unter System -> SSH-Zugriff.
Dann schalten wir uns via SSH auf die IPFire auf:

bash:~$ ssh root@192.168.2.1

Dort erstellen wir dann einen Ordner Namens vpn:

bash:~$ mkdir vpn && cd vpn

Ich habe zwei VPN’s mit denen ich mich verbinden möchte also erstelle ich mir nun zwei weitere Ordner im Ordner vpn:

bash:~/vpn$ mkdir vpn1 vpn2

In diese Ordner kopiere ich meine Zertifikate und OpenVPN Konfigurationsdateien, allerdings müssen wir Letztere noch bearbeiten.

Der Pfad zu unserem Zertifikat muss nämlich absolut und nicht relativ sein, sonst gibts es später Probleme.
Ebenfalls müssen wir, da wir mehr als ein VPN verwenden noch den adapter manuell angeben:

vpn1

dev tun0

vpn2

dev tun1

Somit verwendet unser erstes VPN immer tun0 und das Zweite tun1.

Nachdem diese Vorberitungen nun abgeschlossen sind, können wir uns unser eigentliches Skript basteln:

connect.sh

#!/bin/bash
BASEPATH=/root/vpn
CONF_VPN1=$BASEPATH/vpn1/vpn1.ovpn
CONF_VPN2=$BASEPATH/vpn2/vpn2.ovpn
NET_GREEN0=192.168.2.0/24

# lade das für tun zuständige Kernel-Modul
modprobe tun

# verbinde mit vpn1
openvpn --config $CONF_VPN1 --daemon vpn1
# verbinde mit vpn2
openvpn --config $CONF_VPN2 --daemon vpn2

# erlaube den Zugriff auf das VPN von green0 aus
iptables -t nat -A POSTROUTING -s $NET_GREEN0 -o tun0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s $NET_GREEN0 -o tun1 -j MASQUERADE

Mit dem Befehl chmod +x connect.sh machen wir das Skript noch ausführbar und sind fertig.

Soll das Skript automatisch beim Booten ausgefürht werden, gibt man folgenden Befehl ein:

bash:~$ echo "/root/vpn/connect.sh" >> /etc/sysconfig/rc.local

Nun wird unser Skript automatisch bei jedem Bootvorgang ausgeführt.

Alle PC’s, die nun im green0 Netzwerk hängen, können nun unsere VPN-Verbindung verwenden, auf Wunsch kann man nun SSH wieder deaktivieren.

Heute bauen wir uns eine eigene Hardware Firewall, als Betriebssystem setze ich dazu Ipfire ein.
Eine Open Source Firewall Distribution mit Deutschem Ursprung. http://www.ipfire.org

Vorwort

• Es muss die Möglichkeit bestehen seinen Router auf ein (bei Fritzbox exposed host zu vergeben oder seinen Router auf bridge Mode zu schalten)

Genutzte Hardware

• 1x Digitus USB 2.0 RS 232 seriell Adapter
• 1x PC Engines APU.1D4 Bundle
• 1x [UD Atheros XSPANTM](UD Atheros XSPANTM)
• 2x [DELOCK WLANz Antenne](DELOCK WLANz Antenne)
• 1x BIGtec WLAN Adapterkabel RP SMA

Genutzte Software

• win32diskimager
• PuTTY
• IPFire

Der Bau

Der Einbau der Engines APU in das Aluminium Gehäuse gestaltet sich Relativ einfach und ist weitestgehend selbst erklärend.
Wichtig ist an dem Punkt, nicht zu vergessen das beiliegende Kühl Pad an die Richtige Position unter des Mainboard an das Gehäuse zu Kleben.
Da die APU keine Aktive Kühlung hat wird bei Weglassen des Pads die APU ihre besten tage wohl nicht lange haben.

Die Installation

In meiner Konstellation möchte ich Ipfire auf die mPCIe SSD Installieren und natürlich auch davon starten.
Dazu bereiten wir einen USB Stick vor, mit dem wir die APU Booten können. Dazu laden wir uns als aller erstes das ISO Image herunter, das finden wir auf der Ipfire Seite unter http://www.ipfire.org/.
Die nun vorliegende ISO Datei schreiben wir mit dem Tool win32diskimager auf einen USB Stick der mindestens 1GB groß sein sollte. Nachdem unser USB Stick fertig ist stecken wir ihn an einen USB Port der APU.

Wir schließen nun unser USB – Seriell Adapter an unserem PC an und Installieren denn passenden Treiber Download. Bei mir wird der Adapter als COM3 erkannt.

Wir verbinden jetzt Das Seriell Kabel mit der APU und unsrem Adapter. Dazu ist zu beachten das wir Serial line auf COM3 und der Speed auf 115200 gestellt wird, mit einem Klick auf Open starten wir die Verbindung mit unsrer APU.

Nun stecken wir unsere APU an den Strom und sehen sofort auf unsrem PuTTY Fenster eine Ausgabe.
mit einem Klick auf F12 öffnen wir das Boot Menü, dort wählen wir unseren USB Stick aus.

Es sollte sich jetzt das Ipfire Installationsmenü starten.
In diesem angekommen, gehen wir auf den Punkt Serial console options und von dort auf Install IPFire (serial) nun beginnt das Setup und wir klicken uns durch die Menüs, bis wir am Punkt sind wo wir unsere Festplatte auswählen können worauf IPFire installiert werden soll. Wir wählen in unserem Fall die SATA-SSD aus und bestätigen mit einem klick auf Alle Dateien löschen.
Wir wählen ext4 als Dateisystem aus und bestätigen mit OK. Die Installation beginnt!

Nachdem die Installation erfolgreich abgeschlossen ist muss die IPFire Neugestartet werden, unsren USB stick können wir jetzt wieder abstecken.

Die Grundkonfiguration

Nach dem Neustart landen wir in dem Installationsmenü in das wir später jederzeit wieder mit dem Befehl setup springen können, wir wählen de-latin1 und geben unseren Domänennamen ein z.B. xyz.local.

Im Netzwerkkonfigurationsmenü klicken wir auf Typ der Netzwerkkonfiguration werden wir aufgefordert unseren Einsatzzweck zu bestimmen.

In meinem Beispiel ist das GREEN + RED + ORANGE + BLUE (Green = LAN, Red = Internet, Orange = DMZ, Blue = Wlan)

Nun werden wir aufgefordert die Netzwerkkartenzuordnung vorzunehmen.

Für GREEN wählen wir unsere erste PCI Realtek Karte aus.

Für RED das 2. PCI Realtek Interface, für ORANGE das 3. PCI Realtek Interface und für BLUE unseren Qualcomm Atheros Wlan Chip.

Im Punkt Adresseinstellung definieren wir die IP Konfigurationen für jedes unserer Zugeordneten Interfaces, in meinem Fall:

GREEN:  IP-Adresse: 10.0.1.1 mit der Subnetmask 255.255.255.0
BLUE:   IP-Adresse: 10.0.2.1 mit der Subnetmask 255.255.255.0
ORANGE: IP-Adresse: 10.0.3.1 mit der Subnetmask 255.255.255.0
RED:    IP-Adresse des exposed host eintragen.

Im Punkt DNS- und Gatewayeinstellungen wähle ich als DNS die Server vom Chaos Computer Club und meine Fritzbox als Gateway.

Primärer DNS: 213.73.91.35
Sekundärer DNS: 217.79.186.148
Standard-Gateway: 192.168.1.1

Nachdem alles eingestellt wurde können wir mit einem Klick auf Fertig noch einstellen ob wir einen DHCP Server betreiben wollen und ihm Standarteinstellungen übergeben.

Fast geschafft. der Klick auf OK startet unsere IPFire nun neu, währenddessen werden die SSH und HTTPS Zertifikate generiert

Geschafft unser IPFire ist jetzt einsatzbereit!!! Die Postbelegung sollte nun wie folgt aus

Wir verbinden unseren PC mit einem normalen Ethernet-Kabel mit dem Green0 Port unserer Firewall, wenn wir einen DHCP Server aktiviert haben sollten wir eine nun selbständig eine IP-Adresse bekommen.

Um auf das IPFire Admin Interface zu gelangen öffnen wir jetzt unseren Browser und gehen auf https://10.0.1.1:444 und melden uns mit admin und unsrem bei der Installation vergebenen Kennworts ein.

Heute beschäftigen wir uns mit der Einrichtung eines OpenVPN Tun Servers und der Konfiguration des OpenVPN Clients

Vorbereitung:

• Root zugriff auf einen Linux Server (Debian / Ubuntu)
• Der Server darf nicht mit OpenVZ Virtualliesiert sein da dort die Kernelerweiterung für (TUN/TAP) nicht aktiviert werden kann

Durchführung:

Als erstes bringen wir unser System auf den aktuellsten Stand

bash:~$ apt-get update && apt-get upgrade -y

Den OpenVPN Server installieren wir jetzt mit:

bash:~$ apt-get install openvpn -y

Als nächstes müssen wir die Konfigurationsfiles in das richtige Verzeichnis kopieren

bash:~$ cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
bash:~$ gunzip /etc/openvpn/server.conf.gz
bash:~$ cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa2

Nun geht es an die Erstellung des Serverzertifikates

bash:~$ cd /etc/openvpn/easy-rsa2/
bash:~$ mkdir keys
bash:~$ source ./vars
bash:~$ ./clean-all
bash:~$ ./build-ca

Wichtig: bei Common Name Die IP-Adresse oder FQDN Namen eures Servers eintragen!

Als nächstes Schritt müssen noch Zertifikate für die Clients erstellt werden die sich später mit dem Server verbinden sollen

bash:~$ ./build-key client1
bash:~$ ./build-key client2
bash:~$ ./build-key client3

Daraufhin ist ein sogenannter Diffie-Hellman-Schlüsselaustausch zu generieren

bash:~$ ./build-dh

Des Weiteren legen wir die zugehörige Server Konfigurationsdatei an

bash:~$ cd /etc/openvpn/server.conf
bash:~$ nano -w server.conf

Hierzu kann die von mir bereits erstellte Konfiguration verwendet werden.

port 1194
proto udp
dev tun

ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key
dh ./easy-rsa2/keys/dh1024.pem
#crl-verify ./easy-rsa2/keys/crl.pem

push “redirect-gateway”
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

client-to-client
keepalive 10 120
comp-lzo

user nobody
group nogroup

persist-key
persist-tun

status openvpn-status.log
verb 3

Um den OpenVPN Server später auch wirklich als Gateway nutzen zu können müssen wir noch ein paar Routing Änderungen am Netzwerk des Servers einrichten, um dies zu tätigen öffnen wir die Datei /etc/rc.local mit einem Editor und tragen folgendes ans Ende der Datei ein. „exit 0“ darf erst am ende der Datei sein!

bash:~$ iptables -t nat -F POSTROUTING
bash:~$ echo 1 > /proc/sys/net/ipv4/ip_forward
bash:~$ iptables -t nat -A POSTROUTING -o eth0 -s 10.8.0.0/24 -j MASQUERADE

Somit ist die eigentliche Einrichtung auf dem des VPN-Servers abgeschlossen.
Damit alle Einstellungen korrekt übernommen werden sollte der gesamte Server neu gestartet werden, oder die Routing Einstellungen manuelle gesetzt werden!

Weiter geht es mit unseren Clients

Als erstes benötigen wir die OpenVPN Client Software für unser Endgerät dies finden wir auf der Entwicklerseite unter
Windows: http://openvpn.net/index.php/download/community-downloads.html
Linux: apt-get install openvpn -y
Android: https://play.google.com/store/apps/details?id=net.openvpn.openvpn&hl=de
iOS: https://itunes.apple.com/de/app/openvpn-connect/id590379981?mt=8

Als erstes müssen wir die Zertifikate unseres zuvor erstellten Clients herunterladen, dies Files liegen im Ordner /etc/openvpn/easy-rsa2 auf dem Server benötigt werden.

ca.crt
client1.crt
client1.key

Diese speichert ihr unter Windows am besten direkt im Ordner C:\Program Files\OpenVPN\config

Der nächste Schritt ist es im Ordner config eine weitere Datei mit dem Namen client1.ovpn zu erstellen in die vollende Einstellungen eingetragen wird:

client
dev tun
proto udp
# Hier FQDN oder IP des Servers eintragen!
remote example.org 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
ns-cert-type server
comp-lzo
verb

Um sich mit dem OpenVPN-Server zu verbinden, öffnet die OpenVPN GUI mit Admin-Rechten und öffnen über das Tray-Icon das VPN Symbol.
Dort klickt man auf Verbinden, nun sollte eine Verbindung mit dem VPN Server zustande kommen.

Testen ob ihr nun die IP-Adresse des Servers habt könnt ihr z.B. auf http://myip.is.

Wie es wahrscheinlich viele bereits wissen, bietet Windows an Netzwerkfreigaben als Laufwerk einzubinden.
Ebenfalls soll es möglich sein diese nach einem Neustart zu behalten, nur klappte das bei mir noch nie.

Ich wollte drei verschiedene Freigaben, die auch noch drei unterschiedliche Zugangsdaten benötigen, einbinden.
Windows lies mich das auch tun, allerdings durfe ich nach jedem Neustart des Systems erneut meine Zugangsdaten eingeben.
Wie man sich sicher denken kann, hat mich das auf die Dauer „ein wenig“ genervt.

Also musste mal wieder die Holzhammermethode greifen, zuerst brauchen wir ein Batch-Skript das uns alle Laufwerke einbindet:

@echo off
net use Y: \\10.0.0.2\freigabe1 /user:user1 passwort1
net use X: \\10.0.0.2\freigabe2 /user:user2 passwort2
net use Z: \\10.0.0.2\freigabe3 /user:user3 passwort3

Ich habe dann (regedit.exe) einen neuen Zeichensatz Names MapNetworkDrives unter HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run angelegt und diesem den Wert C:\Scripts\MapDrives.bat gegeben. Dort befindet sich nämlich mein Batch-Skript.
Somit wird dieses Skript nun jedesmal, wenn sich mein Windows-Benutzer anmeldet, ausgeführt und meine Netzlaufwerke eingebunden.

Allerdings war es damit noch nicht vorbei, denn damit Windows bei der nächsten Anmeldung nicht erneut rumzickt muss ein zweites Skript her.
Dieses bindet die Netzlaufwerke beim Abmelden des Nutzers wieder aus:

@echo off
net use * /DELETE /Y

Dieses Skript bei der Abmeldung ausführen zu lassen, wollte bei mir diesmal allerdings nicht mithilfe der Registry funktionieren, also musste die Gruppenrichtlinienverwaltung her (gpedit.msc).
Dort also nach Benutzerkonfiguration > Windows Einstellungen > Skripte (Anmeldung/Abmeldung) navigiert, einen Doppelklick auf Abmeldung gemacht, dort klickt man dann auf Hinzufügen und klickt im nächsten Fenster auf Durchsuchen und wählt das Zweite Batch-Skript aus.

Nun noch alles mit Ok bestätigen und schon werden alle benötigten Netzlaufwerke beim Anmelden eingebunden und beim Abmelden wieder ausgehangen und dann sagen mir Leute Linux sei kompliziert…