Eigenes Reise-VPN mit WireGuard, OpenVPN, GL.iNet Router und Hetzner VPS

Reise-VPN Setup mit Reiserouter, VPS und Heimnetz Ein Reise-VPN ist dann gut, wenn es nicht nur im heimischen WLAN funktioniert, sondern auch im Hotel, Mobilfunknetz und in schwierigen Netzen einen Plan B hat.

TL;DR

Dieses Setup nutzt einen Hetzner VPS als öffentlich erreichbares Gateway, WireGuard als schnellen Haupttunnel, OpenVPN TCP als Fallback und einen GL.iNet Reiserouter als zentrale Zugangsstelle für unterwegs. Zusätzlich verbindet ein zweiter WireGuard-Tunnel den VPS mit dem Heimnetz. Dadurch müssen Geräte unterwegs nicht alle einzeln konfiguriert werden, und Heimnetz-Zugriffe bleiben sauber vom normalen Internetverkehr getrennt. Das Ziel ist keine magische Anti-Sperr-Lösung, sondern ein kontrollierbares, redundantes Reise-Setup für Dienstreisen, Hotels, Mobilfunk und schwierige Netze.

Viele VPN-Anleitungen hören da auf, wo es eigentlich erst spannend wird: App installieren, verbinden, hoffen. Das reicht für Netflix im Hotel vielleicht. Sobald man aber zuverlässig arbeiten, eigene Systeme erreichen oder in schwierigeren Netzen unterwegs sein möchte, wird diese Strategie dünn.

Der konkrete Auslöser für dieses Setup war eine Reise nach China. Wer nach VPN China, WireGuard China, OpenVPN China oder GL.iNet China sucht, merkt schnell: Es gibt viele Versprechen, aber wenig saubere Infrastruktur.

Deshalb entstand dieses Setup mit:

einem Hetzner VPS als zentralem Gateway
WireGuard als Haupt-VPN
OpenVPN TCP als Fallback
einem GL.iNet Reiserouter
einem zweiten WireGuard-Tunnel ins Heimnetz

Wichtig: Das ist keine magische Stealth-Lösung und kein Trick gegen irgendwelche Sperren. Es ist ein kontrollierbares, dokumentiertes und redundantes Setup für Reisen, schwierige Netze und Zugriff auf eigene Infrastruktur.

Update 2026: Der Aufbau ist weiterhin sinnvoll, gerade als Ergänzung zu eSIM und Smartphone-VPN. Auf der China-Reise hat sich aber auch gezeigt: Der Reiserouter ist Komfort, kein Single Point of Failure. Das Smartphone sollte mit eSIM und VPN immer eigenständig arbeitsfähig bleiben.

Warum nicht einfach zuhause hosten?

Normalerweise könnte man WireGuard direkt zuhause betreiben. In meinem Fall hängt der Anschluss aber an Glasfaser ohne öffentliche IPv4. Es gibt nur öffentliche IPv6-Konnektivität.

Das macht externen Zugriff unterwegs unnötig kompliziert:

IPv4-only Netze erreichen den Anschluss nicht sauber
Routing wird unübersichtlich
Hotel-WLANs und Mobilfunknetze sind schwer vorhersehbar
Fehlersuche unterwegs wird unnötig nervig

Der Hetzner VPS löst dieses Problem sauber:

öffentliche IPv4
stabile Erreichbarkeit
zentrale Firewall-Regeln
saubere Trennung zwischen Internet-VPN und Heimnetz-Tunnel

Architektur

Endgeräte
  ↓
GL.iNet Router
  ↓
WireGuard oder OpenVPN
  ↓
Hetzner VPS
  ├── normales Internet
  └── WireGuard Tunnel ins Heimnetz
        ↓
      Home LXC
        ↓
      Heimnetz

Der normale Internetverkehr läuft über den VPS. Nur Heimnetz-Zugriffe gehen durch den zweiten Tunnel nach Hause.

Das ist der wichtigste Punkt am ganzen Setup. Der VPS ist das zentrale Gateway. Das Heimnetz ist nur ein zusätzlich angebundenes Zielnetz, nicht der normale Internet-Ausgang.

Beispiel-Netze

Bereich	Netz
WireGuard Reise-VPN	`10.66.66.0/24`
WireGuard Server	`10.66.66.1`
OpenVPN Fallback	`10.99.99.0/24`
Home Tunnel	`10.200.200.0/24`
Heimnetz	`192.168.1.0/22`
Home LXC	`192.168.1.50`

