Privacy Handbuch

Einleitung…
Surfen… E-Mail (allgm) E-Mail (crypt) Chatten…
Tor… VPNs… DNS…
Daten schützen PC/Laptop OS Smartphones
Kontakt Druckversion

Linuxer können die Apps der VPN-Provider nutzen, wenn sie den gesamten Daten­verkehr über einen VPN-Server leiten wollen. Das ist die einfachste Variante, bei der man Konfigurations­fehler vermeidet. Außerdem hat man in dem GUI einfachen Zugriff auf alle Server des Providers und kann mit einem Klick wechseln, um ein Land als Exit zu wählen und Geo-IP Sperren zu umgehen.

Die VPN Apps der VPN-Provider leiten rigoros den gesamten Traffic durch das VPN – PUNKT.

VPN selbst gebastelt

Linux bietet für Interessierte auch die Möglichkeit, mit Boardmitteln ein VPN oder mehrere VPNS zu konfigurieren (IPsec/IKEv2, Wireguard, OpenVPN). Damit ist man flexibler und kann sich viele interessante Konfigurationen bauen. Ein paar Beispielanwendungen:

  1. Man könnte unterwegs normal surfen und gleichzeitig Zugriff auf das interne Netz der Firma oder auf seine eigenen Ressourcen im privaten Heimnetz haben (Road Warrior).
  2. Man könnte zuhause den Internet Datenverkehr über einen VPN-Server leiten, um Zensur oder Geo-IP Sperren zu umgehen, und gleichzeitig die Ressourcen im eigenen Heimnetz nutzen.
  3. Man könnte beides kombinieren und als Road Warrior den normalen Internet Traffic über einen VPN-Provider schicken und gleichzeitig ein zweites VPN für den Zugriff auf die heimischen Ressourcen oder Server der Firma verwenden – möglich aber ein bisschen komplizierter.

Wenn der gesamte Datenverkehr zu einem VPN-Provider gehen soll, muss man sich auch um DNS- oder IPv6-Leaks kümmern. Dabei handelt es sich nicht um Bugs (im Sinne einer Fehlfunktion des VPN) sondern um Features im Routing, die man durch geeigente Konfiguration vermeiden kann.

Um das Problem zu verstehen, wird das Routing im Innern des PC bei aktiviertem VPN an einem Beispiel erläutert. Ein PC oder Laptop wird zuhause (oder im Hotel) mit dem WLAN verbunden. Der Router sei eine Fritz!Box (andere Router funktionieren ähnlich) und ein OpenVPN wird aktiviert.

  1. Beim Herstellen der WLAN-Verbindung wird das Netzwerkinterface "wlan0" konfiguriert.

    • Via DHCP wird dem Interface "wlan0" eine IPv4 Adresse 192.168.178.x/24 zugewiesen.

      Der Netzbereich /24 hinter der IP-Adresse besagt, dass die Adressen 192.168.178.1…255 (Drucker oder Server im LAN) direkt von dieser Schnittstelle erreichbar sind ohne Routing.

    • Außerdem wird dem WLAN Interface eine IPv6 Adresse via DHCP zugewiesen.
    • Als Gateway ins Internet wird die Fritz!Box mit der Adresse 192.168.0.1 definiert. Alle IP-Adressen außerhalb von 192.168.178.0/24 sind erstmal über dieses Gateway erreichbar.
    • Als DNS-Server ist 192.168.178.1 zu verwenden (sagt die Fritz!Box via DHCP). Die Fritz!Box leitet die DNS Anfragen dann zu einem Upstream DNS-Server weiter.
  2. Beim Aktivieren von OpenVPN wird das virtuelle Netzwerkinterface "tun0" konfiguriert.
    • Dem Interface "tun0" wird in der Regel eine IPv4 Addresse vom VPN-Server zugewiesen. Alternativ könnte die IP-Adresse auch in der OpenVPN Konfiguration festgelegt werden.
    • Die IP-Adresse des VPN-Servers wird als Gateway für einen IPv4(!) Adressbereich gesetzt.
      1. VPN-Provider definieren 0.0.0.0/0 (alle IPv4 Adressen) als Adressbereich, für den der VPN-Server zuständig ist, um den gesamten IPv4 Traffic durch das VPN zu leiten.

      2. Es kann sich auch um die Adressen in einem Firmennetz handeln (z.B. 10.10.0.0/16) oder das eigene Heimnetz zuhause (z.B. 172.22.22.0/24). Als Road Warrior oder im Homeoffice könnte man so einerseits via VPN mit den Servern arbeiten, die in der Firma bzw. zuhause stehen, und gleichzeitig ganz normal ohne VPN im Internet surfen.

    • In der OpenVPN Config wird ein weiterer DNS-Server definiert, der via VPN erreichbar ist.

  3. Außerdem könnte man noch ein zweites VPN starten, wenn man beispielsweise als Road Warrior unterwegs den Internet Traffic zu einem VPN-Provider schicken möchte und gleichzeitig auf private Ressourcen im privaten Netzwerk zuhause oder in der Firma zugreifen möchte.

    In diesem Fall werden in der Regel die Netzwerkschnittstellen tun1 und tun2 verwendet.

