Synology VPN Server - OpenVPN - PiHole - kein Internetzugriff

[Dok-Tore]

dhcp-option DNS <pihole.ip>

das habe ich vorhin schon versucht... leider ohne Erfolg...

Ergänzung (25. Februar 2021)

evtl push dhcp-option???

 

[Tanzmusikus]

Achtung! Doppelte Ports mit Dockers!

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[Raijin]

15:21:23 - DNS: No settings provided, using current network settings

Da steht's doch. Über die VPN-Verbindung kommen keine DNS-Einstellungen und deswegen wird am Client weiterhin der voreingestellte DNS verwendet, also der vom dortigen WLAN oder wo auch immer sich der Client gerade befindet.

Grundsätzlich müssen für das Surfen via OpenVPN mehrere Kriterien erfüllt sein:

1. Der OpenVPN-Server muss "redirect-gateway" pushen oder der Client muss dies in seiner Config selbst setzen
2. Der OpenVPN-Server muss die Verbindung durch ihn hindurch auch zulassen
3. Wenn der OpenVPN-Server kein ausgehendes NAT macht, also die VPN-Clients hinter seiner eigenen LAN-IP verbirgt, benötigt der Internetrouter eine statische Route ins VPN-Subnetz

Für einen DNS-Server außerhalb des VPNs gilt zusätzlich:

4. Sofern der OpenVPN-Server kein ausgehendes NAT macht wie in 3., muss der DNS-Server explizit in seiner Firewall für Zugriffe aus dem VPN-Subnetz freigeschaltet werden.

15:21:23 - Routing.IPv4: Setting default gateway to 192.168.210.5

Das hier bestätigt zumindest, dass redirect-gateway angekommen ist. Aber

topology net30

das wiederum ist eine Einstellung, die ich auf den Tod nicht leiden kann, weil damit für jeden Client ein eigenes kleines /30er Subnetz erstellt wird, daher ist das Gateway oben auch die .5 und nicht die .1 wie man vielleicht erwarten würde. die net30 Einstellung ist daher für ungeübte Anwender ein wenig undurchsichtig, weil man gar nicht weiß warum und wieso das Gateway plötzlich vermeintlich "falsch" ist. Sofern die VPN-Clients nicht explizit voneinander isoliert sein sollen, würde ich daher immer die Einstellung topology subnet verwenden, weil dann ein vollkommen stinknormales verdammtes VPN-Subnetz erstellt wird, bei dem auch jedem klar ist welches Gateway verwendet wird - die .1, weil das der VPN-Server ist. Ich weiß nicht inwiefern man das in einer Synology ändern kann, aber abgesehen von meiner Abneigung gegenüber net30 sollte es dennoch funktionieren.



Wie dem auch sei, durch bloßes Hingucken und Rumgerate werden wir der Ursache kaum auf die Schliche kommen. Ein Smartphone ist ein denkbar schlechtes Werkzeug, um eine VPN-Verbindung zu debuggen. Im Idealfall nimmst du dir einen Laptop und verbindest ihn mit dem mobilen Hotspot des Handys und nutzt dann dessen Mobilfunkinternet für die VPN-Verbindung. Dazu muss natürlich OpenVPN auf dem Laptop installiert und die Konfig-Datei vom NAS auf dem Laptop eingespielt sein. Auf einem Laptop hat man dann bessere Möglichkeiten, das Problem zu analysieren.

Sollte ein Laptop nicht greifbar sein, möchte ich dich bitten, dir im App Store eine Netzwerk-Tool-App runterzuladen. Diese kann Ping ausführen, aber auch mittels Traceroute den Weg eines Pings verfolgen sowie explizit DNS-Queries generieren. Damit kann man gezielt prüfen ob das Routing stimmt und ob DNS funktioniert oder nicht.


Tests für das VPN (am Beispiel Windows):

0. ipconfig /all
1. ping hier.die.router.ip.von.zu.hause
2. ping hier.die.pihole.ip
3. ping 8.8.8.8
4. tracert 8.8.8.8
5. nslookup computerbase.de
6. nslookup computerbase.de hier.die.router.ip.von.zu.hause
7. nslookup computerbase.de hier.die.pihole.ip
8. nslookup computerbase.de 8.8.8.8

Das sind wie gesagt Tests für die eigentliche Verbindung, das Routing sowie DNS. In einer App am Handy kann man dies auch machen, aber das ist natürgemäß absolut vollkommen total mega besch...eiden

 

[Tanzmusikus]

Auf Android nutze ich z.B. die App "Termux". Damit kann ich Ping & ähnliche Dinge ausführen.
Am iPhone wird vermutlich ähnlich wie bei Android ein UNIX Terminal installierbar über den Appstore vorhanden sein.

Ein Ping durch das VPN muss aber auch erstmal ermöglicht/erlaubt werden.

 

[Raijin]