Die Adressen sind Beispiele. Wer das nachbaut, sollte die Netze an die eigene Umgebung anpassen. Wichtig ist nur: Reise-VPN, OpenVPN und Home-Tunnel sollten unterschiedliche Netze benutzen.

Teil 1: WireGuard auf dem VPS installieren

WireGuard ist in diesem Setup der Hauptweg. Es ist schnell, schlank und funktioniert sehr gut auf kleinen Routern wie den Geräten von GL.iNet.

WireGuard installieren

apt update && apt upgrade -y
apt install wireguard qrencode -y

Danach werden die Schlüssel für den Server erzeugt.

Server-Schlüssel erzeugen

mkdir -p /etc/wireguard
cd /etc/wireguard

wg genkey | tee server_private.key | wg pubkey > server_public.key

Den Public Key kann man sich anzeigen lassen:

cat /etc/wireguard/server_public.key

Der Private Key gehört nicht veröffentlicht und nicht in Blogartikel, Wikis oder Screenshots.

Teil 2: WireGuard Server-Konfiguration

Die Server-Konfiguration liegt hier:

/etc/wireguard/wg0.conf

In diesem Beispiel läuft WireGuard auf Port 8443/UDP.

Warum nicht 443/UDP? In meinem Fall war der Port bereits belegt. Außerdem ist es kurz vor einer Reise keine gute Idee, funktionierende Webdienste oder Reverse-Proxys umzubauen, nur um einen schöneren Port zu bekommen.

WireGuard Server-Konfiguration anzeigen

[Interface]
Address = 10.66.66.1/24
ListenPort = 8443
PrivateKey = SERVER_PRIVATE_KEY

PostUp = iptables -I FORWARD 1 -i wg0 -j ACCEPT
PostUp = iptables -I FORWARD 1 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -s 10.66.66.0/24 -o eth0 -j MASQUERADE

PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -D FORWARD -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -s 10.66.66.0/24 -o eth0 -j MASQUERADE

Das externe Interface muss geprüft werden:

ip route get 1.1.1.1

Wenn dort nicht eth0 steht, muss eth0 in der WireGuard-Konfiguration entsprechend ersetzt werden, zum Beispiel durch ens3.

Teil 3: IP Forwarding aktivieren

Damit der VPS Pakete zwischen VPN und Internet weiterleiten kann, muss IPv4 Forwarding aktiv sein.

IPv4 Forwarding aktivieren

echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/99-wireguard.conf
sysctl --system

Danach WireGuard aktivieren und starten:

WireGuard starten

systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0

Status prüfen:

wg
systemctl status wg-quick@wg0

Firewall öffnen:

ufw allow 8443/udp

Falls zusätzlich eine Cloud-Firewall beim Anbieter aktiv ist, muss der Port dort ebenfalls freigegeben werden.

Teil 4: Automatischer WireGuard Clientgenerator

Clients manuell anzulegen ist fehleranfällig. Deshalb ist ein kleines Script praktisch, das:

eine freie Client-IP sucht
Schlüssel erzeugt
den Peer in wg0.conf einträgt
eine Client-Konfiguration schreibt
WireGuard neu startet
einen QR-Code ausgibt

Das Script liegt hier:

/usr/local/bin/wg-add-client

Clientgenerator anzeigen

#!/bin/bash
set -e

WG_IF="wg0"
WG_DIR="/etc/wireguard"
WG_CONF="$WG_DIR/$WG_IF.conf"
SERVER_IP="DEINE_SERVER_IP_ODER_DOMAIN"
SERVER_PORT="8443"
VPN_NET="10.66.66"
DNS="1.1.1.1"

if [ -z "$1" ]; then
  echo "Nutzung: wg-add-client CLIENTNAME"
  exit 1
fi

CLIENT="$1"
CLIENT_DIR="$WG_DIR/clients"
mkdir -p "$CLIENT_DIR"

if [ -f "$CLIENT_DIR/$CLIENT.conf" ]; then
  echo "Client existiert bereits: $CLIENT"
  exit 1
fi

LAST_IP=$(grep -oP 'AllowedIPs = 10\.66\.66\.\K[0-9]+' "$WG_CONF" | sort -n | tail -1)

if [ -z "$LAST_IP" ]; then
  NEXT_IP=2
else
  NEXT_IP=$((LAST_IP + 1))
fi

if [ "$NEXT_IP" -gt 254 ]; then
  echo "Keine freien IPs mehr"
  exit 1
