Wireguard Site to Site VPN

Einen Wireguard Site to Site VPN Tunnel einrichten

Wireguard ist eine open Source VPN Lösung. Der Server, welcher hierbei als VPN Gateway fungiert, läuft im Regelfall auf einem Unix basierten OS, meist im internen Netz des Firmennetzwerks. Die Clients wiederum sind für nahezu alle Client Betriebssysteme verfügbar. Das mache ich mir zunutze, denn man kann auf diese Weise einen Client im lokalen Netzwerk (Homeoffice?) bereithalten, der stets eine Verbindung zum Firmennetzwerk aufbaut. Alle anderen PC’s im lokalen Netzwerk, können dann via statischer Route so konfiguriert werden, dass Anfragen in das Netz der Company über diesen Client geroutet werden. Das erübrigt bspw., dass ein Client im Netzwerk eine SSL-VPN Verbindung zur Company aufbauen muss.
Damit das System ständig laufen kann, sollte es ein kleines, kompaktes Gerät, mit wenig Stromverbrauch sein. Was eignet sich hier besser, als ein Raspberry Pi? Wie man den installiert, hab ich hier umfassend beschrieben.
Die „Software“ Wireguard an sich, macht aus Sicht der Installation übrigens keinen Unterschied zwischen „Server“ und „Client“, man spricht hier von sog. „Peers“. Lediglich die Konfigurationsdatei unterscheidet sich zwischen dem Server und den Clients, also den „Peers“.

