Um einen Client dazu zu bewegen sich mit unserem VPN zu verbinden braucht es neben den Schlüsseln ebenfalls eine Konfigurationsdatei sowie eine Cliensoftware. Das kann für Debian, bzw. Linux, das schon bekannte openVPN Paket sein, denn es kann sowohl einen Server bereitstellen, als auch als reiner Client fungieren. Für MacOS ist Tunnelblick die erste Wahl, für Windows, iOS und Android stellt openVPN eigene Clientsoftware zum Download bereit.

Die Schlüssel haben wir schon, die client.conf muss noch passend erstellt werden:

gateway: /etc/openvpn # nano client.conf.orig

##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server.     #
#                                            #
# This configuration can be used by multiple #
# clients, however each client should have   #
# its own cert and key files.                #
#                                            #
# On Windows, you might want to rename this  #
# file so it has a .ovpn extension           #
##############################################
 

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client
Wir sind kein Server 

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun
Der Server lauscht auf einem "tun" interface

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one.  On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap
 

# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
;proto tcp
proto udp
Der Server nutzt das UDP Protokoll, wenn diese Konfig für einen PC, also Linux, MacOS oder Windows ist. Soll sie für iOS oder Android sein, muss hier tcp stehen!  

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote pa54678.dyndns.org 1196
;remote my-server-2 1194
Dein DynDNS Name und der Port 

# Choose a random host from the remote
# list for load-balancing.  Otherwise
# try hosts in the order specified.
;remote-random nein
 

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite ja
 

# Most clients don't need to bind to
# a specific local port number.
nobind genau, überlass das dem Portmapper wenn es keinen guten Grund gibt das nicht zu tun
 

# Downgrade privileges after initialization (non-Windows only)
user nobody
group nogroup
immer gut, aber Windows kennt weder den Benutzer nobody, noch die Gruppe nogroup, schade eigentlich. Ist Dein Laptop auf Windows, Semikolons stehen lassen.  

# Try to preserve some state across restarts.
persist-key
persist-tun
 

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
Tja, das kann immer nur der Netzwerkadmin des Netzwerks beantworten, in dem Du Dich gerade befindest, wenn Du Dich einloggen willst. Du wirst mit ziemlicher Sicherheit irgendwann in irgendeinem Hotel- oder FlughafenWlan auf sowas treffen und Schwierigkeiten haben Dich zu verbinden. Das ist allerdings nur relevant, soweit ich das verstehe, wenn Dein VPN auch HTTP weiterleiten soll. Für eine Verbindung ins Heimnetz sollte das nicht interessieren.  

# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
mute-replay-warnings find ich gut
 

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
;ca ca.crt
;cert client.crt
;key client.key
Hier ist jetzt obacht angesagt. Wo kommen die Schlüssel hin und wie heissen sie?
Unser Beispiel mit einem Debian Client unter Gnome "Laptop" würde jetzt so aussehen:
ca ca.crt
cert laptop.crt
key laptop.key
In diesem Fall ist es egal wo die Schlüssel liegen, solange sie im selben Verzeichnis wie die KonfigDatei liegen.
Das darf dann gerne ein verstecktes Verzeichnis sein, z.B. ~/.opvn/
Für ein MacOS Laptop mit Tunnelblick genauso, mit dem Unterschied, das nach der ersten Verbindungsaufnahme diese Schlüssel dort auch wieder gelöscht werden können, da Tunnelblick bei der Installation der KonfigDatei die Schlüssel nimmt und tief im System vergräbt.
Bei Windows ist das glaube ich auch so, bei iOS sowieso.

# Verify server certificate by checking that the
# certicate has the correct key usage set.
# This is an important precaution to protect against
# a potential attack discussed here:
#  http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the keyUsage set to
#   digitalSignature, keyEncipherment
# and the extendedKeyUsage to
#   serverAuth
# EasyRSA can do this for you.
remote-cert-tls server
 

# If a tls-auth key is used on the server
# then every client must also have the key.
tls-auth ta.key 1 jep, auch im Ordner bei der Konfig bitte
 

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
# Note that v2.4 client/server will automatically
# negotiate AES-256-GCM in TLS mode.
# See also the ncp-cipher option in the manpage
cipher AES-256-CBC
AUTH SHA512 ergänzen 

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
#comp-lzo 
 

# Set log file verbosity.
verb 3
 

# Silence repeating messages
;mute 20

Damit haben wir eine OpenVPN Konfigurationsdatei die genau für einen Client funktioniert, für „laptop“. Diese wird nun also als laptop.conf gespeichert und für jeden weiteren geplanten Client angepasst und wieder als neuer-client.conf gespeichert usw.
Für Client Smartphone würden also folgende Änderungen vorgenommen:

proto tcp

cert smartphone.crt
key smartphone.key