fi

CLIENT_PRIV=$(wg genkey)
CLIENT_PUB=$(echo "$CLIENT_PRIV" | wg pubkey)
SERVER_PUB=$(wg show "$WG_IF" public-key)

CLIENT_IP="$VPN_NET.$NEXT_IP"

cat >> "$WG_CONF" <<EOF

# $CLIENT
[Peer]
PublicKey = $CLIENT_PUB
AllowedIPs = $CLIENT_IP/32
EOF

cat > "$CLIENT_DIR/$CLIENT.conf" <<EOF
[Interface]
PrivateKey = $CLIENT_PRIV
Address = $CLIENT_IP/24
DNS = $DNS

[Peer]
PublicKey = $SERVER_PUB
Endpoint = $SERVER_IP:$SERVER_PORT
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
EOF

systemctl restart wg-quick@"$WG_IF"

echo
echo "Client erstellt: $CLIENT"
echo "IP: $CLIENT_IP"
echo "Config: $CLIENT_DIR/$CLIENT.conf"
echo

qrencode -t ansiutf8 < "$CLIENT_DIR/$CLIENT.conf"

Script ausführbar machen:

chmod +x /usr/local/bin/wg-add-client

Beispiele für neue Clients:

wg-add-client iphone
wg-add-client tablet
wg-add-client glinet-router

Die fertigen Client-Konfigurationen liegen danach unter:

/etc/wireguard/clients/

Beispiel zum Anzeigen einer Client-Konfiguration:

cat /etc/wireguard/clients/glinet-router.conf

Teil 5: GL.iNet Router einrichten

Der GL.iNet Router verbindet sich unterwegs mit dem verfügbaren Netzwerk, zum Beispiel Hotel-WLAN, Handy-Hotspot oder öffentlichem WLAN. Danach baut er selbstständig den VPN-Tunnel auf.

Dadurch nutzen alle Geräte hinter dem Router automatisch das VPN.

Im GL.iNet Webinterface:

VPN
→ WireGuard Client
→ Add New Profile

Dort wird die zuvor erzeugte Client-Datei importiert.

Der Test sollte nicht im eigenen Heim-WLAN passieren, sondern über einen Handy-Hotspot. Nur so merkt man, ob das Setup wirklich von außen funktioniert.

Test:

curl ifconfig.me

Die Ausgabe sollte die IP des VPS zeigen.

Teil 6: OpenVPN als Fallback

WireGuard ist schnell und effizient, nutzt aber UDP. In manchen Netzen ist UDP instabil oder blockiert. Deshalb läuft zusätzlich OpenVPN über TCP.

OpenVPN ist hier nicht der Hauptweg. Es ist der Rettungsweg.

OpenVPN installieren

apt install openvpn easy-rsa -y

PKI vorbereiten:

OpenVPN PKI vorbereiten

make-cadir /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa

./easyrsa init-pki
./easyrsa build-ca nopass
./easyrsa build-server-full server nopass
./easyrsa build-client-full glinet nopass
./easyrsa gen-dh

openvpn --genkey secret ta.key

Die OpenVPN Server-Konfiguration liegt hier:

/etc/openvpn/server.conf

OpenVPN Server-Konfiguration anzeigen

port 9443
proto tcp
dev tun

ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/server.crt
key /etc/openvpn/easy-rsa/pki/private/server.key
dh /etc/openvpn/easy-rsa/pki/dh.pem

tls-auth /etc/openvpn/easy-rsa/ta.key 0

server 10.99.99.0 255.255.255.0

push "redirect-gateway def1"
push "dhcp-option DNS 1.1.1.1"

keepalive 10 120

cipher AES-256-GCM
auth SHA256

persist-key
persist-tun

user nobody
group nogroup

verb 3

NAT für OpenVPN:

iptables -t nat -A POSTROUTING -s 10.99.99.0/24 -o eth0 -j MASQUERADE

Auch hier gilt: eth0 vorher prüfen und bei Bedarf ersetzen.

OpenVPN starten:

systemctl enable openvpn@server
systemctl start openvpn@server

Firewall öffnen:

ufw allow 9443/tcp

Status prüfen:

systemctl status openvpn@server

Teil 7: OpenVPN Clientdatei für den GL.iNet Router

Für den GL.iNet Router wird eine .ovpn Datei benötigt.

Die Client-Datei kann direkt auf dem Server zusammengesetzt werden.

OpenVPN Clientdatei erzeugen

