VPN-Netz mit Raspi, Wireguard und Pi-hole

Home- oder Branch Office mit dem Firmennetz verbinden

<<< Installation Wireguard auf Raspberry Pi <<< | >>> Installation Wireguard auf Ubuntu Server LTS 20.04 >>>

In diesem Beitrag versuche ich zu erläutern, was Pi-hole und Wireguard miteinander zu tun haben, bzw. warum es eine gute Idee ist, beide Lösungen zu kombinieren.
Das Design des Wireguard VPN Netzwerkes ist entscheidend. Wer meinen Beitrag Wireguard auf Raspberry Pi noch nicht gelesen hat, hier noch einmal ein Beispiel-Schema…

Definieren wir folgende Vorgaben, um das Thema besser zu verstehen:

Die Aufgabe / der Use Case

- Ziel soll es sein, von mehreren Homeoffices oder kleineren Branch Offices ein System am Hauptstandort zu erreichen.
- Ein VPN soll die Verbindung verschlüsseln und es soll hierbei kein VPN Client auf den Laptops oder PCs der Mitarbeiter an den Edge Standorten oder in den Homeoffices installiert werden.
- Alle Clients im Edge Netzwerk sollen einen Applikationsserver am Hauptstandort, unter seinem FQDN erreichen können. Die Bereitstellung ist ein Hub (Zentraler Standort) and Spoke (Homeoffice(s) oder Edge Staort(e)) VPN, kein Mesh
- Für diese Aufgabe soll ein leistungssparendes System eingesetzt werden, welches 24×7 in Betrieb ist.

Edge Netzwerk (Homeoffice/Branch Office)

- Die Lokale Netzwerkadresse unseres Beispiel Client im Homeoffice lautet 192.168.100.48/24. Die Adresse wird via DHCP von einer FritzBox vergeben.
- Die Fritzbox hat die IP 192.168.100.1/24.
- Der Raspberry Pi hat die lokale IP 192.168.100.10, welche fest vergeben wurde und die Wireguard VPN Adresse 172.20.20.11/24

Lab Netzwerk

- Der Wireguard Server in der Company steht in einem dedizierten Netzwerk-Segment (DMZ), hat die lokale IP 10.150.150.10/24 und die Wireguard VPN Adresse 172.20.20.10/24.
- Der DNS Server für die Namensauflösung im Lab hat die IP 10.1.110.1.
- Die Adresse des Servers, welcher in einem Test Lab der Company zu erreichen ist, lautet 10.1.110.3/24 und der FQDN des Servers lautet server1.lab.net.

Hardware- und Software-Lösung

Ein Raspberry Pi Modell 3B+, mit Raspi OS Lite (headless), am Edge Standort. Kosten aktuell ca. 80,- €
Hinweis: Um die Leistungsfähigkeit zu erhöhen, kann hier auch das Nachfolgemodell Raspberry Pi 4B eingesetzt werden und dieser dann mit 1Gbit (statt 200 Mbit beim Raspi 3B) am LAN Anschluss der FritzBox verwendet werden. Kosten aktuell ca. 170,-€ Am Prinzip der Lösung ändert das nichts.
Ubuntu Server LTS 20.04 als virtuelle Maschine / alternativ auch hier ein Raspi, am Hauptstandort, in der DMZ.
Pi-hole als Webfilter, und DNS Server am Edge Standort, ebenfalls auf dem Raspi.
Am Edge Standort existiert ein Internet Anschluss mit dynamischer IP und einer FritzBox, die gleichzeitig als Router und WLAN AP fungiert.
Am Hauptstandort existiert ein Internet Anschluss mit fester IP und einer Hardware Firewall.

Hilfreiche Beiträge

Notwendige Schritte am zentralen Standort

Bereitstellung Ubuntu als Wireguard Server (Beitrag siehe oben)
Einrichten des DNAT, Port Forward oder noch besser eines Reverse Proxy für die Verbindung auf UDP Port 51238,, direkt auf den Ubuntu Wireguard Server (bei mir in einer DMZ)
Anlegen eines öffentlichen DNS A-Record für die Verbindung der Peers zum zentralen Standort

Notwendige Schritte im Homeoffice oder Edge Office

Kurzfassung

Bereitstellung Wireguard „Server“ und Pi-Hole auf Raspberry Pi (Beiträge siehe oben)
Pi-Hole „Conditional Forwarding konfigurieren
Konfigurationen am lokalen Router
- DHCP Scope anpassen und den Raspi als DNS Server für alle Clients festlegen
- Hinzufügen weiterer Routen, um den Traffic zum Hauptstandort in den Wireguard tunnel zu routen

Ausführliche Beschreibung

Damit die Clients den Applikationsserver (Fileserver, Terminalserver, ERP etc…) über seinen FQDN erreichen können, muss man „irgendwie“ sicherstellen, dass für die Namensauflösung der korrekte DNS Server (natürlich am Hauptstandort) verwendet wird. Da die msiten Router, speziell im Homeoffice, selten „Conditional Forwarding“ unterstützen, machen wir uns den dnsmasq srvice des Pi-Hole zu Nutze. Natürlich kann Pi-Hole auch seine Aufgabe als DNS Filter erfüllen, das aber nur bei Bedarf.

Am Beispiel einer FritzBox 6590 mit FritzOS 7 und neuer, erläutere ich zunächst die Einstellungen, welche gemäß unserem Schema (siehe oben) vorgenommen werden müssten.

