Der Wireguard Tunnel soll es erlauben einem Zugriff auf das Heim LAN zu erhalten und gegebenenfalls ein Web-Server im LAN.
Der Zugriff auf das Heim LAN sollte mit ein Rechner (Notebook) oder Smartphone möglich werden. Wenn der Heim-Anschluss nicht über statische Adresse verfügt, ergeben sich Probleme. Ferner sollte der Zugriff über eine verschlüsselte Verbindung stattfinden.
Zur Verschlüsselung des Streams eignet sich Wireguard sehr gut und die Performance sind ausgezeichnet.
Mit wenig Aufwand lässt es sich realisieren. Der Zugriff über IPv4 ist ausreichend, die LAN Adressen können als statisch konfiguriert werden (Die Geräte erhalten von DHCP immer die gleiche Adresse).
Das Protokoll Overhead von IPv4 ist zudem geringer als bei IPv4.
Ein Virtuell-Server kann ab 1 € pro Monat bei Ionos gemietet werden.
Er kann als VPN (Wireguard) Server eingerichtet werden.
Die Einrichtung einem Firewall auf der Server ist bei Ionos nicht nötig, die Virtuelle Maschinen stehen bereits hinter ein Firewall der nur die Ports 22 (ssh), 80 (http) und 443 (https) durchlässt. Für unseren V-Server muss für Wireguard der UDP Port 51820 (im Beispiel) freigeschaltet werden.
Eine einfache Route Anweisung erlaubt es das eigenen Netz zu erreichen. NAT ist nicht notwendig, ein Zugriff auf alle Geräte des LAN ist problemlos möglich.
ip r a 192.168.178.0/24 via 10.18.1.1 dev wg0192.168.178.0/24 ist das LAN
10.18.1.1 ist die IPv4 Adresse des externe Server
#!/usr/bin/bash
### Server Script.
### file: /usr/local/bin/wgs.sh
###Start configuration
CNF=/etc/wireguard/wgs.conf
WG=wg0
MTU=1280 # shall not be lower if we want IPv6
IP=10.18.1.1 # Server IPv4 Address
IPR4=192.168.178.0/24 # LAN IP range
### End configuration
case $1 in
start|up)
ip l add dev $WG type wireguard
sysctl net.ipv4.conf.all.forwarding=1
sysctl -w net.ipv4.ip_forward=1
wg setconf $WG $CNF
ip -4 a a $IP/24 dev $WG
ip link set mtu $MTU up multicast on dev $WG
ip r a $IPR4 via $IP dev $WG
;;
stop|down)
ip link del dev $WG
;;
esac
Damit der Dienst gestartet wird, ist im Verzeichnis /etc/systemd/system ein die systemd Datei wgs.service mit folgenden Inhalt zu erzeugen:
[Unit]
Description=WireGuard Tunnel
After=network-online.target nss-lookup.target
Wants=network-online.target nss-lookup.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/wgs.sh up
ExecStop=/usr/local/bin/wgs.sh down
Environment=WG_ENDPOINT_RESOLUTION_RETRIES=infinity
[Install]
WantedBy=multi-user.targetMit dnsmasq könnte ein einfachen DNS-Server für das Heim LAN installiert werden, der Aufruf wäre einfach:
dnsmasq -a 10.18.1.1 -S 192.168.178.1 -h -R -kMit Unbound ist ein wenig mehr Konfiguration notwendig, es ist aber möglich die Anfragen, entsprechend Domain Name oder IP-Adressen Bereich, an einem vorgegebenen DNS-Server zu senden. Damit kann der DNS-Server des Heim LAN gezielt angesprochen werden, die Anfragen über andere Domäne werden an ein der üblichen DNS-Server, beispielsweise 8.8.8.8 (Google) im Internet gesendet. Dadurch sollte der Weg der DNS Anfrage reduziert. Es ist auch möglich mit dnscrypt die Anfragen zur externen Domäne mittels dnsscript zu senden.
# File unbound.conf
server:
interface: 10.18.1.1 # Liesten on Wireguard interface
access-control: 10.18.1.0/24 allow
access-control: 192.168.0.0/16 allow
so-reuseport: yes
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: no
do-not-query-localhost: no
so-reuseport: yes
domain-insecure: "fritz.box"
private-address: 192.168.0.0/16
private-domain: "fritz.box"
local-zone: "178.168.192.in-addr.arpa" transparent
forward-zone:
name: "fritz.box"
forward-addr: 192.168.178.1
forward-zone:
name: "."
forward-addr: 9.9.9.9
forward-addr: 8.8.8.8Das Program sniproxy kann Web Anfragen an den gewünschter Webserver weiterleiten. Damit können wir HTTP Anfragen, die über der Virtuell-Server geschickt werden zu Systeme im Heim LAN weiterleiten.
user daemon
# PID file
pidfile /var/run/sniproxy.pid
error_log {
# Log to the daemon syslog facility
syslog daemon
# Control the verbosity of the log
priority notice
}
# blocks are delimited with {...}
listen 80 {
proto http
table http_hosts
access_log {
filename /var/log/sniproxy/http_access.log
priority notice
}
}
listen 443 {
proto tls
table https_hosts
access_log {
filename /var/log/sniproxy/https_access.log
priority notice
}
}
# named tables are defined with the table directive
table http_hosts {
.*\.example\.org 192.168.178.3
}
# named tables are defined with the table directive
table https_hosts {
.*\.example\.org 192.168.178.3
}
# if no table specified the default 'default' table is defined
table {
.*\.example\.org 192.168.178.3
}
In diesem Beispiel werden alle http oder https Anfragen, die über der Virtuell-Server ankommen zum Web Server mit der IP-Adresse 192.168.178.3 weitergeleitet. Falls der Virtuell-Server eine IPv6-Adresse zugewiesen wurde, kann auch von Besucher die LAN Web-Präsenz erreicht werden.
Alle Zugriffe auf das Heim LAN erfolgen über ein Gateway Gerät im Heim Netz.
Ein NAS, Raspberry PI oder ein andere Linux Rechner kann verwendet werden.
Die üblichen NAS Geräte (Synology, QNAP,…) verwenden ein ältere Kernel und damit muss die User-Space Version von Wireguard (wireguard-go) verwendet werden. Nachteil sind Geschwindigkeit Einbüsse. Falls ein NAS System vorhanden ist und dauernd im Einsatz ist, muss keinem weiteren System vorhanden sein (Stromverbrauch).
Die Konfiguration auf einem normalen Linux-System, inklusive der Raspberry unterscheidet kaum von der vom Server. Einzig entfällt die Route:
ip r a $IPR4 via $IP dev $WGFalls der Gateway auf ein NAS ohne Wireguard Kernel Unterstützung läuft, ist das Aufziehen des Wireguard Interface ein wenig anders:
… start) wireguard-go $WG … stop) pkill wireguard-go …
Ein Raspberry Pi eignet sich ganz gut dafür. Das Start Script ist nicht besonders.
Die Zeilen:
sysctl net.ipv4.conf.all.forwarding=1
sysctl -w net.ipv4.ip_forward=1können entfallen, wenn es in der Datei /etc/sysctl.conf eingegeben ist.
#!/bin/sh
# Gateway Script
# Configuration
CNF=/etc/wireguard/wgs.conf
WG=wg0
MTU=1320
# LAN Address
IP=10.18.1.2
### End configuration
case $1 in
start|up)
ip link add dev $WG type wireguard
sysctl net.ipv4.conf.all.forwarding=1
sysctl -w net.ipv4.ip_forward=1
wg setconf $WG $CNF
ip -4 address add $IP/24 dev $WG
ip link set mtu $MTU up multicast on dev $WG
;;
stop|down)
ip link del dev $WG
;;
esacDas automatische Starten erfolgt auf der gleichen Art wie auf den Server (siehe oben).
Auf der Smartphone (Android) kann konfiguriert werden welche App auf der Tunnel zurückgreifen.
Damit ist es möglich das SIP-Telefon Verkehr über das Wireguard Tunnel laufen zu lassen. Dafür muss ein DNS Eintrag in der Wireguard Oberfläche eingetragen werden, in dem Fall 10.18.1.1 die Adresse des Wireguard Netz auf den Server. Damit kann eine Namensauflösung über das Wireguard Tunnel erfolgen und es spielt keine Rolle ob es eine Kollision der LAN-Netzwerke gibt (Falls man über WIFI mit das Internet verbunden ist).
Ein Linux “mobile PC” kann das LAN über Wireguard erreichen, einiges muss allerdings beachtet werden.
Falls die Verbindung des PC über der Router einem Bekannten erfolgt, besteht die Gefahr, dass die LAN Adresse der jeweiligen Router die gleiche sind. In dem Fall darf nur der Verkehr zur externen Adresse des Wireguard Server über den Router des bekannte laufen, der Rest sollte den Weg über Wireguard nehmen.
Im Beispiel Script erfolgt die DNS Auflösung mittels systemd-resolved. Damit werden alle DNS Anfragen mit der Domäne “fritz.box” über den Tunnel geleitet.
#!/bin/sh
# Client script
########################
# Tunnel Configuration #
########################
WG=wg0 # May be set to an other name
CNF=/etc/wireguard/wg0.conf # Wireguard configutartion file
IP0=10.18.1.3 # Our tunnel address
# IP/Domain for the LAN
DNS=10.18.1.1 # DNS server at home (via Wireguard)
IPR=192.168.178.1 # LAN Address for our home router
DOMAIN="fritz.box" # Search domain for address resolution of our LAN device
IPRN=192.168.178.0/24 # LAN IP range
# Tunnnel
# MTU and interface name
MTU=1320 # The MTU shall not be less than 1280, the default value
########################
# End of configuration #
########################
getDevGwSrc() {
GATEWAY=`ip r get 1.1.1.1 | awk '{print $3;exit}'`
DEV=`ip r get 1.1.1.1 | awk '{print $5;exit}'`
SRC=`ip r get 1.1.1.1 | awk '{print $7;exit}'`
}
case $1 in
start|up)
getDevGwSrc
ip link add dev $WG type wireguard
wg setconf $WG $CNF
ip link set mtu $MTU up multicast on dev $WG
echo nameserver $DNS | resolvconf -a $WG -m 0 -x
resolvectl default-route $DEV 0
ip address add $IP0/24 dev $WG
ip route add $IPRN via $IP0 dev $WG
resolvectl domain $WG $DOMAIN
resolvectl default-route $WG
;;
stop|down)
ip link del dev $WG
getDevGwSrc
resolvectl default-route $DEV 1
;;
esacDie Konfiguration von Linphone oder des verwendeten SIP-Telefons Software ist für beide Verbindung (im Heim LAN oder fremden Netz) identisch.
Wenn es im Heim LAN funktioniert, sollte es auch im fremden LAN über das Wireguard Tunnel funktionieren.
Wenn Firewall in den einzelnen Systemen verwendet werden, muss der Zugriff über der Wireguard VPN Netz, im Beispiel 10.18.1.0/24, Port 51820 erlaubt werden.
Ferner sollten alle infrage kommende Ports die im Heim-Bereich vorhanden sind auch über die Wireguard-Verbindung erreichbar sein.
Wenn firewalld und das NetworkManager verwendung finden, kann der Wireguard Interface die passende Zone, beispielsweise “home”, zugeordnet werden. Dies kann mit das Editieren der Verbindungseinstellung vorgenommen werden. Alternativ kann es per Script erfolgen:
# Look for possibly assigned zone.
zone=`firewall-cmd --get-zone-of-interface=wg0 2>/dev/null`
case "$zone" in
home)
# All is okay, nothing to do
;;
"") # Set the wanted zone (home)
firewall-cmd --zone=home --add-interface=wg0 >/dev/null 2>&1
;;
*) # A Zone ist allready set and ist not the wanted zone.
# Remove old setting
firewall-cmd --zone=$zone --remove-interface=wg0 >/dev/null 2>&1
# Set the wanted zone (home)
firewall-cmd --zone=home --add-interface=wg0 >/dev/null 2>&1
;;
esacIm Beispiel ist die Zone Zuweisung temporär und sofort aktive.
Ein Windows PC kann auch für der ZUgriff auf unserer LAN dienen. Mit nachfolgende Konfiguration het es:
[Interface]
PrivateKey = KB0oMJwc5XcmrbkOX41KCYlqz52/c8xZGXM92B6cMXY=
Address = 198.18.1.9/32
DNS = 198.18.1.1, fritz.box
[Peer]
PublicKey = 7+up81rvQRHGGktf9Sizu9iJV/gqJyQZcMIiyGFMFTc=
AllowedIPs = 198.18.1.0/24, 192.168.178.0/24
Endpoint = 82.165.252.150:1197
PersistentKeepalive = 25Damit der Verkehr vom VPN Netz 10.10.1.0/24 die verschiedene Systeme im Heim LAN erreichen können muss eine IPv4 Route in der Fritz!Box eingetragen werden.
Unter Netzwerk Reiter Netwerkeinstellungen wählen und [IPv4-Routen] klicken. In der neuen Seite [Neue IPv4-Route] klicken und in der Maske:
IPv4-Netzwerk
10.18.1.0
Subnetzmaske
255.255.255.0
Gateway
10.18.1.2eintragen und IPv4-Route aktiv setzen. Nach der Übernahme kann vom Wireguard Tunnel aus auf alle Geräte des LAN zurückgegriffen werden.
10.18.1.2 ist die IPv4-Adresse des Wireguards Gateway
Falls auf eine IPv4 Adresse verzichtet werden kann und die IPv6 Adressen im LAN sich nicht ändern, ist es möglich auf eine externen V-Server zu verzichten.
In dem Fall ist lediglich ein Wireguard-Server im LAN nötig. Der DNS-Server und SNI-Proxy sind auch überflüssig.
Das Startscript für eine NAS (Synology, QNAP, …) mit installierten Entware könnte wie nachstehend aussehen.
### Begin configuration
USERSPACE=true
CNF=/opt/etc/wireguard/wg0.conf
WG=wg0
MTU=1280 # shall not be lower if we want IPv6
# LAN Address
IP=18.18.1.1
### End configuration
# /opt/etc/init.d/S... part for Entware start script
ENABLED=yes
PREARGS=""
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
. /opt/etc/init.d/rc.func
PATH=$PATH:/opt/bin
case $1 in
start|up)
modprobe tun # if module not installed!
if [ "$USERSPACE" == "true" ]
then
wireguard-go $WG
else
ip l add dev $WG type wireguard
fi
wg setconf $WG $CNF
ip -4 a a $IP/24 dev $WG
ip link set mtu $MTU up dev $WG
;;
stop|down)
if [ "$USERSPACE" == "true" ]
then
pkill wireguard-go
else
ip link del dev $WG
fi
;;
check)
ip l sh dev $WG >/dev/null 2>&1
if [ $? -eq 0 ]
then
echo alive
else
echo stopped
fi
;;
esac[Interface] # server
PrivateKey = 8PxZem9dX51lfBLtMYiZWCN+cbbAf0fpXkFpWg86bUo=
ListenPort = 51820
[Peer] # gateway
PublicKey = sPrgKJnil5OVAD7GxPQn3k/QUE7qEFuOzyl6NKXqHUg=
AllowedIPs = 10.18.1.2/32, 0.0.0.0/0, ::/0
[Peer] # notebook
PublicKey = DKquA3gQcNAdu2++mSbNTWHs/HONgpn/oiq1K0L76nA=
AllowedIPs = 10.18.1.3/32, 0.0.0.0/0, ::/0
[Peer] # smartphone
PublicKey = j7vTblFlIxYNsk0t+TfGAAUwoVpbV0ECjxNjPg23DnA=
AllowedIPs = 10.18.1.4/32, 0.0.0.0/0, ::/0[Interface] # gateway
PrivateKey = iIaoYPTIuZPoCWWnQUBQdWU+ip6/+1UvWpNVTzM/lVg=
[Peer] # Server
PublicKey = QE2uUsPxiTFqmKhTD0GRO1TWN1orE/r5CVXM7vrJ1Ug=
AllowedIPs = 0.0.0.0/0, ::/0
EndPoint = 192.0.2.1:51820
PersistentKeepAlive = 25[Interface] # notebook
PrivateKey = CFgQS42SdqOKR/L5AOGC9IvwCsL1tLvrl01aWtnKjVs=
[Peer] # Server
PublicKey = QE2uUsPxiTFqmKhTD0GRO1TWN1orE/r5CVXM7vrJ1Ug=
AllowedIPs = 0.0.0.0/0, ::/0
EndPoint = 192.0.2.1:51820
PersistentKeepAlive = 25[Interface] # smartphone
PrivateKey = 6A2RF9uEWWGxBHdKxvW87spfmY7wHv73NtKWym2bamQ=
[Peer] # Server
PublicKey = QE2uUsPxiTFqmKhTD0GRO1TWN1orE/r5CVXM7vrJ1Ug=
AllowedIPs = 0.0.0.0/0, ::/0
EndPoint = 192.0.2.1:51820[Interface]
PrivateKey = KB0oMJwc5XcmrbkOX41KCYlqz52/c8xZGXM92B6cMXY=
Address = 198.18.1.9/32
DNS = 198.18.1.1, fritz.box
[Peer]
PublicKey = 6A2RF9uEWWGxBHdKxvW87spfmY7wHv73NtKWym2bamQ
AllowedIPs = 10.18.1.0/24, 192.168.178.0/24
Endpoint = 192.0.2.1:51820
PersistentKeepalive = 25