cat > /etc/openvpn/client-glinet.ovpn <<EOF
client
dev tun
proto tcp
remote DEINE_SERVER_IP_ODER_DOMAIN 9443

resolv-retry infinite
nobind
persist-key
persist-tun

remote-cert-tls server

cipher AES-256-GCM
auth SHA256

key-direction 1

verb 3

<ca>
$(cat /etc/openvpn/easy-rsa/pki/ca.crt)
</ca>

<cert>
$(sed -n '/BEGIN CERTIFICATE/,/END CERTIFICATE/p' /etc/openvpn/easy-rsa/pki/issued/glinet.crt)
</cert>

<key>
$(cat /etc/openvpn/easy-rsa/pki/private/glinet.key)
</key>

<tls-auth>
$(cat /etc/openvpn/easy-rsa/ta.key)
</tls-auth>
EOF

Datei anzeigen:

cat /etc/openvpn/client-glinet.ovpn

Oder herunterladen:

scp root@DEINE_SERVER_IP:/etc/openvpn/client-glinet.ovpn .

Im GL.iNet Webinterface:

VPN
→ OpenVPN Client
→ Upload File

Teil 8: Heimnetz-Tunnel

Der zweite Tunnel verbindet den VPS mit dem lokalen Server zuhause. Darüber werden nur interne Ziele erreicht, zum Beispiel:

Home Assistant
NAS
Proxmox
interne Webdienste

Beispiel:

Heimnetz:       192.168.1.0/22
Home LXC:       192.168.1.50
Tunnelnetz:     10.200.200.0/24
VPS Tunnel IP:  10.200.200.1
Home Tunnel IP: 10.200.200.2

Auf dem Home-LXC wird WireGuard installiert:

apt update
apt install wireguard -y

Die Home-Konfiguration liegt auf dem lokalen LXC hier:

/etc/wireguard/wg-home.conf

Home WireGuard Config anzeigen

[Interface]
Address = 10.200.200.2/24
PrivateKey = HOME_PRIVATE_KEY

PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -i wg-home -j ACCEPT
PostUp = iptables -A FORWARD -o wg-home -j ACCEPT

PostDown = iptables -D FORWARD -i wg-home -j ACCEPT
PostDown = iptables -D FORWARD -o wg-home -j ACCEPT

[Peer]
PublicKey = VPS_PUBLIC_KEY
Endpoint = VPS_IP_ODER_DOMAIN:51830
AllowedIPs = 10.200.200.1/32,10.66.66.0/24
PersistentKeepalive = 25

Home-Tunnel starten:

systemctl enable wg-quick@wg-home
systemctl start wg-quick@wg-home

Status prüfen:

wg
systemctl status wg-quick@wg-home

Wichtig ist der Handshake. Wenn dort latest handshake erscheint, steht der Tunnel.

Teil 9: WireGuard Home-Tunnel auf dem VPS

Auf dem VPS existiert für den Heimtunnel eine eigene WireGuard-Instanz.

Datei:

/etc/wireguard/wg-home.conf

VPS Home-Tunnel Config anzeigen

[Interface]
Address = 10.200.200.1/24
ListenPort = 51830
PrivateKey = VPS_HOME_PRIVATE_KEY

[Peer]
PublicKey = HOME_PUBLIC_KEY
AllowedIPs = 10.200.200.2/32,192.168.1.0/22
PersistentKeepalive = 25

Starten:

systemctl enable wg-quick@wg-home
systemctl start wg-quick@wg-home

Status prüfen:

wg
systemctl status wg-quick@wg-home

Teil 10: Statische Route auf der UniFi Dream Machine Pro

Damit Antworten aus dem Heimnetz zurück zum Reise-VPN finden, braucht die UDM Pro eine statische Route.

Zielnetz	Gateway
`10.66.66.0/24`	`192.168.1.50`

Ohne diese Route passiert der Klassiker: Der VPN-Handshake funktioniert, aber der Zugriff auf interne Geräte nicht.

Der Grund ist simpel: Ein Gerät im Heimnetz bekommt ein Paket aus 10.66.66.0/24, kennt dieses Netz aber nicht und antwortet an sein Standard-Gateway. Die UDM muss deshalb wissen, dass dieses Netz über den Home-LXC erreichbar ist.

Teil 11: Tests

WireGuard prüfen:

wg
systemctl status wg-quick@wg0

OpenVPN prüfen:

systemctl status openvpn@server

Home-Tunnel prüfen:

systemctl status wg-quick@wg-home
wg