Routing auf der FritzBox für das Netz am Hauptstandort einrichten
- - An der Firtzbox anmelden
  - Im Menü jetzt auf Heimnetz -> Netzwerk und jetzt im Tab oben auf Netzwerkeinstellungen klicken.
  - Jetzt nach unten scrollen und im Abschnitt IP Adressen auf IPv4-Routen klicken
  - Auf neue Route klicken und folgenden Eintrag hinzufügen, die Route aktiv schalten und den Eintrag speichern.
    Achtung, in der Übersicht auch den Button „Übernehmen“ einmal klicken und auch im folgenden Fenster „Netzwerkeinstellungen“ noch einmal auf „Übernehmen“ klicken!
Ab jetzt werden alle Pakete, welche an das o.g. Netzwerk des Hauptstandort gesendet werden, zum Raspi und damit in den Wireguard Tunnel geroutet.
Den DNS Server, im lokalen Netzwerk auf den Raspi (Pi-Hole) umstellen
- - An der FritzBox anmelden
  - Im Menü jetzt auf Heimnetz -> Netzwerk und jetzt im Tab oben auf Netzwerkeinstellungen klicken.
  - Jetzt nach unten scrollen und im Abschnitt IP Adressen auf IPv4-Konfiguration klicken
  - Jetzt im Abschnitt Heimnetz, bei Lokaler DNS-Server die IP des Raspi, also 192.168.100.10 eintragen
- Nach einem Reboot der Clients oder einem erneuern des DHCP-Lease der Clients, verwenden diese ab sofort ausschließlich den Raspberry Pi als DNS Server.
  Ja nachdem was am Pi-Hole konfiguriert wurde, werden in der Pi-Hole GUI jetzt nach und nach die lokalen Clients und deren DNS Anfragen sichtbar.
- In Edge Offices empfehle ich die Einstellungen zum Logging unter Settings -> Privacy auf „Anonymous mode: This disables basically everything except the live anonymous statistics“ zu setzen, um dem Datenschutz gerecht zu werden.
Conditional Forwarding am Pi-Hole konfigurieren

Am Raspi via SSH anmelden und die lokale DNS Konfigurationsdatei editieren
```
sudo nano /etc/dnsmasq.d/01-pihole.conf
```
Standardmäßig wird die Datei in etwa so aussehen…

Jetzt tragen wir in dieser Datei den lokalen Domainnamen des Hauptstandort (lab.net) und den zugehörigen DNS Server (10.1.110.1) ein. Meine vollständige Datei sieht dann so aus. Ich habe sie ein wenig kommentiert, um die Einträge besser zu verstehen. Wer alle Parameter wissen möchte, den verweise ich an die DNSMASQ Man Page…

# Please see LICENSE file for your rights under this license.

###############################################################################
#      FILE AUTOMATICALLY POPULATED BY PI-HOLE INSTALL/UPDATE PROCEDURE.      #
# ANY CHANGES MADE TO THIS FILE AFTER INSTALL WILL BE LOST ON THE NEXT UPDATE #
#                                                                             #
#        IF YOU WISH TO CHANGE THE UPSTREAM SERVERS, CHANGE THEM IN:          #
#                      /etc/pihole/setupVars.conf                             #
#                                                                             #
#        ANY OTHER CHANGES SHOULD BE MADE IN A SEPARATE CONFIG FILE           #
#                    WITHIN /etc/dnsmasq.d/yourname.conf                      #
###############################################################################

# Lokale Host Listen
addn-hosts=/etc/pihole/local.list
addn-hosts=/etc/pihole/custom.list

# beantworte DNS Anfragen, welche an die lokale IP Adresse gesendet werden
localise-queries

# verwende für Antworten nicht die Datei /etc/resolve.conf
no-resolv

# Größe des DNS Cache
cache-size=10000

# Logge alle Anfragen
log-queries

# Log datei
log-facility=/var/log/pihole.log

# Logge in eine Queue, wenn die Log Datei gerade blocked ist
log-async

# TTL für cached DNS Antworten in Sekunden
local-ttl=2

# DNS Forwarder für DNS Anfragen IPv4
server=1.1.1.1
server=1.0.0.1

# DNS Forwarder für DNS Anfragen IPv6
server=2606:4700:4700::1111
server=2606:4700:4700::1001

# Akzeptiere nur Anfragen aus dem lokalen Subnetz, zu welchem die lokale IP gehört. (verhindert DNS Amplifies)
local-service

# Server für Reverse Lookup (Server / Host für Reverse Lookup Anfragen, bspw. DHCP Server)
rev-server=192.168.100.0/24,192.168.100.1

# Conditional Forwarding
server=/lab.net/10.1.110.1
server=/fritz.box/192.168.100.1

# Canary Domain für DoH (DNS over HTTPS, nutzt bspw. Firefox)
server=/use-application-dns.net/

Datei mit STRG+O -> ENTER speichern und mit STRG+X verlassen.
Man kann jetzt mit

pihole-FTL dnsmasq-test

prüfen, ob man die Syntax der Datei eingehalten und sich nicht doch irgendwo ein Typo eingeschlichen hat… Wenn der Test mit

dnsmasq: syntax check OK.

beantwortet wird, sollte man jetzt den FQDN server1.lab.net pingen können.
Sollte es noch nicht funktionieren, kann man testweise den DNS Masq Service neu starten und dann erneut testen.

sudo pihole restartdns

Damit wäre der Zugriff auf den Applikationsserver am Hauptstandort, via FQDN realisiert.
Fileshares, Netzlaufwerke, Terminalserverfarmen, etc. können jetzt wie gewohnt via FQDN aufgerufen werden.
Bei Domain joined Clients, die den Suffix der Domain automatisch an Anfragen anhängen, würde sogar eine NETBIOS-Abfrage funktionieren. Ich rate davon ab, „client driven“ DNS Suffixe manuell hinzuzufügen. Mangels zentraler Steuerung, würde das bei Änderungen, aber auch bei Fehlern, einen mords Aufwand erzeugen.