Jetzt haben wir zwei Päckchen die wir schnüren können:

Ordner laptop mit folgendem Inhalt:
laptop.conf laptop.ovpn für MacOS
ca.crt
laptop.crt
laptop.key
ta.key

Ordner smartphone mit folgendem Inhalt:
smartphone.ovpn muss die .conf zumindest bei iOS enden
ca.crt
smartphone.crt
smartphone.key
ta.key

Jedes Päckchen muss auf sein Gerät und dort initialisiert werden.

Wichtig! Es darf keine Datei mit .conf ausser den beiden Serverconfigs server.udp.conf und server.tcp.conf im Ordner /etc/openvpn auf gateway verbleiben!!! Der openVPN-Server liest bei jedem Neustart jede Datei, die auf .conf endet!

So, mit dem Übertragen der Päckchen auf die verschiedensten Geräte darf ich Euch alleine lassen, dazu gibt es für jedes System auch in Deutsch gute HowTo’s.
Ich zeige hier einmal das Prinzip am Debian Desktop Gnome:

Die Dateien werden übertragen via scp oder mv, je nachdem, in einen direkt dafür vorbereiteten Ordner:

ich@meinPC: ~ #mkdir .ovpn

Erstellt ein „verstecktes“ Verzeichnis, die mit dem Punkt davor, die die ich nur sehe, wenn ich ls -al eingebe, unser „alias“ l

Nun alle Dateien dahin kopieren oder schieben. Ich habe die Päckchen laptop und smartphone „vorübergehend“ auf meinem Desktop oder Schreibtisch geschnürt, also:

ich@meinPC: ~ # mv Schreibtisch/laptop/* .ovpn/

Nun ist der Ordner laptop auf dem Schreibtisch leer und kann gelöscht werden und das ist gut so.

Wir lassen keine Schlüssel und keine Konfigurationdateien rumliegen wenn sie verteilt und initialisiert sind.
Wenn es mit mv oder scp nicht geht zu übertragen, benutzen wir das USB-Kabel ( Smartphone ) oder einen USB-Stick ( Windows ). Es wird nichts verschickt, weder als E-Mail, noch und schon garnicht über irgendwelche anderen fremden Systeme wie Messenger oder Clouds.
Nach dem ganzen Aufwand bisher ist das klar, oder?
Auch wenn man ohne CA keine neuen Schlüssel erstellen kann, – mit den geschnürten Päckchen kommt jeder rein der es hat!

Sofern noch nicht vorhanden braucht es jetzt die Clientsoftware.
Laden wir sie für Debian mit Gnome Desktop mit:

root@meinPC: ~ #apt update
root@meinPC: ~ #apt install network-manager-openvpn-gnome

Für MacOS laden und installieren wir Tunnelblick, für Smartphone schauen wir im jeweiligen AppStore nach openVPN und für Windows laden wir die Soft direkt von openVPN.

Nun können wir die Konfig laden:

Netzwerkverbindung hinzufügen: +

Aus Datei importieren…

Kontrolle: >Erweitert…ta.key fehlt mir hier

Aber prima, alles da! > ok und Hinzufügen

Jetzt hab ich natürlich mal kein pa5tralala.dyn und bin mal kurz ins andere Netz um zu schauen ob es so läuft, oder ob ich noch einen dummen Fehler drin habe. Deshalb, s.o. 10.0.2.1…

Auf der anderen Seite sieht der Log jetzt wie folgt aus:

gateway: /etc/openvpn # tail -f /var/log/openvpn/openvpn-status.udp.log 
 OpenVPN CLIENT LIST
 Updated,Tue Nov 12 16:11:48 2019
 Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
 laptop,10.0.2.2:33201,3981,3696,Tue Nov 12 16:11:36 2019
 ROUTING TABLE
 Virtual Address,Common Name,Real Address,Last Ref
 10.8.0.2,laptop,10.0.2.2:33201,Tue Nov 12 16:11:36 2019
 GLOBAL STATS
 Max bcast/mcast queue length,0
 END

Und auch die andere Logdatei spuckt sinnvolles aus, vor allem, wenn was nicht klappt.

Damit wäre das Kapitel jetzt durch, Deine speziellen Geräteeinrichtungen funktionieren ganz ähnlich, Links dazu:

Für MacOS – Tunnelblick und das HowTo – Google übersetzt das auch ganz brauchbar
Für Windows – openVPN und das HowTo
Für Android und iOS gibt es reichlich Anleitungen auf Deutsch, immer muss man die Dateien zunächst via USB-Verbindung auf das Gerät schieben und dann die openVPN App öffnen. Die App fragt sodann – „neue Konfig gefunden, öffnen?“….

Jetzt installieren wir noch einen kleinen Wächter, der auf unseren VPN aufpasst und die Honks aus China & Co ein wenig auflaufen lässt.

next > fail2ban