WireGuard: Zugang von unterwegs

Vorstand und Übungsleitung sollen auch von zu Hause oder vom Bootssteg an Paperless und Co. kommen, ohne dass diese Dienste offen im Internet stehen. Dafür bekommt der Verein ein eigenes kleines VPN mit WireGuard.

Wie das Vereins-VPN funktioniert

• Eigener Container: WireGuard läuft im Container vpn (ID 208, 192.168.178.208). Die FRITZ!Box leitet nur einen UDP-Port dorthin weiter.
• Nur der Verein läuft durch den Tunnel: Auf dem Handy gehen nur die Vereinsdienste durchs VPN, alles andere wie gewohnt direkt ins Internet. Das schont Akku und Anschluss.
• Nur bis zum Proxy: Wer im VPN ist, erreicht ausschließlich den Proxy auf den Ports 80 und 443, also die Weboberflächen. Kein Heimnetz, kein Proxmox, kein SSH.
• Ein Zugang pro Person: Jede Person bekommt einen eigenen Schlüssel als QR-Code. Scheidet jemand aus, wird genau dieser Zugang gesperrt.

Warum nicht das VPN der FRITZ!Box? Das geht auch, öffnet aber das ganze Heimnetz. Mit einem eigenen Container lässt sich genau festlegen, was erreichbar ist, und das Vereins-VPN bleibt vom privaten getrennt.

Schritt 1: WireGuard auf dem Host

Ein LXC-Container nutzt den Kernel von Proxmox. Deshalb muss das WireGuard-Modul auf dem Host geladen sein, dauerhaft auch nach einem Neustart:

# auf dem Proxmox-Knoten
modprobe wireguard
echo wireguard > /etc/modules-load.d/wireguard.conf

Schritt 2: Der Container

Container 208 anlegen wie im Kapitel Ein Container pro Dienst, mit 1 Kern und 256 MB. Docker braucht er nicht. Dann:

apt install -y wireguard-tools iptables qrencode dnsmasq
umask 077
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub

Schritt 3: Die Schnittstelle wg0

Das Tunnelnetz ist 10.77.0.0/24. Es darf sich mit keinem anderen Netz überschneiden, auch nicht mit einem VPN, das man privat schon nutzt. Der Server bekommt 10.77.0.1, der UDP-Port ist 51821.

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.77.0.1/24
ListenPort = 51821
PrivateKey = <Inhalt von server.key>
PostUp = /usr/local/sbin/vpn-regeln up
PostDown = /usr/local/sbin/vpn-regeln down

Die Regeln, die beim Start greifen, legen fest, was aus dem Tunnel erlaubt ist: weiterleiten nur zum Proxy auf 80 und 443, den Container selbst nur für DNS erreichen. Alles andere wird verworfen.

#!/usr/bin/env bash
# /usr/local/sbin/vpn-regeln   (chmod 700)
PROXY=192.168.178.201
iptables -D FORWARD -j VPN 2>/dev/null;      iptables -F VPN 2>/dev/null;    iptables -X VPN 2>/dev/null
iptables -D INPUT -i wg0 -j VPN-IN 2>/dev/null; iptables -F VPN-IN 2>/dev/null; iptables -X VPN-IN 2>/dev/null
iptables -t nat -D POSTROUTING -s 10.77.0.0/24 -o eth0 -j MASQUERADE 2>/dev/null
[ "$1" = down ] && exit 0

sysctl -qw net.ipv4.ip_forward=1
# Weiterleiten: aus dem Tunnel nur zum Proxy auf 80/443
iptables -N VPN
iptables -A VPN -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A VPN -i wg0 -d $PROXY -p tcp -m multiport --dports 80,443 -j ACCEPT
iptables -A VPN -i wg0 -j DROP
iptables -A VPN -o wg0 -j DROP
iptables -I FORWARD -j VPN
# Den Container selbst: aus dem Tunnel nur DNS
iptables -N VPN-IN
iptables -A VPN-IN -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A VPN-IN -p udp --dport 53 -j ACCEPT
iptables -A VPN-IN -p tcp --dport 53 -j ACCEPT
iptables -A VPN-IN -j DROP
iptables -I INPUT -i wg0 -j VPN-IN
# Der Proxy sieht VPN-Nutzer als 192.168.178.208 (eigenes Netz, also kein 403)
# und braucht keine Route ins Tunnelnetz
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o eth0 -j MASQUERADE

systemctl enable --now wg-quick@wg0
wg show

Schritt 4: DNS für VPN-Nutzer

Unterwegs fragt das Handy nicht die FRITZ!Box nach dms.meinverein.internal, und im Internet ist der Name gar nicht bekannt. Deshalb beantwortet der VPN-Container die Namen selbst, aber nur im Tunnel:

# /etc/dnsmasq.d/vpn.conf
interface=wg0
bind-dynamic
no-resolv
server=192.168.178.1
address=/meinverein.internal/192.168.178.201
cache-size=1000

Damit dnsmasq erst nach dem Tunnel startet, bekommt der Dienst eine kleine Ergänzung per systemctl edit dnsmasq: [Unit] und darunter After=wg-quick@wg0.service. Danach systemctl restart dnsmasq.

Schritt 5: Ein Zugang pro Person

Für jede Person ein Schlüsselpaar und eine eigene Tunnel-Adresse. Auf dem Server kommt ein [Peer]-Block in die wg0.conf:

key=$(wg genkey); pub=$(echo "$key" | wg pubkey); psk=$(wg genpsk)

cat >> /etc/wireguard/wg0.conf <<PEER

# Zugang: anna
[Peer]
PublicKey = $pub
PresharedKey = $psk
AllowedIPs = 10.77.0.2/32
PEER

wg syncconf wg0 <(wg-quick strip wg0)    # übernehmen, ohne den Tunnel zu trennen

Und die Gegenseite für das Handy oder den Laptop. Unter AllowedIPs steht nur der VPN-DNS und der Proxy: Das ist der Teil, der durch den Tunnel geht.

[Interface]
PrivateKey = <key von oben>
Address = 10.77.0.2/32
DNS = 10.77.0.1

[Peer]
PublicKey = <Inhalt von server.pub>
PresharedKey = <psk von oben>
Endpoint = abcd1234efgh5678.myfritz.net:51821
AllowedIPs = 10.77.0.1/32, 192.168.178.201/32
PersistentKeepalive = 25

Als Endpoint dient die MyFRITZ!-Adresse der FRITZ!Box (Internet → MyFRITZ!-Konto) oder ein eigener DynDNS-Name. Mit qrencode -t ansiutf8 < anna.conf erscheint der QR-Code im Terminal. In der WireGuard-App: Tunnel hinzufügen → QR-Code scannen. Gesperrt wird ein Zugang, indem man seinen [Peer]-Block wieder entfernt und wg syncconf erneut ausführt.

Schritt 6: Port in der FRITZ!Box freigeben

Unter Internet → Freigaben → Portfreigaben den Container 192.168.178.208 auswählen und UDP 51821 freigeben. Nur diesen einen Port.

Der Test: Am Handy WLAN aus, VPN an und https://dms.meinverein.internal öffnen. Erscheint Paperless, läuft alles. Mit wg show sieht man auf dem Server, wann sich welcher Zugang zuletzt gemeldet hat.

Weiter: Paperless-ngx →