Routing prüfen:

ip route
iptables -S
iptables -t nat -S

Öffentliche IP prüfen:

curl ifconfig.me

Die Ausgabe sollte die IP des VPS zeigen.

Typische Fehler

WireGuard startet nicht

Prüfen:

journalctl -xeu [email protected]
systemctl status wg-quick@wg0

Häufige Ursachen:

Port bereits belegt
falscher Private Key
kaputte Config
Interface-Name bei NAT falsch
alte iptables-Regeln

Belegte Ports prüfen:

ss -tulpn

Handshake funktioniert, aber kein Internet

Dann liegt es meistens an:

fehlendem IP Forwarding
fehlender NAT-Regel
falschem externem Interface
Firewall-Regeln

Prüfen:

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
iptables -t nat -S

Heimnetz nicht erreichbar

Dann fehlt sehr oft die statische Route auf dem Heimrouter:

10.66.66.0/24 → 192.168.1.50

Oder auf dem VPS fehlt beim Home-Peer das Heimnetz in AllowedIPs:

AllowedIPs = 10.200.200.2/32,192.168.1.0/22

Webseiten laden nur halb

Das ist häufig ein MTU-Problem. In der Client-Config kann helfen:

MTU = 1280

Das ist besonders bei Hotel-WLANs, Mobilfunk und internationalen Verbindungen ein Klassiker.

Fazit

Dieses Setup ist aufwendiger als eine VPN-App. Dafür ist es deutlich kontrollierbarer.

Man bekommt:

einen eigenen VPN-Server
einen Reise-Router für alle Geräte
WireGuard als schnellen Standardweg
OpenVPN TCP als Fallback
Zugriff aufs Heimnetz trotz IPv6-only Anschluss zuhause
eine saubere Trennung zwischen Internet-Traffic und Heimnetz-Traffic
einen brauchbaren Fallback für schwierigere Netze wie China

Gerade für Reisen, öffentliche WLANs oder restriktivere Netze ist das robuster als blind irgendeiner VPN-App zu vertrauen.

Der wichtigste Punkt ist aber nicht die Technik, sondern die Struktur: Ein Hauptweg, ein Fallback und ein sauber gerouteter Heimzugang. Nicht fünf halbfertige Bastellösungen, sondern wenige Wege, die getestet sind. Der normale Internetverkehr läuft über den VPS. Nur Heimnetz-Zugriffe gehen durch den zweiten Tunnel nach Hause.

Das ist der wichtigste Punkt am ganzen Setup. Der VPS ist das zentrale Gateway. Das Heimnetz ist nur ein zusätzlich angebundenes Zielnetz, nicht der normale Internet-Ausgang.

Beispiel-Netze

Bereich	Netz
WireGuard Reise-VPN	`10.66.66.0/24`
WireGuard Server	`10.66.66.1`
OpenVPN Fallback	`10.99.99.0/24`
Home Tunnel	`10.200.200.0/24`
Heimnetz	`192.168.1.0/22`
Home LXC	`192.168.1.50`

Die Adressen sind Beispiele. Wer das nachbaut, sollte die Netze an die eigene Umgebung anpassen. Wichtig ist nur: Reise-VPN, OpenVPN und Home-Tunnel sollten unterschiedliche Netze benutzen.

Teil 1: WireGuard auf dem VPS installieren

WireGuard ist in diesem Setup der Hauptweg. Es ist schnell, schlank und funktioniert sehr gut auf kleinen Routern wie den Geräten von GL.iNet.

WireGuard installieren

apt update && apt upgrade -y
apt install wireguard qrencode -y

Danach werden die Schlüssel für den Server erzeugt.

Server-Schlüssel erzeugen

mkdir -p /etc/wireguard
cd /etc/wireguard

wg genkey | tee server_private.key | wg pubkey > server_public.key

Den Public Key kann man sich anzeigen lassen:

cat /etc/wireguard/server_public.key

Der Private Key gehört nicht veröffentlicht und nicht in Blogartikel, Wikis oder Screenshots.

Teil 2: WireGuard Server-Konfiguration

Die Server-Konfiguration liegt hier:

/etc/wireguard/wg0.conf

In diesem Beispiel läuft WireGuard auf Port 8443/UDP.

WireGuard Server-Konfiguration anzeigen

[Interface]
Address = 10.66.66.1/24
ListenPort = 8443
PrivateKey = SERVER_PRIVATE_KEY

