Vor einiger Zeit wurde hier im Blog gezeigt, wie man mit Pi-hole einen Werbeblocker für das gesamte Netzwerk einrichten kann (siehe Nie mehr Werbung – Pi-hole auf Ubuntu Server 18.04). Seitdem möchte ich diese Funktion nicht mehr missen.
Um auch unterwegs ohne Werbung auszukommen, verbinde ich mein Smartphone mittels VPN ins heimische Netzwerk. Damit wird dann auch der Pi-hole als DNS-Server genutzt, sobald die VPN-Verbindung steht und Werbung/Tracker werden wie gewohnt blockiert.
Nun gibt es allerdings ein Problem: Ich hoste zu Hause mehrere Websites (z.B. Nextcloud). Bei aktiver VPN-Connection ist dann leider keine Verbindung mehr zu diesen Diensten möglich, da die Domain(s) anscheinend nicht mehr aufgelöst werden können.
Im folgenden Artikel werde ich der Sache auf den Grund gehen und eine sehr einfache Möglichkeit zeigen, wie man das Problem mittels Pi-hole lösen kann.
Netzwerk-Konfiguration
Zunächst eine kurze Beschreibung der Netzwerk-Konfiguration: Als Router kommt eine handelsübliche FritzBox zum Einsatz. Diese stellt das interne Netzwerk (LAN) 192.168.178.0/24 bereit. Die VPN-Konfiguration wurde wie auf den AVM-Hilfeseiten beschrieben eingerichtet.
In diesem LAN wird eine Website gehostet (Nextcloud), der per DynDNS erreichbar ist. Die entsprechenden Port-Forwardings sind dementsprechend in der FritzBox hinterlegt.
Auf der „anderen Seite“ kommt ein Android-Smartphone zum Einsatz. Die VPN-Verbindung wird hier über die App VpnCilla aufgebaut.
Unter den Verbindungs-Einstellungen wird dabei unter Force Default Route die Option via VPN (der VPN server muss dies zulassen) gewählt. Diese Einstellung ist wichtig, da diese dafür sorgt, dass sämtlicher Netzwerk-Verkehr über die VPN-Verbindung geroutet wird.
Bisher noch alles recht unspektakulär: Diese oder ähnliche Konfigurationen dürften häufiger anzutreffen sein.
Nun gibt es wie gesagt das Problem, dass keine Verbindung zur selbst gehosteten Webanwendung möglich ist, sobald die VPN-Verbindung aufgebaut wurde…
Split Tunneling/Reverse Split Tunneling
Was hat es nun mit diesen Begriffen auf sich? Unter Split Tunneling versteht man eine Technik bei VPN-Verbindungen, bei der nur der Verkehr über die VPN-Connection geroutet wird, der das lokale Netzwerk als Ziel hat. Dies entspricht übrigens der Option via lokales WiFi/Mobile Netzwerk in den Einstellungen von VpnCilla.
Bedeutet im Klartext, dass in diesem Fall der normale Netzwerk-Verkehr (z.B. beim Surfen auf dem Smartphone) einfach über die Mobilfunk-/WLAN-Verbindung direkt ins Internet geroutet wird. Nur Netzwerk-Verkehr, der explizit an das Netzwerk gerichtet ist, zu dem eine VPN-Verbindung besteht, wird auch über die VPN-Verbindung geroutet.
Wenn nun sämtlicher Netzwerk-Verkehr über die VPN-Verbindung geroutet wird, benötigt man ein sog. Reverse Split Tunneling (manchmal auch Inverse Split Tunneling genannt). Das ist im Prinzip das gleich wie Split Tunneling, jedoch „in der Gegenrichtung“: Über die VPN-Verbindung kommt ein Request auf die lokal gehostete Website rein. Um diesen Request beantworten zu können, muss die Domain aufgelöst werden und der Request „über das Internet“ geleitet werden. Der Response wird hier wieder über die VPN-Verbindung ausgeliefert.
Und genau das ist das Problem: Eine FritzBox unterstützt leider kein Reverse Split Tunneling. Das Resultat ist nun, dass die lokal gehostete Website nicht aufgerufen werden kann, wenn VPN auf dem Smartphone aktiv ist.
Daher müsste man sich nun entscheiden: Entweder man nutzt VPN mit Zugriff auf das entfernte Netzwerk, oder man benötigt Zugriff auf die lokal gehostete Website. Hier müsste man dann je nach Bedarf die VPN-Verbindung an- bzw. ausschalten.
Pi-hole als lokaler DNS-Server
Aber Moment mal: Der Pi-hole im lokalen Netzwerk dient doch als DNS-Server für das gesamte Netz. Hier bietet es sich natürlich an, die Domains, über die Dienste lokal gehostet werden, auf die jeweilige lokale IP-Adresse aufzulösen. Als Beispiel: Eine Webanwendung mit der Domain meinedomain.de wird auf einer Maschine mit der lokalen IP 192.168.178.60 gehostet. Pi-hole kann nun so eingestellt werden, dass der Aufruf von meinedomain.de im lokalen Netzwerk immer auf die lokale IP 192.168.178.60 aufgelöst wird. Das ganze wirkt dann ausschließlich im LAN, externe Aufrufe „aus dem Internet“ sind dadurch nicht betroffen.
Seit der Version 5.0 von Pi-hole unterstützt der Werbeblocker eben genau dieses „Umbiegen“ auf lokale IP-Adressen. Dazu wird einfach der Menüpunkt Local DNS Records im Menü aufgerufen. Nun kann im oberen Bereich eine Domain und die dazugehörige lokale IP-Adresse eingegeben werden.
Ab sofort wird nun meinedomain.de im lokalen Netzwerk für alle Clients, die den Pi-hole als DNS-Server nutzen, auf die lokale IP-Adresse aufgelöst. Dies funktioniert dann auch außerhalb des LANs, wenn die Verbindung mittels VPN aufgebaut wird.
Dies funktioniert natürlich nicht nur mit dem Pi-hole, sondern auch mit jedem anderen (lokal betriebenen) DNS-Server.
Direkter Zugriff auf Webanwendungen über LAN
Durch die Auflösung einer Domain auf die lokale IP-Adresse ergibt sich noch ein weiterer positiver Nebeneffekt: Da der Zugriff immer direkt über das LAN erfolgt, erhält man nun in der Regel einen erheblichen Performance-Gewinn, wenn man sich im gleichen Netzwerk befindet. Im LAN hat man üblicherweise eine Netzwerkgeschwindigkeit von 1 GBit/s, was deutlich schneller ist als hiesige Internet-Anschlüsse. Da ein Webrequest nun nicht mehr über das Internet geroutet wird, sondern das LAN niemals verlässt, hat man mit dieser Lösung nun immer die volle LAN/WLAN Geschwindigkeit.
Alternative Variante ohne DNS-Server
Wer keinen eigenen DNS-Server/Pi-hole betreibt, der kann sich aber auch einer alternativen Variante bedienen: Auf jedem Client kann die IP-Adresse zu einer Domain direkt hinterlegt werden. Dies geschieht normalerweise in der Datei /etc/hosts (unter Windows: C:\Windows\System32\drivers\etc\hosts). In dieser Datei wird einfach für jede Domain, die lokal aufgelöst werden soll, ein Eintrag am Ende der Datei hinzugefügt:
192.168.178.60 meinedomain.de
Anschließend erfolgt der Zugriff dieses Clients auf die Domain dann über die lokale IP-Adresse.
Das Vorgehen ist dann auf allen Clients des lokalen Netzwerks zu wiederholen (das macht diese Lösung daher etwas aufwändiger).
Fazit
Die hier gezeigte Lösung sorgt zum einen dafür, dass man auch trotz bestehender VPN-Verbindung Zugriff auf Webanwendungen im gleichen Netzwerk hat. Zum anderen wird der Zugriff auf diese Anwendungen über das lokale Netzwerk extrem beschleunigt, da die Requests nicht mehr über das Internet geroutet werden müssen, sondern das lokale Netzwerk niemals verlassen.
Auf diese Weise kann man Pi-hole nicht nur zum Blockieren von Werbung und Trackern einsetzen, sondern auch gezielt Domains auf eigene IPs „umbiegen“.
Eine Umsetzung dieser sollte man allerdings gut dokumentieren und im Hinterkopf behalten. Da man hier aktiv in die Netzwerk-Konfiguration eingegriffen hat, gestaltet sich eine Fehlersuche häufig schwieriger.
In Zukunft hat man nun auch mit aktiver VPN-Verbindung, bei der sämtlicher Traffic über VPN geschützt ist, einen direkten Zugriff auf lokal gehostete Dienste.
Weiterführende Artikel
- Nie mehr Werbung – Pi-hole auf Ubuntu Server 18.04
- Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
Hallo Jan,
das ist gleichzeitig die Lösung für mein Problem :
ich will auf meinem Homeserver z.B. DokuWiki hosten und immer über https://wiki.meinedomain.de zugreifen. Dabei will ich das so einstellen, dass die Anfragen aus dem LAN/VPN ohne Beschränkung erfolgen und externe Abfragen mit einem nginx-Passwortschutz versehen sind.
satisfy any;
allow 192.168.100.0/24;
allow 192.168.200.0/24;
allow 192.168.250.0/24;
deny all;
auth_basic „Restricted Area“;
auth_basic_user_file conf/htpasswd;
Jetzt würde ich die lokale IP für DokuWiki-Server bei Pi-Hole einstellen.
Gruss
Hi Tom,
Super Hinweis. Genau solche „Spielereien“ sind dann damit auch möglich.
Gruß,
Jan
Hallo Jan,
ich habe das jetzt ausprobiert und muss feststellen, dass es so nicht funktioniert.
Bei PiHole habe ich einen lokalen DNS-Record gesetzt :
wiki.meinedomain.de auf 192.168.150.2
Wenn ich die Domain in meinem LAN, im Browser aufrufe, wird aber mit externer IP zugegriffen.
Grund ist wahrscheinlich die CNAME-Deepinspection, die wiki.meinedomain.de auf dyndns.meinedomain.de auflöst und dann die externe IP zurückgebt.
Evtl. das gleiche wie hier :
https://github.com/pi-hole/pi-hole/issues/3619
Oder hast du hierfür eine Lösung ?
LG
Hi Tom,
was meinst du genau mit CNAME-Deepinspection? Ist das eine Sache der Firewall?
Ich habe auch etliche CNAME-Einträge auf etlichen Domains. Intern komme ich mit den Tipps aus diesem Artikel über die lokale IP rein. Da „funkt“ mir also nichts dazwischen.
Edit: Wenn du also in deinem Netzwerk ein Ping auf wiki.meinedomain.de machst, kommt da die externe IP zurück?
Gruß,
Jan
Deep CNAME Inspection versucht die „neuen“ Tricks der Werbeindustrie zu verhindern. Da wird ein CNAME von img.gute-seite.de auf werbung.boese-seite.de erstellt damit die Adblocker die Werbung nicht blockieren.
https://pi-hole.net/2020/05/10/pi-hole-v5-0-is-here/#page-content
Ich kriege mit dem ping auf wiki.meinedomain.de die externe IP obwohl diese bei pi-hole als lokaler DNS Record eingetragen ist.
CNAME_DEEP_INSPECT=false und Neustart vom DNS-Resolver hat auch nicht geholfen.
Hi Tom,
OK, dieses Feature ist irgendwie an mir vorbei gegangen. Bei mir ist es auf jeden Fall aktiviert. Daher denke ich mal, dass dies nicht dein Problem ist.
Dann versuch mal eine alternative Methode: Trag mal in der /etc/hosts auf dem Pi-hole einen Eintrag für deine Domain an:
192.168.150.2 wiki.meinedomain.deMeiner Erfahrung nach beachtet er hier auch die /etc/hosts. Vor der neuen Version von Pi-hole konnte man sich nämlich das hier beschriebene auch auf diese Art und Weise „nachbauen“.
Gruß,
Jan
Mit Einträgen in der /etc/hosts von PiHole hat es anfangs nicht geklappt und
jetzt klappt alles. Evtl. lag es am DNS-Cache ?
P.S.
Bin dabei nach dieser Anleitung noch das Webinterface von PiHole abzusichern.
Finde es gut auch im Heimnetz über Https auf Dienste zuzugreifen.
https://fotis.xyz/posts/https-for-local-sites/
Hi Tom,
ja, vielleicht wurde irgendwas gecached.
Ich begrenze den Web-Zugang für Pi-hole immer nur auf das lokale Netzwerk, d.h. hier kommt man nur in gleichen Netzwerk oder VPN drauf. Optional kann man dann noch ein HTTPS-Zertifikat nutzen. Hier ist man allerdings auf selbst signierte Zertifikate beschränkt, da ja kein Zugriff auf Port 80 von außen möglich ist.
Gruß,
Jan
Hallo Jan,
nein, das ist das Coole dran – man erstellt Lets Encrypt Zertifikate für pi-hole auch wenn sie von Außen nicht erreichbar ist.
Das geht mit der DNS-Challange (über den TXT-Record).
acme.sh kennt schon viele DNS-Provider.
Ich erstelle zuerst eine Subdomain pi-hole.local.meinedomain.de.
Zertifikat für meine Subdomain bei INWX wird so erstellt :
acme.sh –issue –dns dns_inwx -d pi-hole.local.meinedomain.de
https://github.com/acmesh-official/acme.sh/wiki/dnsapi
Gruss
Hi Tom,
das klingt echt interessant. Muss ich mir bei Gelegenheit mal näher ansehen.
Gruß,
Jan
Ich empfehle als VPN hier anstatt das IPSek der FritzBox, WireGuard als VPN. Wesentlich schneller, und sicherlich auch Akkuschonender als die anderen Lösungen.
https://www.wireguard.com/
Sicherlich wirst du dazu einmal einen schönen Artikel machen :-)
Hi Jan,
durch dieses umbiegen sind allerdings alle Dienste des lokalen Servers wie cloud.meinedomain.de nicht mehr aus dem Gastnetz der FRITZ!Box erreichbar.
Beispiel:
192.168.0.1 FRITZ!Box
192.168.0.5 Server + pihole
192.168.179.1 client (Gastzugang)
Wenn das pihole als DNS-Server in der FRITZ!Box eingetragen ist, dann erhält der Client die 192.168.179.1 als DNS-Server und die FRITZ!Box holt sich die IPs vom pihole, dann erhält der Client beim Aufruf von cloud.meinedomain.de die 192.168.0.5 zurück und kann diesen Server nicht erreichen, da oder Client im getrennten 192.168.179.0 -Gast-Netz ist.
Gibt es dafür einen workaround?
Viele Grüße
Marcel
Hi Marcel,
ich denke, da man dies nicht so einfach hinbekommt, da das normale Netzwerk und das Gast-Netzwerk ja (nicht ohne Grund) komplett voneinander getrennt sind. Du könntest höchstens versuchen, den Server mit einem zweiten Netzwerkadapter zusätzlich noch ins Gastnetz zu hängen. Da bräuchtest du dann allerdings eine andere DNS-Auflösung, da man hier am Pi-hole nicht trennen kann, also vermutlich auch eine zweite Pi-hole Instanz.
Ob das ganze allerdings empfehlenswert ist, steht auf einem anderen Blatt, da der Server ja dann quasi eine Brücke zwischen Netzwerk und Gastnetz darstellt.
Gruß,
Jan
Hallo,
gibt es dabei eigentlich auch die Möglichkeit auf eine IP zu verweisen, und einen Port des jeweiligen Gerätes anzusprechen? Denn wenn ich einfach bei der Target IP den Port anhänge bekomme ich den Fehler, dass es keine gültige IP ist…
Danke