Achtung Sicherheit und Flexibilität!
Wireguard benötigt auf der Client Seite einen entsprechend freigeschalteten ausgehenden UDP Port, welcher frei definierbar ist, aber auch freigeschaltet sein muss! (Hotel Hotspots, Flughafen Hotspots, etc. öffnen im Regelfall lediglich TCP 80 (HTTP), TCP 443 (HTTPS) und selten auch UDP 53 (DNS). Diese Ports können NICHT für Wireguard verwendet werden!

Auf der Server Seite muss ein Admin ran, denn der Wireguard Server muss auf dem konfigurierten Port, aus dem Internet erreichbar sein! Wer jetzt die Idee hat, UDP 53 (DNS) hierfür zu verwenden, wird vermutlich scheitern, denn Wireguard verhindert „by Design“ den Start der Wireguard VPN Schnittstelle auf diesem Port, da hier im Regelfall bereits „resolved/dnscrypt-proxy“ horcht. Nachzulesen ist dieses Problem auch hier.

Das Prinzip

Folgendes Schema dient bei der Installation als Orientierung. Eine Konstellation, die man durchaus häufiger vorfinden dürfte. Im Schema ist beispielhaft nur ein Client dargestellt, dies können natürlich im weiteren Betrieb durchaus mehr werden.

Network Overview

Grundsätzlicher Ansatz und Vorbereitungen

  • Definition des zentralen Serversystems, wie Standort, Plattform, Netzwerk (hier Labor, VM mit Raspian Desktop, Servernetz)
  • Definition der Server Management IP (10.150.150.10/24)
  • Definition des SEPARATEN Wireguard Netzwerks, welches mit keinem bestehenden Teilnetz „überlappt“. (10.172.172.0/24)
  • Definition der Server IP im Wireguard Subnetz (10.172.172.1/24)
  • Definition der Client IP(s) (10.172.172.11/24)
  • Definition der öffentlichen IP / des öffentlichen DNS Namens, des Servers im Company Netzwerk (hier nicht veröffentlicht)

Konfigurationsschritte „Serverseite“

  • Installation Raspian Buster Desktop
  • SSH aktivieren
  • Konfiguration der lokalen IP im Firmennetz, die nur dem Management des Servers dient (10.150.150.10/24)
  • Konfiguration eines weiteren Interfaces – der Wireguard NIC – im Beispiel „wg0-server“. (10.172.172.1/24)
  • Installation Wireguard
  • Konfiguration Wireguard, gemäß der obigen Festlegungen
  • Konfiguration der erlaubten Client Zugriffe, anhand der Client IP und des Client Public Key. (10.172.172.11/24)
  • Veröffentlichung des Servers (DNAT) am WAN Anschluss der Firewall, um die Client Verbindungen zu ermöglichen. Den Destination Port habe ich im Beispiel auf 51238 festgelegt.
  • Test der Client VPN Zugriffe

Konfigurationsschritte am Client

  • Installation Raspian Buster
  • SSH aktivieren
  • Konfiguration der lokalen IP (dies kann durchaus eine dynamische IP sein)
  • Installation Wireguard für das entsprechende Betriebssystem
  • Konfiguration Wireguard für das entsprechende Betriebssystem, gemäß der obigen Festlegungen
  • Test des VPN Zugriffs und des zugriffs auf die internen Systeme

Vorbereitung des Client im Homeoffice

(hier ein Raspberry „Pi 3 Model B“)

Kurzversion für Fortgeschrittene:

  • Raspi mit Kabel an die FritzBox
  • Auf dem Raspberry „Raspbian Buster Lite“ an den Start bringen
  • SSH aktivieren
  • Hostname anpassen

Für alle anderen hier Step by Step…

  1. In meinem Fall ist der Raspberry via LAN Kabel, direkt an die FritzBox angeschlossen
  2. Jetzt eine SD-Karte mit dem Raspberry-OS (bei mir die Variante „Raspbian Buster Lite“) und dem „Raspberry Pi Imager for Windows“ flashen… Es gibt auch andere Tools (bspw. „Balena Etcher“), für ein originales Raspian reicht das aber…
    [wpdm_package id=’1027′]
  3. Raspian Buster holen –> https://www.raspberrypi.org/downloads/raspbian/
  4. Achtung!
    Nach dem Flashen der SD-Karte, diese nochmal in den PC stecken, nach dem Laufwerk „Boot“ suchen und hier eine leere Datei, OHNE Endung, mit dem Namen „ssh“ erstellen. Damit wird automatisch SSH am Raspi aktiviert und man muss nicht mit Tastatur, Maus und Monitor rumhampeln. Standardmäßig wird der Raspi sich die IP von der FritzBox holen und ist dann via SSH auf dieser IP erreichbar.
  5. Jetzt via SSH am Raspi anmelden. Default Login am Raspi ist immer –> User: pi Passwort: raspberry
  6. Zuerst natürlich das Passwort ändern!
  7. Dann ändern wir den Hostnamen (in meinem Beispiel soll das System „wireclient“ heißen
    Check den akuellen Namen (notieren, brauchen wir nachher nochmal)

    hostname

    Jetzt ändern wir den Namen mit…

    sudo hostname -b wireclient

    Check neuen Hostname…

    hostname

    Suchen, wo der Name noch verwendet wird… (jetzt brauchen wir den alten Namen nochmal, der jetzt zwischen die Hochkommas kommt…)

    sudo grep -lr "alter Name" /etc/*

    Hier im Beispiel nur das Ergebnis, der Hostname ist schon geändert. Die Dateien /etc/ssh… können hier ignoriert werden, diese werden bei der Neuerstellung der SSH Keys automatisch angepasst…

    Jede Datei, in welcher der Name vorkommt anpassen, hier zum Beispiel in der Datei „hosts“ (lokales DNS Resolve)

    sudo nano /etc/hosts

  8. IP Adresse fest vergeben (hier die Variante via dhcpd) 
    sudo service dhcpcd status
sudo service dhcpcd start
sudo systemctl enable dhcpcd
sudo nano /etc/dhcpcd.conf

    Beispielkonfig

    interface eth0
static ip_address=192.168.100.10/24
static routers=192.168.100.1
static domain_name_servers=192.168.100.1
  9. Abschluss mit… 
    sudo reboot

Vorbereitung des Servers in der Company (Hyper-V VM, Raspian Buster Desktop)

  1. Virtuelle Maschine erstellen
  2. Raspian Desktop herunterladen und bereitstellen…
  3. SSH aktivieren, also Konsole öffnen 
    sudo systemctl enable ssh
sudo systemctl start ssh
  4. Hostname anpassen (siehe Client)
  5. IP Adresse anpassen (siehe Client)
    Beispielkonfig

    interface eth0
static ip_address=10.150.150.10/24
static routers=10.150.150.250
static domain_name_servers=10.1.110.1

Wireguard Installation und Konfiguration

Die Installation ist auf dem PI und dem Server identisch.

Installation Wireguard auf Raspian Buster

  1. Installation Wireguard und Tools…
    Zeile für Zeile in die SSH Console des Raspi kopieren…

    sudo apt-get update
sudo apt-get upgrade 
sudo apt-get install raspberrypi-kernel-headers
echo "deb http://deb.debian.org/debian/ unstable main" | sudo tee --append /etc/apt/sources.list.d/unstable.list
sudo apt-get install dirmngr 
wget -O - https://ftp-master.debian.org/keys/archive-key-$(lsb_release -sr).asc | sudo apt-key add -
printf 'Package: *\nPin: release a=unstable\nPin-Priority: 150\n' | sudo tee --append /etc/apt/preferences.d/limit-unstable
sudo apt-get update
sudo apt-get install wireguard 
sudo reboot
  2. Konfiguration Wireguard
    • Privaten und öffentlichen Schlüssel des Clients erstellen
      Erstellen des Wireguard Verzeichnis

      sudo mkdir /etc/wireguard/

      Wechsel ins Wireguard Verzeichnis

      cd /etc/wireguard

      Generieren des privaten Schlüssels mit dem Wireguard Tool

      wg genkey > private.key

      Erstellen des Öffentlichen Schlüssels, welcher aus dem privaten Schlüssel generiert wird

      wg pubkey > public.key < private.key

      Public Key anzeigen mit…

      cat public.key

      Private Key anzeigen mit…

      cat private.key
    • Konfiguration am Client 
      sudo nano /etc/wireguard/wg0.conf

      Hier die Beispielkonfig gemäß Zeichnung, die auf dem Server natürlich vice versa anzupassen ist. Die Zeile „Endpoint“ im Bereich [Peer] ist am Server nicht erforderlich! Die beiden Zeilen in der Mitte (PostUp…) sorgen dafür, dass Anfragen des Client in das lokale Netzwerk geroutet werden, um so die „dahinter liegenden“ Systeme zu erreichen.

      [Interface]
Address = 172.20.20.11/24
PrivateKey = ClientPrivateKeyMussHierRein
ListenPort = 51238
 

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
Endpoint = server.public.dns.com:51238
PublicKey = ServerPublicKeyMussHierRein
AllowedIPs = 10.0.0.0/8,172.20.20.0/24
PersistentKeepalive = 25
    • Lassen wir Wireguard automatisch starten… 
      sudo systemctl enable wg-quick@wg0
  3. Wenn die Client Konfig fertig ist, Wireguard am Server auf identische Art und Weise bereitstellen und dann wäre das die Serverkonfig… 
    [Interface]
PrivateKey = ServerPrivateKeyMussHierRein
ListenPort = 51238
Address = 172.20.20.1/24

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = ClientPublicKeyMussHierRein
AllowedIPs = 172.20.20.0/24,192.168.100.0/24
PersistentKeepAlive = 25
  4. Wenn beide Seiten fertig sind, der Server bspw. via DNAT veröffentlicht wurde, starten wir Wireguard auf beiden Seiten mit: 
    sudo wg-quick up wg0

    Jetzt heißt es testen, also am Raspi Client bspw.
    Status der Verbindung anzeigen:

    sudo wg show

    Idealerweise sieht man (hier bspw. am Pi-Client) den Datenfluss sendend und empfangend…

    oder ein klassischer Ping auf die Gegenseite…

    ping 172.20.20.1

    Ist die Antwort positiv, steht zunächst der Tunnel zwischen den Peers, Step 1 war also erfolgreich…

  5. Möchte man jetzt bspw. von anderen Clients im Peer Netz 192.168.100.0/24 auf die Gegenseite zugreifen, muss dem Client noch die Route über den Wireguard Peer mitgeteilt werden. Dazu wird in meinem Beispiel auf der Fritzbox eine Statische Route eingerichtet:
    Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> IP Routen
  6. Jetzt wieder testen, also dieses Mal von einem Client im Peer Netz, hinter der Fritzbox einen Ping auf 10.xx.xxx.xxx. absetzen… War das ebenfalls erfolgreich, kann jetzt aus dem Netz 192.168.100.0/24, auf alle Systeme im 10.0.0.0/8 Netz zugegriffen werden.
Beitrag Teilen

Ein Kommentar

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Seite ist durch reCAPTCHA und Google geschütztDatenschutz-Bestimmungen UndNutzungsbedingungen anwenden.

Interessante Beiträge

Cropped Fortinet
Fortigate FortiOS 7.2.4 – recover lost admin password
Wdoof
Windows Zeitservice – Cheat Sheet