PostUp = iptables -I FORWARD 1 -i wg0 -j ACCEPT
PostUp = iptables -I FORWARD 1 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -s 10.66.66.0/24 -o eth0 -j MASQUERADE

PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -D FORWARD -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -s 10.66.66.0/24 -o eth0 -j MASQUERADE

Das externe Interface muss geprüft werden:

ip route get 1.1.1.1

Wenn dort nicht eth0 steht, muss eth0 in der WireGuard-Konfiguration entsprechend ersetzt werden, zum Beispiel durch ens3.

Teil 3: IP Forwarding aktivieren

Damit der VPS Pakete zwischen VPN und Internet weiterleiten kann, muss IPv4 Forwarding aktiv sein.

IPv4 Forwarding aktivieren

echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/99-wireguard.conf
sysctl --system

Danach WireGuard aktivieren und starten:

WireGuard starten

systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0

Status prüfen:

wg
systemctl status wg-quick@wg0

Firewall öffnen:

ufw allow 8443/udp

Falls zusätzlich eine Cloud-Firewall beim Anbieter aktiv ist, muss der Port dort ebenfalls freigegeben werden.

Teil 4: Automatischer WireGuard Clientgenerator

Clients manuell anzulegen ist fehleranfällig. Deshalb ist ein kleines Script praktisch, das:

eine freie Client-IP sucht
Schlüssel erzeugt
den Peer in wg0.conf einträgt
eine Client-Konfiguration schreibt
WireGuard neu startet
einen QR-Code ausgibt

Das Script liegt hier:

/usr/local/bin/wg-add-client

Clientgenerator anzeigen

#!/bin/bash
set -e

WG_IF="wg0"
WG_DIR="/etc/wireguard"
WG_CONF="$WG_DIR/$WG_IF.conf"
SERVER_IP="DEINE_SERVER_IP_ODER_DOMAIN"
SERVER_PORT="8443"
VPN_NET="10.66.66"
DNS="1.1.1.1"

if [ -z "$1" ]; then
  echo "Nutzung: wg-add-client CLIENTNAME"
  exit 1
fi

CLIENT="$1"
CLIENT_DIR="$WG_DIR/clients"
mkdir -p "$CLIENT_DIR"

if [ -f "$CLIENT_DIR/$CLIENT.conf" ]; then
  echo "Client existiert bereits: $CLIENT"
  exit 1
fi

LAST_IP=$(grep -oP 'AllowedIPs = 10\.66\.66\.\K[0-9]+' "$WG_CONF" | sort -n | tail -1)

if [ -z "$LAST_IP" ]; then
  NEXT_IP=2
else
  NEXT_IP=$((LAST_IP + 1))
fi

if [ "$NEXT_IP" -gt 254 ]; then
  echo "Keine freien IPs mehr"
  exit 1
fi

CLIENT_PRIV=$(wg genkey)
CLIENT_PUB=$(echo "$CLIENT_PRIV" | wg pubkey)
SERVER_PUB=$(wg show "$WG_IF" public-key)

CLIENT_IP="$VPN_NET.$NEXT_IP"

cat >> "$WG_CONF" <<EOF

# $CLIENT
[Peer]
PublicKey = $CLIENT_PUB
AllowedIPs = $CLIENT_IP/32
EOF

cat > "$CLIENT_DIR/$CLIENT.conf" <<EOF
[Interface]
PrivateKey = $CLIENT_PRIV
Address = $CLIENT_IP/24
DNS = $DNS

[Peer]
PublicKey = $SERVER_PUB
Endpoint = $SERVER_IP:$SERVER_PORT
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
EOF

systemctl restart wg-quick@"$WG_IF"

echo
echo "Client erstellt: $CLIENT"
echo "IP: $CLIENT_IP"
echo "Config: $CLIENT_DIR/$CLIENT.conf"
echo

qrencode -t ansiutf8 < "$CLIENT_DIR/$CLIENT.conf"

Script ausführbar machen:

chmod +x /usr/local/bin/wg-add-client

Beispiele für neue Clients:

wg-add-client iphone
wg-add-client tablet
wg-add-client glinet-router

Die fertigen Client-Konfigurationen liegen danach unter:

/etc/wireguard/clients/

Beispiel zum Anzeigen einer Client-Konfiguration:

cat /etc/wireguard/clients/glinet-router.conf

Teil 5: GL.iNet Router einrichten

Der GL.iNet Router verbindet sich unterwegs mit dem verfügbaren Netzwerk, zum Beispiel Hotel-WLAN, Handy-Hotspot oder öffentlichem WLAN. Danach baut er selbstständig den VPN-Tunnel auf.

