Skip to content

Wireguard - DNS für VPN-Server

Wireguard
  • In meinem Beitrag zum VPN-Server hatte ich ja als DNS-Server testweise mal 8.8.8.8 eingetragen. Wenn man seine echte IP-Adresse verschleiern will, ist das keine so gute Idee. Da ich den VPN-Server hier auf meinem eigenen Root laufen habe, wäre es auch egal gewesen es so zu belassen. Der gehört ja schließlich mir und deswegen ist es auch nachvollziehbar, das das gesendete Paket von mir stammt.

    Da ich aber was lernen möchte, muss das halt auch ordentlich sein 🙂

    Nun war in der Anleitung ein Beispiel den DNS-Server mit unbound aufzubauen. Das Beispiel hat aber bei mir überhaupt nicht funktioniert. Ok, von vorne....

    Was ist unbound?

    Unbound is a validating, recursive, caching DNS resolver. It is designed to be fast and lean and incorporates modern features based on open standards.

    Installation

    Aus dem Beispiel

    apt-get install unbound unbound-host
    

    Liste der Root DNS Server herunterladen

    curl -o /var/lib/unbound/root.hints https://www.internic.net/domain/named.cache
    

    Benutzerrechte anpassen

    chown -R unbound:unbound /var/lib/unbound
    

    So weit war das alles kein Problem. Was sehr schnell Probleme bereitete war der eingerichtete systemd.

     service unbound status
     ● unbound.service - Unbound DNS server
        Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
        Active: failed (Result: exit-code) since Sat 2019-07-27 18:13:55 CEST; 15h ago
          Docs: man:unbound(8)
       Process: 21945 ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS (code=exited, status=1/FAILURE)
       Process: 21940 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
       Process: 21935 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
      Main PID: 21945 (code=exited, status=1/FAILURE)
     
     Jul 27 18:13:55 amadeus systemd[1]: unbound.service: Unit entered failed state.
     Jul 27 18:13:55 amadeus systemd[1]: unbound.service: Failed with result 'exit-code'.
     Jul 27 18:13:55 amadeus systemd[1]: unbound.service: Service hold-off time over, scheduling restart.
     Jul 27 18:13:55 amadeus systemd[1]: Stopped Unbound DNS server.
     Jul 27 18:13:55 amadeus systemd[1]: unbound.service: Start request repeated too quickly.
     Jul 27 18:13:55 amadeus systemd[1]: Failed to start Unbound DNS server.
     Jul 27 18:13:55 amadeus systemd[1]: unbound.service: Unit entered failed state.
     Jul 27 18:13:55 amadeus systemd[1]: unbound.service: Failed with result 'exit-code'.
    

    Und die Config klappte auch irgendwie gar nicht. Aber, niemals aufgeben. Ich schaute mir mal in Ruhe die Anleitung von unbound an. Und die Dokumentation zur Config.

    Vergessen wir mal den systemd.

    Starten von unbound

    unbound -c /etc/unbound/unbound.conf
    

    Stoppen von unbound

    kill `cat /etc/unbound/unbound.pid`
    

    Config /etc/unbound/unbound.conf

    # Unbound configuration file for Debian.
    #
    # See the unbound.conf(5) man page.
    #
    # See /usr/share/doc/unbound/examples/unbound.conf for a commented
    # reference config file.
    #
    # The following line includes additional configuration files from the
    # /etc/unbound/unbound.conf.d directory.
    #include: "/etc/unbound/unbound.conf.d/*.conf"
    
    server:
                directory: "/etc/unbound"
                username: unbound
                # make sure unbound can access entropy from inside the chroot.
                # e.g. on linux the use these commands (on BSD, devfs(8) is used):
                #      mount --bind -n /dev/random /etc/unbound/dev/random
                # and  mount --bind -n /dev/log /etc/unbound/dev/log
                chroot: "/etc/unbound"
                # logfile: "/etc/unbound/unbound.log"  #uncomment to use logfile.
                pidfile: "/etc/unbound/unbound.pid"
                # verbosity: 1      # uncomment and increase to get more logging.
                # listen on all interfaces, answer queries from the local subnet.
                interface: 0.0.0.0
                #interface: ::0
                access-control: 10.10.0.0/8 allow
                #access-control: 2001:DB8::/64 allow
                private-address: 10.10.0.3/8
                hide-identity: yes
                hide-version: yes
                unwanted-reply-threshold: 10000000
                #Minimum lifetime of cache entries in seconds
                cache-min-ttl: 1800
                #Maximum lifetime of cached entries
                cache-max-ttl: 14400
                prefetch: yes
                prefetch-key: yes
    

    Client Config

    Screenshot_20190728-094438.png

    Als DNS Adresse wird jetzt der Server eingetragen. Danach funktionierte der VPN-Tunnel incl. DNS einwandfrei.

    Testmöglichkeiten

    Mit https://wieistmeineip.de checken wir die IP-Adresse die wir nutzen. Da sollte dann die IP-Adresse des Servers angezeigt werden.

    Um den DNS zu checken nutzen wir http://dnsleak.com

    dnsleak.png

    Das sieht gut aus. Dann hatte ich vor Jahren mal böse Post von einem Internet Provider bzgl. DNS-Resolver.

    Was ist ein offener DNS-Resolver?

    Offene DNS-Resolver

    Als offene DNS-Resolver werden DNS-Server bezeichnet, welche rekursive Anfragen für beliebige Domainnamen aus dem Internet zulassen und beantworten.

    Problem

    Offene DNS-Resolver können für DDoS-Reflection-Angriffe gegen IT-Systeme Dritter missbraucht werden.

    Die beiden oberen Antworten stammen vom Bundesamt für Sicherheit in der Informationstechnik.
    Quelle: https://www.bsi.bund.de/DE/Themen/Cyber-Sicherheit/Aktivitaeten/CERT-Bund/CERT-Reports/HOWTOs/Offene-DNS-Resolver/Offene-DNS-Resolver_node.html

    Da wir diesen Dienst ja nur für uns benutzen wollen, muss also verhindert werden das er öffentlich zur Verfügung steht. Das erreichen wir in der Config von unbound mit der Zeile

    access-control: 10.10.0.0/8 allow
    

    Um das zu überprüfen schicken wir mal eine DNS-Anfrage an den Server.

    frank@debian:~$ dig www.google.com @<IP vom Server>
    
    ; <<>> DiG 9.11.5-P4-5.1-Debian <<>> www.google.com @<IP vom Server>
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 1050
    ;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
    ;; WARNING: recursion requested but not available
    
    ;; Query time: 23 msec
    ;; SERVER: <IP vom Server>#53(<IP vom Server>)
    ;; WHEN: So Jul 28 10:13:59 CEST 2019
    ;; MSG SIZE  rcvd: 12
    

    Die Zeile hier

    status: REFUSED
    

    zeigt uns an, das die Anfrage nicht zugelassen wurde. Laut BSI sollten wir damit auf der sicheren Seite sein.

    Sollte der Befehl dig nicht funktionieren, so muss man da noch was installieren.

    apt install dnsutils
    

    Danach geht es.

  • Und mit wg auf dem Server kann man schön nachsehen, wie viel Daten da so durchlaufen.

    root@amadeus ~ # wg
    interface: wg0
      public key: fGg7MkjzD6fVqxxxxxxxxxxxxxxxxxGa0NIBaTPRqqzU=
      private key: (hidden)
      listening port: 60563
    
    peer: bDTE7Kr7Uw/Xxxxxxxxxxxxxxxxxxxxx46uHFZErWz8SGgI=
      endpoint: xx.xxx.194.117:58702
      allowed ips: 10.10.0.3/32
      latest handshake: 14 seconds ago
      transfer: 56.55 MiB received, 287.67 MiB sent
    

  • 0 Stimmen
    1 Beiträge
    304 Aufrufe
    Niemand hat geantwortet
  • 0 Stimmen
    3 Beiträge
    2k Aufrufe
    FrankMF

    Es gab wieder ein neues Update!

    Bildschirmfoto vom 2022-05-10 20-36-50.png

    Wollen wir mal sehen, ob sich im Wireguard Bereich etwas getan hat.

    Es gibt jetzt einen eigenen Reiter, wenn ich mich korrekt erinnere.

    Bildschirmfoto vom 2022-05-10 20-35-04.png

    Hier kann man jetzt die Wireguard Einstellungen sich anzeigen lassen, ein Feature was ich mir in der Feedback EMail gewünscht hatte.
    Bildschirmfoto vom 2022-05-10 20-35-47.png

    Das sieht dann so aus.
    Bildschirmfoto vom 2022-05-10 20-36-06.png

    Bildschirmfoto vom 2022-05-10 20-36-28.png

    Ich denke, jetzt hat man ausreichend Informationen, um bei Problemfällen sich mit den Einstellungen zu beschäftigen. Danke AVM, das ihr so auf das Feedback der Kunden reagiert. 👏

  • Wireguard auf dem Smartphone

    Wireguard
    1
    0 Stimmen
    1 Beiträge
    194 Aufrufe
    Niemand hat geantwortet
  • 0 Stimmen
    2 Beiträge
    445 Aufrufe
    FrankMF

    Hat ein wenig Nerven gekostet und der Artikel ist auch was länger geworden 🙂 Viel Spaß beim Lesen und testen!

  • Wireguard - Client installieren

    Wireguard
    3
    0 Stimmen
    3 Beiträge
    478 Aufrufe
    FrankMF

    Ich kann dir nicht ganz folgen. Mein Wireguard Server ist eine VM im Netz. Mein Smartphone baut zu diesem eine Verbindung auf und ich habe mal eben nachgeschaut, was da so geht. Mein Smartphone ist aktuell im meinem WLan angemeldet.

    6e0016dc-7e11-41e1-bba2-e52a3f1348df-image.png

    iperf3 -s -B 10.10.1.1 ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 10.10.1.10, port 44246 [ 5] local 10.10.1.1 port 5201 connected to 10.10.1.10 port 44248 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 4.98 MBytes 41.7 Mbits/sec [ 5] 1.00-2.00 sec 5.52 MBytes 46.3 Mbits/sec [ 5] 2.00-3.00 sec 4.80 MBytes 40.3 Mbits/sec [ 5] 3.00-4.00 sec 4.17 MBytes 35.0 Mbits/sec [ 5] 4.00-5.00 sec 5.04 MBytes 42.3 Mbits/sec [ 5] 5.00-6.00 sec 5.43 MBytes 45.6 Mbits/sec [ 5] 6.00-7.00 sec 5.75 MBytes 48.3 Mbits/sec [ 5] 7.00-8.00 sec 5.70 MBytes 47.8 Mbits/sec [ 5] 8.00-9.00 sec 5.73 MBytes 48.1 Mbits/sec [ 5] 9.00-10.00 sec 5.65 MBytes 47.4 Mbits/sec [ 5] 10.00-10.04 sec 206 KBytes 46.5 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.04 sec 53.0 MBytes 44.3 Mbits/sec receiver ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 10.10.1.10, port 44250 [ 5] local 10.10.1.1 port 5201 connected to 10.10.1.10 port 44252 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 4.80 MBytes 40.2 Mbits/sec 0 253 KBytes [ 5] 1.00-2.00 sec 14.7 MBytes 123 Mbits/sec 181 379 KBytes [ 5] 2.00-3.00 sec 9.68 MBytes 81.2 Mbits/sec 58 294 KBytes [ 5] 3.00-4.00 sec 8.88 MBytes 74.5 Mbits/sec 1 227 KBytes [ 5] 4.00-5.00 sec 7.76 MBytes 65.1 Mbits/sec 0 245 KBytes [ 5] 5.00-6.00 sec 8.88 MBytes 74.5 Mbits/sec 0 266 KBytes [ 5] 6.00-7.00 sec 9.81 MBytes 82.3 Mbits/sec 0 289 KBytes [ 5] 7.00-8.00 sec 7.82 MBytes 65.6 Mbits/sec 35 235 KBytes [ 5] 8.00-9.00 sec 5.59 MBytes 46.9 Mbits/sec 4 186 KBytes [ 5] 9.00-10.00 sec 6.64 MBytes 55.7 Mbits/sec 0 207 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.04 sec 84.6 MBytes 70.6 Mbits/sec 279 sender ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- ^Ciperf3: interrupt - the server has terminated

    Im zweiten Teil ist der Wireguard Server der Sender.

    Bis jetzt hatte ich eigentlich nie Probleme, auch nicht unterwegs. Aber, ich gehe davon aus, das ich dich nicht 100% verstanden habe 😉

  • 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 🙂

  • Unbound - Werbeblocker

    Linux
    2
    0 Stimmen
    2 Beiträge
    311 Aufrufe
    FrankMF

    Als Script

    #!/bin/bash ###############################################################################$ # ###############################################################################$ cd /Verzeichnis /usr/bin/wget -N https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts /usr/bin/wget -N https://download.dnscrypt.info/blacklists/domains/mybase.txt /usr/bin/wget -N https://raw.githubusercontent.com/anudeepND/whitelist/master/domains/whitelist.txt cat hosts | grep '^0\.0\.0\.0' | awk '{print $2}' > block sed '/#/d; /*/d; /^$/d; /^\./d' mybase.txt > mybase cat block mybase | sort -u > merged touch /root/blocklist/mywhitelist cat whitelist.txt /root/blocklist/mywhitelist | sort -u > whitelist comm -23 merged whitelist > merged_corr awk '{print "local-zone: \""$1"\" refuse"}' merged_corr > /etc/unbound/unbound.conf.d/blocklist.conf sed -i '1s/.*$/server:\n&/g' /etc/unbound/unbound.conf.d/blocklist.conf service unbound restart
  • Wireguard - VPN Server

    Wireguard
    2
    0 Stimmen
    2 Beiträge
    479 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 😁