Routing bei selbst gebastelten VPNs

Im folgenden wird beschrieben, wie das Routing am Ende funktionieren sollte und mit welchen Tools man es verifizieren kann. Die Konfiguration der VPNs wird hier nicht beschrieben.

  1. DNS: Bevor der Browser einen Server kontaktieren kann, muss er einen DNS-Server nach der IP-Adresse fragen. In der Beispielkonfiguration sind zwei DNS-Server bekannt. Die Fritz!Box hat bei der Einrichtung der WLAN Schnittstelle einen DNS-Server via DHCP konfiguriert und außerdem wurde für das bzw. die VPN(s) mindestens ein weiterer DNS-Server eingerichtet.

    • Wenn der DNS Daemon kein Split-DNS unterstützt, dann hat man ein Problem!!!

      Die DNS-Anfrage werden parallel an alle bekannten DNS-Server gesendet (Fritz!Box und DNS-Server der VPNs) und das Ergebnis sind DNS-Leaks. Um DNS-Leaks zu vermeiden, muss man die unerwünschten DNS-Server aus der Konfiguration entfernen!

      Man sollte deshalb einen modernen DNS Daemon zu verwenden, der Split-DNS kann.

    • Wenn der DNS Daemon Split-DNS unterstützt (z.B. systemd-resolved), dann ist alles ok. Mit den Kommandos "resolvectl" oder "systemd-resolve --status" kann man es sich anschauen.

      Variante A: Wenn man einen VPN-Provider verwendet, der sich um den gesamten Traffic kümmern soll mit Ausnahme des heimischen Netzwerkes, dann sollte der DNS-Server des VPN-Providers der Server mit +DefaultRoute sein und der DNS-Server der Fritz!Box soll nur noch für die heimische Domain (z.B. fritz.box) verwendet werden (-DefaultRoute).

      > systemd-resolve --status
      Global
         resolv.conf mode: foreign
         Current DNS Server: 10.18.0.1
         DNS Servers: 10.18.0.1 192.168.178.1
         DNS Domain: fritz.box

      Link 2 (wls6) # WLAN
         Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: -DefaultRoute ...
         DNS Servers: 192.168.178.1
         DNS Domain: fritz.box

      Link 3 (tun0) # VPN
         Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute ...
         DNS Servers: 10.18.0.1

      Variante B: Wenn man das VPN als Road Warrior nutzt und neben dem normalen Internet Zugang zusätzlich Zugriff auf das internen Netz einer Firma oder das eigene Heimnetz haben möchte, dann sind DefaultRoute und DNS Domain umgekehrt zu konfigurieren.

      Wenn man beispw. von unterwegs zusätzlich auf ein privates Netz 172.22.22.0/24 mit dem DNS-Server 172.22.22.3 und dem DNS Suffix grotta.del.cane zugreifen möchte, dann muss das Split-DNS Routing nach dem Aktivieren des VPNs wie folgt aussehen:

      > systemd-resolve --status
      Global
         resolv.conf mode: foreign
         Current DNS Server: 192.168.178.1
         DNS Servers: 172.22.22.3 192.168.178.1
         DNS Domain: fritz.box grotta.del.cane

      Link 2 (wls6) # WLAN
         Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute ...
         DNS Servers: 192.168.178.1
         DNS Domain: fritz.box

      Link 3 (tun0) # VPN
         Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: -DefaultRoute ...
         DNS Servers: 172.22.22.3
         DNS Domain: grotta.del.cane

      Variante C: Wenn man mit zwei VPNs arbeitet und den Internet Traffic zu einem VPN-Provider schicken und gleichzeitig über ein zweites VPN auf heimische Ressourcen zugreifen will, dann müsste die Split-DNS Konfiguration am Ende so aussehen;

      > systemd-resolve --status
      Global
         resolv.conf mode: foreign
         Current DNS Server: 10.18.0.1
         DNS Servers: 172.22.22.3 10.18.0.1 192.168.178.1
         DNS Domain: fritz.box grotta.del.cane

      Link 2 (wls6) # WLAN
         Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: -DefaultRoute ...
         DNS Servers: 192.168.178.1
         DNS Domain: fritz.box

      Link 3 (tun1) # VPN-Provider
         Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute ...
         DNS Servers: 10.18.0.1

      Link 4 (tun2) # privates VPN
         Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: -DefaultRoute ...
         DNS Servers: 172.22.22.3
         DNS Domain: grotta.del.cane

  2. IPv4: Das Routing des IPv4 Traffic kann man sich mit dem Befehl "ip route" anschauen:

    > ip route

    default via 10.18.0.1 dev tun0 proto static metric 50
    default via 192.168.178.1 dev wls6 proto dhcp metric 600

    10.18.0.0/16 dev tun0 proto kernel scope link src 10.18.0.10 metric 50
    37.58.58.230 via 192.168.178.1 dev wls6 proto static metric 600

    192.168.178.0/24 dev wls6 proto kernel scope link src 192.168.178.31 metric 600
    192.168.178.1 dev wls6 proto static scope link metric 600

    Als allgemeine Routing Regel gilt: es wird immer die "most specific rule" verwendet.

    • Die erste Zeile mit default legt fest, wo der Traffic hinfließen soll, der im weiteren nicht näher spezifiziert wird. Weitere default Zeilen werden ignoriert. Im Beispiel werden diese Daten zum VPN-Interface tun0 geschickt.

    • Traffic in das Netz des VPN Providers, in ein Firmennetz oder ein privaten Netz wie die grotta.del.cane wird zum VPN-Interface tun0 geschickt. Im Beispiel ist es 10.18.0.0/16.

      Der Server mit der IP-Addr. 37.58.58.230 ist der VPN-Server. Der (verschlüsselte) Daten­verkehr zu diesem Server muss zum Router über das WLAN Interface geschickt werden.

    • Wenn ein Server mit einer IP-Adresse aus dem Netzbereich des lokalen Netzes (IPs 192.168.178.1…255) kontaktiert wird, dann geht der Traffic sofort zur WLAN Schnittstelle. Das ist praktisch, weil so die Dienste im heimischen LAN trotz VPN erreichbar bleiben.

      Außerdem ist die IP-Addr. 192.168.178.1 der Fritz!Box via WLAN Interface ereichbar.

    Das Beispiel sollte genügen, um auch andere Konfiguration verifizieren zu können.

  3. IPv6: Wenn eine Internetanwendung einen Server mit einer IPv6 Adresse kontaktieren möchte, dann geht der Traffic im Beispiel immer am VPN vorbei direkt über WLAN Schnittstelle und die Fritz!Box ins Internet, weil nur das Interface "wlan0" eine aktive IPv6 Adresse hat.

    Moderne Internetanwendungen bevorzugen IPv6. Sie fragen den DNS-Server zuerst nach einem AAAA-Record (IPv6 Adresse) und erst dann nach einem A-Record (IPv4 Adresse). Wenn der Server also via IPv6 erreichbar ist, läuft der Datenverkehr NIE über ein VPN!

    Das kann zum Problem werden, wenn man den gesamten Datenverkehr durch das VPN schicken möchte. In diesem Fall muss man Maßnahmen ergreifen, um Daten­verkehr am VPN vorbei zu unterbinden. IPv6 muss man abschalten (oder mit einer Firewall blockieren).