Gerade das gilt es ja herauszufinden. Wir wissen nicht was technisch geht und was nicht geht, wenn lediglich das Endergebnis "Surfen geht nicht" getestet wird. Auf dem Weg vom VPN ins www und zurück gibt es viele Stellen, an denen es hängenbleiben kann. Daher erstmal ganz unten anfangen und die Basics abklären.

 

[Tanzmusikus]

Jep. Guter Ansatz.

Dazu kommt noch, wie sind die einzelnen "Netzwerk-Teile" konfiguriert.
Also z.B. wurde PiHole über den Docker installiert? Wird der DNS des PiHole oder der Synology genutzt.
Wird Portainer genutzt? Wie sind dort die NW-Einstellungen?
Sind Dienste (DHCP, DNS, ...) evtl. doppelt in Betrieb?

https://foxly.de/article/3-pi-hole-auf-einer-synology-nas-installieren/
https://smarthome-training.com/de/pi-hole-docker-installation/
https://discourse.pi-hole.net/t/pi-hole-docker-lauft-seit-dem-letzten-update-nicht-mehr/44371

 

[Dok-Tore]

Puh, vielen Dank ihr beiden für die ausführlichen Infos... Besteht die Möglichkeit das wir das mal
durchgehen sodass ich das im einzelnen auch verstehen kann?

Ich fang mal hier an:

Dazu kommt noch, wie sind die einzelnen "Netzwerk-Teile" konfiguriert.
Also z.B. wurde PiHole über den Docker installiert? Wird der DNS des PiHole oder der Synology genutzt.
Wird Portainer genutzt? Wie sind dort die NW-Einstellungen?
Sind Dienste (DHCP, DNS, ...) evtl. doppelt in Betrieb?

PiHole ist über den Docker installiert, allerdings ohne MacVlan. PiHole ist unter der selben IP wie die Syno erreichbar. Allerdings unter einem anderen Port.

Portainer ist installiert, wird allerdings für PiHole nur zum Erneuern des Containers genutzt.

DHCP ist nur in der Fritz!Box aktiv. Syno off / PiHole off
DNS ist aus dem PiHole aktiv und auch in der Fritz!Box unter lokaler DNS Server eingetragen.

 

[Tanzmusikus]

DNS ist aus dem PiHole aktiv und auch in der Fritz!Box unter lokaler DNS Server eingetragen.

Welche IPs sind denn als erster & als zweiter DNS (in Fritz!Box sowie PiHole) eingetragen?

 

[Dok-Tore]

Welche IPs sind denn als erster & als zweiter DNS (in Fritz!Box sowie PiHole) eingetragen?

Hier mal ein paar Screenshots:

Ergänzung (25. Februar 2021)

Tests für das VPN (am Beispiel Windows):

0. ipconfig /all
1. ping hier.die.router.ip.von.zu.hause
2. ping hier.die.pihole.ip
3. ping 8.8.8.8
4. tracert 8.8.8.8
5. nslookup computerbase.de
6. nslookup computerbase.de hier.die.router.ip.von.zu.hause
7. nslookup computerbase.de hier.die.pihole.ip
8. nslookup computerbase.de 8.8.8.8

Kurz mal zu dem gesamten Thread....

Ich habe jetzt via Notebook über einen mobilen Hotspot eine Verbindung zum VPN Server.

Das heisst ich mache jetzt erstmal die hier o.a. Tests und poste die hier komplett inkl. der MAC Adressen usw. ?
Oder wie gehe ich jetzt am besten vor? So tief stecke ich da ja auch nicht in der Materie drin...

Danke schon mal...

 

[Tanzmusikus]

Hier könnte zum Testen mal Option 3 "Listen on all interfaces, permit all origins" aktiviert werden.
!! Ups, aber bitte nicht machen, wenn Port 53 von der Fritte zum PiHole weitergeleitet wird !!

Ergänzung (25. Februar 2021)

Das heisst ich mache jetzt erstmal die hier o.a. Tests und poste die hier komplett inkl. der MAC Adressen usw. ?

Bitte entferne doch zu Deinem eigenen Schutz private/personenbezogene Daten aus Deinen Posts bzw. veröffentliche diese erst gar nicht.
MAC-Adressen sind unique/einzigartig & deshalb können deshalb Rückschlüsse auf Dich im Internet geben.
Außerdem können diese dann für Angriffe im Internet quasi "unter Deinem Namen" genutzt werden.

***

Letztlich brauchst Du nur zu Schauen, wie die Ergebnisse der Befehlsausführungen verlaufen.
Screenshots oder Copy'n'Paste für Dich selbst könnten hilfreich sein. Brauchst Du hier aber nicht zu posten.

Es reicht also, wenn Du uns antwortest:
1. (nicht) erfolgreich
4. endet mit *** (also erfolglos bzw. Teilerfolg oder zeigt lokale IP der Fritzbox o.s.ä.)
...

 

[Dok-Tore]