Dadurch nutzen alle Geräte hinter dem Router automatisch das VPN.

Im GL.iNet Webinterface:

VPN
→ WireGuard Client
→ Add New Profile

Dort wird die zuvor erzeugte Client-Datei importiert.

Der Test sollte nicht im eigenen Heim-WLAN passieren, sondern über einen Handy-Hotspot. Nur so merkt man, ob das Setup wirklich von außen funktioniert.

Test:

curl ifconfig.me

Die Ausgabe sollte die IP des VPS zeigen.

Teil 6: OpenVPN als Fallback

WireGuard ist schnell und effizient, nutzt aber UDP. In manchen Netzen ist UDP instabil oder blockiert. Deshalb läuft zusätzlich OpenVPN über TCP.

OpenVPN ist hier nicht der Hauptweg. Es ist der Rettungsweg.

OpenVPN installieren

apt install openvpn easy-rsa -y

PKI vorbereiten:

OpenVPN PKI vorbereiten

make-cadir /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa

./easyrsa init-pki
./easyrsa build-ca nopass
./easyrsa build-server-full server nopass
./easyrsa build-client-full glinet nopass
./easyrsa gen-dh

openvpn --genkey secret ta.key

Die OpenVPN Server-Konfiguration liegt hier:

/etc/openvpn/server.conf

OpenVPN Server-Konfiguration anzeigen

port 9443
proto tcp
dev tun

ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/server.crt
key /etc/openvpn/easy-rsa/pki/private/server.key
dh /etc/openvpn/easy-rsa/pki/dh.pem

tls-auth /etc/openvpn/easy-rsa/ta.key 0

server 10.99.99.0 255.255.255.0

push "redirect-gateway def1"
push "dhcp-option DNS 1.1.1.1"

keepalive 10 120

cipher AES-256-GCM
auth SHA256

persist-key
persist-tun

user nobody
group nogroup

verb 3

NAT für OpenVPN:

iptables -t nat -A POSTROUTING -s 10.99.99.0/24 -o eth0 -j MASQUERADE

Auch hier gilt: eth0 vorher prüfen und bei Bedarf ersetzen.

OpenVPN starten:

systemctl enable openvpn@server
systemctl start openvpn@server

Firewall öffnen:

ufw allow 9443/tcp

Status prüfen:

systemctl status openvpn@server

Teil 7: OpenVPN Clientdatei für den GL.iNet Router

Für den GL.iNet Router wird eine .ovpn Datei benötigt.

Die Client-Datei kann direkt auf dem Server zusammengesetzt werden.

OpenVPN Clientdatei erzeugen

cat > /etc/openvpn/client-glinet.ovpn <<EOF
client
dev tun
proto tcp
remote DEINE_SERVER_IP_ODER_DOMAIN 9443

resolv-retry infinite
nobind
persist-key
persist-tun

remote-cert-tls server

cipher AES-256-GCM
auth SHA256

key-direction 1

verb 3

<ca>
$(cat /etc/openvpn/easy-rsa/pki/ca.crt)
</ca>

<cert>
$(sed -n '/BEGIN CERTIFICATE/,/END CERTIFICATE/p' /etc/openvpn/easy-rsa/pki/issued/glinet.crt)
</cert>

<key>
$(cat /etc/openvpn/easy-rsa/pki/private/glinet.key)
</key>

<tls-auth>
$(cat /etc/openvpn/easy-rsa/ta.key)
</tls-auth>
EOF

Datei anzeigen:

cat /etc/openvpn/client-glinet.ovpn

Oder herunterladen:

scp root@DEINE_SERVER_IP:/etc/openvpn/client-glinet.ovpn .

Im GL.iNet Webinterface:

VPN
→ OpenVPN Client
→ Upload File

Teil 8: Heimnetz-Tunnel

Der zweite Tunnel verbindet den VPS mit dem lokalen Server zuhause. Darüber werden nur interne Ziele erreicht, zum Beispiel:

Home Assistant
NAS
Proxmox
interne Webdienste

Beispiel:

Heimnetz:       192.168.1.0/22
Home LXC:       192.168.1.50
Tunnelnetz:     10.200.200.0/24
VPS Tunnel IP:  10.200.200.1
Home Tunnel IP: 10.200.200.2

Auf dem Home-LXC wird WireGuard installiert:

apt update
apt install wireguard -y

