Ja, ich kann bestätigen, es funktioniert und startet einwandfrei!
ROCKPro64 - Projekt Wireguard Server
-
Der Plan
Ich wollte über die Ostertage mal eben einen Wireguard Server hinter meiner Fritzbox aufsetzen um zu schauen, ob der Kernel 5.6 ordentlich funktioniert. Ok, das Ganze sollte etwas ausarten, viel Zeit fressen, viel Frust erzeugen und mir mal wieder vor Augen führen, das ich von IPv6 keine Ahnung habe.
Hintergrund
Technischer Hintergrund, man hat am Kabelanschluss einen DS-Lite-Tunnel. Man hat also keine richtige IPv4 Adresse, die man von extern erreichen könnte. Man hat aber eine vollwertige IPv6 Adrese, womit man die Fritzbox von außen erreichen kann. Dazu später mehr.
Um einen Wireguard Server permanent erreichen zu können, könnte man ja in der Fritzbox einen DynDNS Service benutzen, der dafür sorgt das man immer unter einem Domainnamen erreichbar ist. Da die meisten Geld kosten, habe ich davon Abstand genommen. Mein Gedanke war, warum hat man denn IPv6, das muss auch damit gehen.
Ich weiß jetzt, das das was ich einen Satz vorher geschrieben habe, nicht richtig ist. Weil auch diese Adresse kann sich ändern, aber ich habe einen Workaround womit ich persönlich leben kann. Auch dazu, später mehr.
Fritzbox
Ich nutze eine Fritzbox 6591C am Anschluss von Vodafone NRW. Diese Fritzbox ist dank des netten Beitrages vom Nico auf der FrOSCon 2019 voll IPv6 fähig.
Hinter dieser Fritzbox befindet sich eine pfSense die mein Netzwerk vom Rest abschirmt. Die pfSense ist auch voll IPv6 fähig.
Für einen ersten Test sollte der Wireguard Server hinter die Fritzbox kommen. Damit wir diesen auch aus dem Internet erreichen können, müssen wir unter Internet/Freigaben folgendes einstellen.
Danach ist der ROCKPro64 aus dem Internet erreichbar.
Hardware
- ROCKPro64v2.1 2GB RAM
- PCIe NVMe SSD Samsung 970 EVO 500GB (system)
- u-boot im SPI
Software
- Kamil's Release 0.10.10
Kernel
root@rockpro64:~# uname -a Linux rockpro64 5.6.0-1134-ayufan-g652fb97d87eb #ayufan SMP Thu Apr 9 22:26:01 UTC 2020 aarch64 GNU/LinuxInstallation Wireguard
Users with Debian releases older than Bullseye should enable backports.
Wir öffnen /etc/apt/sources.list
nano /etc/apt/sources.listAns Ende fügen wir folgende Zeile ein
deb http://deb.debian.org/debian buster-backports mainDas dann bitte speichern. Danach
apt updateUnd jetzt installieren wir
apt install wireguardTest
root@rockpro64:~# wg version wireguard-tools v1.0.20200319 - https://git.zx2c4.com/wireguard-tools/Konfiguration Wireguard
Keys erzeugen
private.key erzeugen
root@rp64_nextcloud:/etc/wireguard# wg genkey > private.key Warning: writing to world accessible file. Consider setting the umask to 077 and trying again.public.key erzeugen
root@rp64_nextcloud:/etc/wireguard# wg pubkey > public.key < private.keypsk.key erzeugen
root@rp64_nextcloud:/etc/wireguard# wg genpsk > psk.keyBitte die Warnung beachten!
Warning: writing to world accessible file. Consider setting the umask to 077 and trying again.Inhalt des Ordners /etc/wireguard
root@rockpro64:/etc/wireguard# ls -lha total 36K drwx------ 2 root root 4.0K Apr 13 07:11 . drwxr-xr-x 87 root root 4.0K Apr 11 19:06 .. -rwxr-xr-x 1 root root 1012 Apr 12 13:12 firewall.sh -rw-r--r-- 1 root root 45 Apr 10 16:44 private.key -rw-r--r-- 1 root root 46 Apr 10 16:46 psk.key -rw-r--r-- 1 root root 45 Apr 10 16:44 public.key -rw-r--r-- 1 root root 843 Apr 12 12:55 wg0.confDamit wären wir mit den Grundlagen durch. Es gibt nun zwei(?) Möglichkeiten die Wireguard Schnittstelle zu konfigurieren. Einmal könnte man das Interface beim Start direkt erzeugen lassen, einmal macht man das mittels wg-quick. Hier bei der Testerei hat sich schnell raus gestellt, das wg-quick zum Testen ideal ist. Man kann die Schnittstelle schnell starten und stoppen. Ich zeige trotzdem hier beide Wege.
Dateien, die benötigt werden für beide Fälle.
wg0.conf
[Interface] Address = 10.10.1.1/24, fddb:76e8:5e07:0100::1/64 PrivateKey = IJHK9lAjxlKxxxxxxxxxxxxxxx5NQ/zJfLicD7Vs= ListenPort = 51820 PostUp = /etc/wireguard/firewall.sh DNS = 10.10.1.1 # ThinkPad [Peer] PublicKey = qomJliKdaxxxxxxxxxxxxxxxxxxxxxxxqE5heItyHna2Q= PresharedKey = 5/kEBxxxxxxxxxxxxxxxxxxxxxxxxxxbSarEcqt4= AllowedIPs = 10.10.1.3, fddb:76e8:5e07:0100::3Ok, die erste Frage die jetzt viele haben werden ist folgende Woher kommen die IP-Adressen?
Ich habe da nur einen privaten Adressbereich für IPv4 und einen privaten IPv6 Adressbereich festgelegt.Auf die IPv4 Adresse gehe ich hier nicht näher ein, das setze ich mal als allgemein bekannt voraus.
Die IPv6 Adresse ist da um einiges interessanter. Ich habe lange rumgedocktert mit öffentlichen IPv6 Adressen, aber nichts funktionierte. Nach einem kurzen Hilferuf nach Hamburg brachte mich dann der Nico auf den rechten Weg
Man bräuchte dazu Unique Local Address Danach hatte ich mich auf die Suche im Netz gemacht und bin über folgende Anleitung gestolpert. Danach war mir einiges klarer.Nico hatte mir auch einen Link zur Verfügung gestellt, womit man den Adressbereich ermitteln kann. Dazu gibt man die MAC Adresse der Netzwerkkarte dort ein und erhält dann den Adressbereich angezeigt. Diese Adressen werden zufällig erzeugt, hier mal ein Beispiel.
Your Private IPv6 network is: fd65:9491:8310::/48 giving you access to the to the following /64s: fd65:9491:8310:0::/64 through fd65:9491:8310:ffff::/64Die Schnittstelle würde als nach dem Beispiel folgende IPv6 bekommen
fd65:9491:8310:0100::1- fd ist der Prefix
- 65:9491:8310 ist die Global ID (random)
- 0100 Subnet ID (hier frei gewählt)
- 0000:0000:0000:0001 Interface ID, die man ja verkürzen kann auf ::1
Das sollte es soweit für Euch verständlich machen. Mich hat das Ausprobieren nur ein paar Stunden gekostet
/etc/wireguard/firewall.sh
Die Firewall hier ist nicht optimiert und enthält auch vermutlich Fehler. Fpr einen Einsatz im internet nicht zu gebrauchen!!
#!/bin/bash ### BEGIN INIT INFO # Provides: firewall # Required-Start: # Required-Stop: # Should-Start: # Default-Start: # Default-Stop: # Short-Description: firewall # Description: firewall ### END INIT INFO IP4TABLES=/sbin/iptables IP6TABLES=/sbin/ip6tables SERVERNETIPV4="192.168.178.29/32" SERVERNETNAT_IPV4="10.10.1.0/24" SERVERNETIPV6="2a02:908:1200:fbe0::/64" IPV6SUBNET="2a02:908:1265:fbe0:0100::" IPV6SUBNETMASK="/72" WGIF="wg0" OUTIF="eth0" # Enable forwarding sysctl -q -w net.ipv4.ip_forward=1 sysctl -q -w net.ipv6.conf.all.forwarding=1 sysctl -q -w net.ipv6.conf.all.proxy_ndp=1 # Add Proxy NDP entries for i in {1..1000} do ip neigh add proxy ${IPV6SUBNET}${i} dev $OUTIF done # NAT for IPv4 connections iptables -t nat -A POSTROUTING -o $OUTIF -j MASQUERADE # NAT for IPv6 connections added by FM ;) ip6tables -t nat -A POSTROUTING -o $OUTIF -j MASQUERADE # Filter all packets that have RH0 headers ip6tables -A FORWARD -o $WGIF -m rt --rt-type 0 -j DROP # Allow ICMPv6 ip6tables -A FORWARD -o $WGIF -p ipv6-icmp -j ACCEPT # Allow established connections ip6tables -A FORWARD -o $WGIF -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT # Allow new connections from VPN-Clients ip6tables -A FORWARD -o $WGIF -s ${IPV6SUBNET}${IPV6SUBNETMASK} -m conntrack --ctstate NEW -j ACCEPT # Reject all other forwarding ip6tables -A FORWARD -o $WGIF -j REJECT #========================= # SSH zur Firewall erlauben (IN) #========================= $IP4TABLES -A INPUT -p tcp --dport 22 -j ACCEPT $IP6TABLES -A INPUT -p tcp --dport 22 -j ACCEPTWird bei Gelegenheit optimiert!
Schnittstelle wg0
In /etc/network/interfaces.d erstellen wir die Datei wg0
# Wireguard auto wg0 iface wg0 inet static address 10.10.1.1 netmask 255.255.255.0 pre-up ip link add $IFACE type wireguard pre-up wg setconf $IFACE /etc/wireguard/$IFACE.conf post-up /etc/wireguard/firewall.sh post-down ip link del $IFACE iface wg0 inet6 static address fddb:76e8:5e07:0100::1 netmask 64Nun würden beim Neustarten das Interface wg0 erstellt.
wg-quick
Das Ganze mit wg-quick. Um diese Schnittstelle temporär zu erzeugen benutzt man den Befehl
wg-quick up wg0und
wg-quick down wg0Erste Tests brachten mich an den Rande des Wahnsinns. Einen Handshake bekam ich gut hin, Gegenseite konnte ich auch pingen. Aber alles andere ging so ziemlich gar nicht. Kein DNS, kein ping www.google.de usw. Das war bevor ich das mit den ULA Adressen wusste, danach war es einfacher
Client
Als Client benutze ich meinen Thinkpad. Dort läuft natürlich auch ein Linux
Debian Buster 10.3 mit Cinnamon Desktop
Installation
Die Installation erfolgt ebenfalls aus den Backports, wie oben schon beschrieben.
wireguard-tools v1.0.20200319 - https://git.zx2c4.com/wireguard-tools/Konfiguration
Keys
Genau wie oben beschrieben.
wg0.conf
[Interface] Address = 10.10.1.3, fddb:76e8:5e07:0100::3: /64 PrivateKey = oM9jWxxxxxxxxxxxxxxxxxxxVw+3+j0tS4vW8= ListenPort = 51820 DNS = 10.10.1.1 [Peer] Endpoint = 2a02:xxx:xxxx:xxxx:xxxx:xxxx:xxxx:dcb3:51820 PublicKey = dCK5wSl3xxxxxxxxxxxxxxxxh+jhWF1O4cx0= PresharedKey = 5/kEB4FxxxxxxxxxxxxxxxxxxxiMPbSarEcqt4= AllowedIPs = 0.0.0.0/0, ::/0Auch hier wieder ein paar kurze Erklärungen zu den IP-Adressen. Die Interface Adressen sollten Euch jetzt klar sein. Wenn nicht, bitte oben noch mal nachlesen. Jetzt zum Endpoint. Das ist IP-Adresse die Euch die Fritzbox unter der Freigabe anzeigt. Hier noch mal als Bild.
Noch wichtig ist DNS = 10.10.1.1, das erkläre ich später.
Gestartet wird der Wireguard Tunnel dann wieder ganz bequem per
wg-quick up wg0Danach sollte die Verbindung stehen.
Kontrolle der Verbindung
Server
root@rockpro64:/etc/wireguard# wg interface: wg0 public key: dCK5wxxxxxxxxxxxxxxxxxxxxxxWF1O4cx0= private key: (hidden) listening port: 51820 peer: qomJliKxxxxxxxxxxxxxxxxxxxxxxtyHna2Q= preshared key: (hidden) endpoint: [2a01:xxxxxxxxxxxxxxxxxxxxxxxx]:51820 allowed ips: 10.10.1.3/32, fddb:76e8:5e07:100::3/128 latest handshake: 15 seconds ago transfer: 41.87 KiB received, 22.52 KiB sentHier ist ganz wichtig, der latest handshake! So lange der nicht auftaucht, stimmt irgendwas nicht an der Verbindung!
Auf dem Client kann man sich das genauso anzeigen lassen. Dann kurzer Test auf dem Client.ping 10.10.1.1 ping 8.8.8.8 ping fddb:76e8:5e07:100::1 ping www.google.de ping 2001:4860:4860::8888- 10.10.1.1 private IPv4 der Wireguard Schnittstelle des Servers
- 8.8.8.8 IPv4 Adresse von google
- fddb:76e8:5e07
:1 private IPv6 der Wireguard Schnittstelle des Servers - www.google.de Geht der DNS im IPv4
- 2001:4860:4860::8888 IPv6 Adresse von google
Wenn alle diese Pings einwandfrei funktionieren, dann steht die Wireguard Verbindung und funktioniert!!
Ok, bei Euch fehlt noch der DNS, das machen wir jetzt.
DNS
Bei einer VPN Verbindung besteht immer das Problem, das man mittels der DNS Abfragen seine wahre Identität entschleiert. Nennt sich auch DNS-Leak. Es gibt auch Seiten um das zu testen.
Wir müssen beim Aufbau der Wireguard Verbindung alle DNS-Abfragen umlenken. Diese Abfragen müssen durch den Tunnel! Dazu gibt es den Eintrag
DNS = 10.10.1.1Das heisst nun, auf dem Wireguard Server muss ein DNS Dienst laufen. Dazu nutzen wir unbound.
Installation
apt install unboundKonfiguration
Unter /etc/unbound/unbound.conf.d/ erstellen wir die Datei user.conf
Inhalt
server: interface: 10.10.1.1 # interface: ::0 access-control: 10.0.0.0/8 allow access-control: 127.0.0.0/8 allow access-control: 192.168.0.0/16 allow access-control: fddb:76e8:5e07:100::/72 allow prefetch: yes hide-identity: yes hide-version: yes qname-minimisation: yesIch bin nicht der unbound Experte, aber das was ich vom Nico gelernt habe, lauscht der jetzt auf der privaten IP 10.10.1.1 und beantwortet Anfragen. Darunter noch was Zugriffskontrolle. Danach den Dienst neustarten.
service unbound restartEin ganz wichtiger Test kommt jetzt! Wir testen ob der DNS von außen erreichbar ist. Stichwort DNS Resolver! Dazu nutze ich einen der vorhanden Server im Internet und setze folgenden Befehl ab.
nmap -6 xxxxxxxxxxxxxxxxxx:8e40 Starting Nmap 7.70 ( https://nmap.org ) at 2020-04-19 14:45 CEST Nmap scan report for xxxxxxxxxxxxxxxxx:8e40 Host is up (0.031s latency). Not shown: 997 closed ports PORT STATE SERVICE 9/tcp filtered discard 22/tcp open ssh 179/tcp filtered bgp Nmap done: 1 IP address (1 host up) scanned in 5.33 secondsAls IP-Adresse wird die genommen, die die Fritzbox anzeigt. Sieh Bild oben! Dort darf nicht folgendes auftauchen!!
53/tcp open domainSomit sollte der Dienst unbound ausreichend sicher konfiguriert sein.
Wenn man mal testen möchte, von wo die DNS-Anfrage beantwortet wird, kann man das hiermit machen.
root@rockpro64:/etc/wireguard# dig www.google.de ; <<>> DiG 9.11.5-P4-5.1-Debian <<>> www.google.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27807 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.google.de. IN A ;; ANSWER SECTION: www.google.de. 300 IN A 172.217.21.195 ;; Query time: 50 msec ;; SERVER: 10.10.1.1#53(10.10.1.1) ;; WHEN: Sun Apr 19 13:03:43 UTC 2020 ;; MSG SIZE rcvd: 58IP ändert sich
Die IP-Adresse Eurer Fritzbox ist ja nicht statisch, so das sich diese ab und zu mal ändern kann. Passiert nicht mehr so oft, kann aber vorkommen. Dann würde man den Wireguard Server nicht mehr erreichen, weil die IP-Adresse ja nicht mehr stimmt. Es gibt da eine Möglichkeit, man kann die Fritzbox auch von extern erreichen. Stichwort: MyFRITZ!-Konto
Aber, das Thema muss ich mir noch mal was durch den Kopf gehen lassen
Schlusswort
Ja, das war wieder eine Lernphase. Aber das ist auch genau der Grund warum ich das mache. Man muss ja im Alter die Birne am Laufen halten
So ein Wiregaurd Server ist was extrem praktisches. Da kann man so viele Sachen mit machen. Aus dem Hotel das WLan sicher nutzen, den Anbieter seines Vertrauens nicht mitlesen lassen usw.
Viel Spaß damit und denkt dran, hier sind nicht alle Aspekte der Sicherheit im Internet angesprochen worden. So sollte man den Server nicht ins Internet stellen! Und Danke an Nico!!
-
-
NanoPi R4S - OpenWrt kompilieren
Angeheftet NanoPi R4S -
NVMe - Booten jetzt möglich
Angeheftet ROCKPro64 -
-
-
-
-
Mainline Kernel 4.17-rc7
Verschoben Archiv