Habe ich aktiviert... kannst Du mir sagen was das bedeutet?

Jetzt taucht das Gerät, welches per VPN verbunden ist im PiHole auf (s. Anlage)

Trace Route - s. Anlage

 

[Raijin]

Good catch @Tanzmusikus


@Dok-Tore : Damit werden mehrere Sachen gleichzeitig eingestellt. Einerseits ist es so, dass ein Dienst wie DNS auf eine Schnittstelle bzw. eine IP-Adresse gebunden werden kann. Das heißt, dass man pihole explizit sagen kann, dass er nur auf der LAN-Schnittstelle, nicht aber auf der virtuellen VPN-Schnittstelle laufen und somit antworten soll, oder man sagt pihole, dass er auf allen Schnittstellen läuft.

Darüber hinaus sagt die 3. Option aber noch "permit all origins". Das wiederum fügt noch etwas hinzu. Standardmäßig sind Dienste wie DNS so eingestellt, dass sie ausschließlich aus dem lokalen Netzwerk bedienbar sind. D.h., dass die interne Firewall - manchmal auch der Dienst selbst - Verbindungen von "unbekannten" IP-Adressen blockiert. Der VPN-Dienst muss beispielsweise so eingestellt sein, weil man sonst niemals vom Internet aus eine Verbindung herstellen könnte, weil man ja von außen mit einer "unbekannten" IP-Adresse kommt, eine beliebige öffentliche IP-Adresse aus dem www. In diesem Falle ist für pihole der Client hinter dem VPN eben auch "unbekannt" und somit wird er standardmäßig geblockt.

@Tanzmusikus hat aber Recht, dass du das nur aktivieren darfst, wenn du keine Portweiterleitung im Router auf den pihole hast, also Port 53 --> pihole. Wobei davor so oder so abzuraten ist, weil man niemals einen öffentlich erreichbaren DNS-Server laufen lassen sollte, wenn man nicht genau weiß was man da tut. Sonst bekommt man sehr schnell Post vom Provider oder gar von der Bundesnetzagentur, weil sonst jemand deinen DNS für .. .. unschöne Zwecke nutzen könnte. DNS also stets nur lokal oder eben über VPN nutzen, nie aber direkt im Router als Weiterleitung einrichten.

 

[Tanzmusikus]

Ein Sprung (Hop) ist dann wohl von einem Netz in einen anderes.
Oder auch eine Route intern. Oder von einem Server zum nächsten, wenn es mit einem Netz-Wechsel einhergeht.
Sieht man bei dem Befehl "tracert <IP>" sehr schön.

 

[Dok-Tore]

@Tanzmusikus
@Raijin

An dieser Stelle möchte ich wirklich ein ganz großes DANKESCHÖN loswerden, das ihr das Problem mit mir angegangen seid und wir die Lösung des Problems gefunden haben.

2 Sachen habe ich noch....

Port 53 ist zu. Da läuft nix. Lediglich Port 80/443 und der OpenVPN Port sind offen...

Die Lösung die wir hier herbei geführt haben ist eine gute Lösung oder sollte man unterm Strich die ganze Kompente nochmal durchleuchten?

Wie gesagt -> DANKE !!!!

Dok-Tore

 

[Raijin]

@Tanzmusikus Ein Hop entfernt ist exakt in ein und demselben Subnetz. In ein benachbartes Subnetz wären es 2 Hops, 1) das Gateway ins andere Subnetz und 2) das Ziel bzw. dann eben die Quelle.

Port 53 ist zu. Da läuft nix. Lediglich Port 80/443 und der OpenVPN Port sind offen...

Das kommt ganz darauf an. Wenn Port 80 nichts anderes tut als auf 443 umzuleiten, also http in https gezwungen wird, wäre das vertretbar. Wenn allerdings direkt ein http-Service läuft, rate ich davon ab. Generell würde ich bei Vorhandensein einer VPN-Verbindung nichts zulassen außer das VPN selbst. Über die VPN-Verbindung kann man alles tun und lassen was man möchte, aber wenn der Webserver auf 80/443 angreifbar ist, kann das gesamte Netzwerk kompromittiert werden.
Und bevor der Einwand kommt: Ja, dasselbe gilt im Prinzip für das VPN auch, aber OpenVPN ist ja gerade für Sicherheitszwecke entwickelt worden, einen Webserver hat heutzutage aber so ziemlich jedes Gerät mit (W)LAN und kann somit auch beliebig (un)sicher sein. Daher mache ich da persönlich keine Ausnahmen, alles nur via VPN und das war's.

 

[Tanzmusikus]

Genau das ist mir auch gerade eingefallen.
Da möchte einer der übermäßigen Werbung entkommen ... und macht unwissentlich ein Scheunentor für Angreifer auf.

Wenn OpenVPN über HTTPS verschlüsselt wird, reicht es aus Port 443 für TCP oder Port 1194 für UDP zu öffnen.