Skip to content

Wireguard - Tunnel zur Fritz!Box 6591 Cable Part 3

Angeheftet Wireguard
  • Im dritten Teil beschäftigen wir uns mal mit dem Thema DNS-Leak. Im Wiki steht dazu folgendes.

    The vulnerability allows an ISP, as well as any on-path eavesdroppers, to see what websites a user may be visiting. This is possible because the browser's DNS requests are sent to the ISP DNS server directly, and not sent through the VPN.

    Ok, für meinen Wireguard-Server in der Hetzner Cloud habe ich dafür den Unbound DNS Dienst benutzt. Das ging dort relativ einfach aber jetzt hier im Heimnetz!? Da ich schon lange einen Proxmox 24/7 laufen habe, stand schnell der Plan das darauf laufen zu lassen. Vorher hatte ich das schnell mit einem ROCKPro64 probiert.

    Das schöne an Unbound ist, der ist relativ einfach zu konfigurieren.

    Installation

    apt install unbound
    

    Konfiguration

    Wir legen in cd /etc/unbound/unbound.conf.d/ die Datei user.conf an.

    server:
      interface: 0.0.0.0
      interface: ::0
      access-control: 127.0.0.0/8 allow
      access-control: 192.168.178.0/24 allow
      prefetch: yes
      hide-identity: yes
      hide-version: yes
      qname-minimisation: yes
    

    Das sollte relativ einfach zu verstehen sein. Wir lauschen auf allen Interfaces, der Zugriff ist nur loka (127.0.0.0) und 192.168.178.9/24 erlaubt. Das ist der Adressbereiche, den die Fritz!Box standardmäßig benutzt. Alle anderen Anfragen werden verworfen.

    Einmal neustarten und kurz testen...

    systemctl restart unbound
    

    Test

     frank@frank-MS-7C37:~$ dig @192.168.178.65 google.de
     
     ; <<>> DiG 9.16.1-Ubuntu <<>> @192.168.178.65 google.de
     ; (1 server found)
     ;; global options: +cmd
     ;; Got answer:
     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27957
     ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
     
     ;; OPT PSEUDOSECTION:
     ; EDNS: version: 0, flags:; udp: 1232
     ;; QUESTION SECTION:
     ;google.de.			IN	A
     
     ;; ANSWER SECTION:
     google.de.		300	IN	A	172.217.23.99
     
     ;; Query time: 404 msec
     ;; SERVER: 192.168.178.65#53(192.168.178.65)
     ;; WHEN: Sa Apr 02 17:48:09 CEST 2022
     ;; MSG SIZE  rcvd: 54
    

    Das hier zeigt uns, das wir die Antwort vom richtigen Server bekommen.

    SERVER: 192.168.178.65#53(192.168.178.65)
    

    Als Vergleich, ohne Angabe vom Server. Das würd den DNS benutzen, der auf meinem Haupt-PC konfiguriert ist.

    frank@frank-MS-7C37:~$ dig google.de
    
    ; <<>> DiG 9.16.1-Ubuntu <<>> google.de
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17733
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 65494
    ;; QUESTION SECTION:
    ;google.de.			IN	A
    
    ;; ANSWER SECTION:
    google.de.		112	IN	A	216.58.212.131
    
    ;; Query time: 28 msec
    ;; SERVER: 127.0.0.53#53(127.0.0.53)
    ;; WHEN: Sa Apr 02 17:49:11 CEST 2022
    ;; MSG SIZE  rcvd: 54
    

    Damit läuft nun der Unbound DNS, jetzt muss man nur noch in der Wireguard die IP-Adresse des DNS-Servers ändern und das Problem mit dem DNS Leak ist Geschichte.

    Vor dem Eintragen des Unbound DNS-Servers.

    Screenshot_20220328-200418_Firefox.jpg

    Danach

    Screenshot_20220330-180940_Firefox.jpg

    Es gibt da noch ein kleines Leak im IPv6 Bereich, wo ich mit meinem Systemadministrator in Hamburg nochmal drüber sprechen muss 🙂 Es ging ohne ihn 🙂

    Update: Wichtig!

    Man muss nicht nur die IPv4 Adresse des DNS-Servers in der App eintragen, sondern auch die IPv6 Adresse. Er würde sonst immer noch den DNS-Servers des ISP benutzen, weil ja mittlerweile viele Anwendungen IPv6 bevorzugen. Das könnt ihr auch gut mit dieser Seite testen.

    ipleak.net

    Part 1 -> https://linux-nerds.org/topic/1164/wireguard-tunnel-zur-fritz-box-6591-cable-part-1
    Part 2 -> https://linux-nerds.org/topic/1165/wireguard-tunnel-zur-fritz-box-6591-cable-part-2
    Part 4 -> https://linux-nerds.org/topic/1167/wireguard-tunnel-zur-fritz-box-6591-cable-part-4-adblocker

  • FrankMF FrankM hat dieses Thema am angepinnt
  • FrankMF FrankM hat am auf dieses Thema verwiesen
  • FrankMF FrankM hat am auf dieses Thema verwiesen
  • FrankMF FrankM hat am auf dieses Thema verwiesen

  • Wireguard - Tunnel zur Fritz!Box 6591 Cable Part 4 (Adblocker)

    Angeheftet Wireguard
    1
    0 Stimmen
    1 Beiträge
    325 Aufrufe
    Niemand hat geantwortet
  • Wireguard - Tunnel zur Fritz!Box 6591 Cable Part 2

    Angeheftet Wireguard
    1
    0 Stimmen
    1 Beiträge
    353 Aufrufe
    Niemand hat geantwortet
  • Redis Replication über Wireguard

    Redis
    5
    0 Stimmen
    5 Beiträge
    415 Aufrufe
    K

    👍
    spart bischen zeit

  • ROCKPro64 - Kernel 5.6 und Wireguard 1.0

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    305 Aufrufe
    Niemand hat geantwortet
  • Wireguard 1.0.0

    Wireguard
    1
    0 Stimmen
    1 Beiträge
    257 Aufrufe
    Niemand hat geantwortet
  • Wireguard - Traffic routen

    Wireguard
    2
    0 Stimmen
    2 Beiträge
    1k Aufrufe
    FrankMF

    Wie ich bei meinem Hamburger Systemadministrator gelernt habe, geht das auch wesentlich einfacher. Dafür hat Wireguard einen netten Befehl schon parat, nennt sich

    wg-quick up wg0-client

    Dazu muss auf dem Client natürlich vorher alles konfiguriert sein. Das Verzeichnis /etc/wireguard sieht dann so aus.

    root@thinkpad:/etc/wireguard# ls -lha /etc/wireguard/ insgesamt 32K drwx------ 2 root root 4,0K Aug 16 08:47 . drwxr-xr-x 141 root root 12K Aug 16 08:47 .. -rw-r--r-- 1 root root 45 Aug 9 16:48 private.key -rw-r--r-- 1 root root 45 Aug 9 16:48 psk.key -rw-r--r-- 1 root root 45 Aug 9 16:48 public.key -rw-r--r-- 1 root root 275 Aug 16 08:47 wg0-client.conf

    Die drei Schlüssel sind also vorhanden, der Server ist auch entsprechend vorbereitet. Dann brauchen wir auf dem Clienten noch die wg0-client.conf mit folgendem Inhalt.

    [Interface] Address = 10.10.0.4/32 PrivateKey = oM9jWxxxxxxxxxxxxxxxxxxxxxxxxxxxtS4vW8= ListenPort = 50xxx DNS = 10.10.0.2 [Peer] PublicKey = fGg7MxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxTPRqqzU= Endpoint = 136.xxx.xxx.xxx:60xxx AllowedIPs = 0.0.0.0/0 PersistentKeepalive = 21

    Im ersten Teil [Interface] wird die Schnittstelle auf dem Clienten konfiguriert.

    Die Adresse des Clienten Privatekey, findet man in /etc/wireguard/private.key Den Port für die Wireguard Kommunikation, frei wählbar. Der DNS-Server, ist hier mein Wireguard-Server, der einen DNS Dienst bereit hält.

    Im zweiten Teil [Peer] wird die Verbindung zum Server konfiguriert.

    PublicKey, der PublicKey des Servers. Endpoint, ist die IP-Adresse des Servers. AllowedIPs 0.0.0./0 wird den gesamten IPv4 Verkehr über den Tunnel routen. Dient dazu , die Verbindung aufrecht zu erhalten?

    Mit

    wg-quick up wg0-client

    baut er nun die Verbindung auf.

    root@thinkpad:/etc/wireguard# wg-quick up wg0-client [#] ip link add wg0-client type wireguard [#] wg setconf wg0-client /dev/fd/63 [#] ip -4 address add 10.10.0.4/32 dev wg0-client [#] ip link set mtu 1420 up dev wg0-client [#] resolvconf -a tun.wg0-client -m 0 -x [#] wg set wg0-client fwmark 51xxx [#] ip -4 route add 0.0.0.0/0 dev wg0-client table 51xxx [#] ip -4 rule add not fwmark 51xxx table 51xxx [#] ip -4 rule add table main suppress_prefixlength 0 root@thinkpad:/etc/wireguard#

    Damit steht der Tunnel

    9: wg0-client: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet 10.10.0.4/32 scope global wg0-client valid_lft forever preferred_lft forever

    Ausschalten

    root@thinkpad:/etc/wireguard# wg-quick down wg0-client [#] ip -4 rule delete table 51xxx [#] ip -4 rule delete table main suppress_prefixlength 0 [#] ip link delete dev wg0-client [#] resolvconf -d tun.wg0-client

    Auf meinem Debian 10 Buster ging das erst so nicht, weil ein Paket fehlt.

    root@thinkpad:/etc/wireguard# wg-quick up wg0-client [#] ip link add wg0-client type wireguard [#] wg setconf wg0-client /dev/fd/63 [#] ip -4 address add 10.10.0.4/32 dev wg0-client [#] ip link set mtu 1420 up dev wg0-client [#] resolvconf -a wg0-client -m 0 -x /usr/bin/wg-quick: line 31: resolvconf: command not found [#] ip link delete dev wg0-client

    Wireguard ist so nett und schreibt alles rein 😉 Eine Installation von resolcconf löst das Problem.

    root@thinkpad:/etc/wireguard# apt install resolvconf Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig Die folgenden NEUEN Pakete werden installiert: resolvconf 0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert. Es müssen 74,2 kB an Archiven heruntergeladen werden. Nach dieser Operation werden 196 kB Plattenplatz zusätzlich benutzt. [gekürzt]

    Nun kann man den Tunnel mit zwei einfachen Befehlen auf- und wieder abbauen. Als nächstes kommt dann noch die IPv6 Erweiterung, weil im Moment IPv6 Traffic am Tunnel vorbei fliessen würde, wenn man eine öffentliche IPv6 Adresse zugewiesen bekommen hätte. Aber, das muss ich mir noch ein wenig erklären lassen 🙂

  • Wireguard - VPN Server

    Wireguard
    2
    0 Stimmen
    2 Beiträge
    542 Aufrufe
    FrankMF

    Das DNS-Problem ist gelöst. Da die Erklärung was umfangreicher ist, wird das heute nichts mehr. Genug getippt für heute 😁

  • Wireguard - Failed to parse netdev kind, ignoring: wireguard

    Wireguard
    1
    0 Stimmen
    1 Beiträge
    367 Aufrufe
    Niemand hat geantwortet