Die Home-Konfiguration liegt auf dem lokalen LXC hier:

/etc/wireguard/wg-home.conf

Home WireGuard Config anzeigen

[Interface]
Address = 10.200.200.2/24
PrivateKey = HOME_PRIVATE_KEY

PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -i wg-home -j ACCEPT
PostUp = iptables -A FORWARD -o wg-home -j ACCEPT

PostDown = iptables -D FORWARD -i wg-home -j ACCEPT
PostDown = iptables -D FORWARD -o wg-home -j ACCEPT

[Peer]
PublicKey = VPS_PUBLIC_KEY
Endpoint = VPS_IP_ODER_DOMAIN:51830
AllowedIPs = 10.200.200.1/32,10.66.66.0/24
PersistentKeepalive = 25

Home-Tunnel starten:

systemctl enable wg-quick@wg-home
systemctl start wg-quick@wg-home

Status prüfen:

wg
systemctl status wg-quick@wg-home

Wichtig ist der Handshake. Wenn dort latest handshake erscheint, steht der Tunnel.

Teil 9: WireGuard Home-Tunnel auf dem VPS

Auf dem VPS existiert für den Heimtunnel eine eigene WireGuard-Instanz.

Datei:

/etc/wireguard/wg-home.conf

VPS Home-Tunnel Config anzeigen

[Interface]
Address = 10.200.200.1/24
ListenPort = 51830
PrivateKey = VPS_HOME_PRIVATE_KEY

[Peer]
PublicKey = HOME_PUBLIC_KEY
AllowedIPs = 10.200.200.2/32,192.168.1.0/22
PersistentKeepalive = 25

Starten:

systemctl enable wg-quick@wg-home
systemctl start wg-quick@wg-home

Status prüfen:

wg
systemctl status wg-quick@wg-home

Teil 10: Statische Route auf der UniFi Dream Machine Pro

Damit Antworten aus dem Heimnetz zurück zum Reise-VPN finden, braucht die UDM Pro eine statische Route.

Zielnetz	Gateway
`10.66.66.0/24`	`192.168.1.50`

Ohne diese Route passiert der Klassiker: Der VPN-Handshake funktioniert, aber der Zugriff auf interne Geräte nicht.

Teil 11: Tests

WireGuard prüfen:

wg
systemctl status wg-quick@wg0

OpenVPN prüfen:

systemctl status openvpn@server

Home-Tunnel prüfen:

systemctl status wg-quick@wg-home
wg

Routing prüfen:

ip route
iptables -S
iptables -t nat -S

Öffentliche IP prüfen:

curl ifconfig.me

Die Ausgabe sollte die IP des VPS zeigen.

Typische Fehler

WireGuard startet nicht

Prüfen:

journalctl -xeu [email protected]
systemctl status wg-quick@wg0

Häufige Ursachen:

Port bereits belegt
falscher Private Key
kaputte Config
Interface-Name bei NAT falsch
alte iptables-Regeln

Belegte Ports prüfen:

ss -tulpn

Handshake funktioniert, aber kein Internet

Dann liegt es meistens an:

fehlendem IP Forwarding
fehlender NAT-Regel
falschem externem Interface
Firewall-Regeln

Prüfen:

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
iptables -t nat -S

Heimnetz nicht erreichbar

Dann fehlt sehr oft die statische Route auf dem Heimrouter:

10.66.66.0/24 → 192.168.1.50

Oder auf dem VPS fehlt beim Home-Peer das Heimnetz in AllowedIPs:

AllowedIPs = 10.200.200.2/32,192.168.1.0/22

Webseiten laden nur halb

Das ist häufig ein MTU-Problem. In der Client-Config kann helfen:

MTU = 1280

Das ist besonders bei Hotel-WLANs, Mobilfunk und internationalen Verbindungen ein Klassiker.

Fazit

Dieses Setup ist aufwendiger als eine VPN-App. Dafür ist es deutlich kontrollierbarer.

Man bekommt:

einen eigenen VPN-Server
einen Reise-Router für alle Geräte
WireGuard als schnellen Standardweg
OpenVPN TCP als Fallback
Zugriff aufs Heimnetz trotz IPv6-only Anschluss zuhause
eine saubere Trennung zwischen Internet-Traffic und Heimnetz-Traffic
einen brauchbaren Fallback für schwierigere Netze wie China

Gerade für Reisen, öffentliche WLANs oder restriktivere Netze ist das robuster als blind irgendeiner VPN-App zu vertrauen.