Wireguard - DNS für VPN-Server



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



  • 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

Log in to reply
 

Diese Artikel könnten Dich auch interessieren.

  • 1
  • 4
  • 2
  • 2
  • 1
  • 2
  • 1