14
Routing über VPN statt über öffentliche IP?
Hallo zusammen,
innerhalb unseres Vereins betreiben wir eine Intranet-Seite, auf die natürlich nur aus dem internen Netz ein Zugriff erfolgen soll (bzw. bei aktiver OpenVPN-Verbindung). Bisher waren diese Seiten unter der privaten Adresse intranet.verein.local erreichbar. Problematisch hierbei war, dass verschlüsselte Seiten (https) bei privaten Endgeräten stets zu Zertifikatsfehlern geführt haben, da die Stammzertifizierungsstelle ja zunächst als vertrauenswürdig definiert werden muss. Technisch sicherlich alles machbar, aber für den Standardanwender - trotz kommunizierter Anleitung - eher unpraktisch, insbesondere auch dann, wenn mobile Endgeräte im Spiel sind.
Wir haben daher die Intranet-Seite auf die Subdomain intranet.domain.tld umgestellt und per Let's Encrypt ein entsprechendes Zertifikat zuteilen lassen. Gleichzeitig wird per IP festgestellt, ob ein Zugriff erfolgen darf ("internes Netz") oder nicht. Dies funktioniert alles soweit. Einziges Problem besteht bei den Zugriffen per OpenVPN. Da die Subdomain intranet.domain.tld wg. LE öffentlich erreichbar sein muss, wird über die öffentliche IP geroutet, was natürlich vom Server abgelehnt wird. Der einzige von uns identifizierte Workaround besteht derzeit darin, die Verbindungsmetrik der VPN-Verbindung ggü. dem allgemeinen Netz zu verringern, damit eine entsprechende Priorisierung zu Gunsten der VPN-Verbindung erfolgt. Ist aber auch eher suboptimal...
Gibt es ggf. eine elegantere Lösung?
Viele Grüße
Michael
innerhalb unseres Vereins betreiben wir eine Intranet-Seite, auf die natürlich nur aus dem internen Netz ein Zugriff erfolgen soll (bzw. bei aktiver OpenVPN-Verbindung). Bisher waren diese Seiten unter der privaten Adresse intranet.verein.local erreichbar. Problematisch hierbei war, dass verschlüsselte Seiten (https) bei privaten Endgeräten stets zu Zertifikatsfehlern geführt haben, da die Stammzertifizierungsstelle ja zunächst als vertrauenswürdig definiert werden muss. Technisch sicherlich alles machbar, aber für den Standardanwender - trotz kommunizierter Anleitung - eher unpraktisch, insbesondere auch dann, wenn mobile Endgeräte im Spiel sind.
Wir haben daher die Intranet-Seite auf die Subdomain intranet.domain.tld umgestellt und per Let's Encrypt ein entsprechendes Zertifikat zuteilen lassen. Gleichzeitig wird per IP festgestellt, ob ein Zugriff erfolgen darf ("internes Netz") oder nicht. Dies funktioniert alles soweit. Einziges Problem besteht bei den Zugriffen per OpenVPN. Da die Subdomain intranet.domain.tld wg. LE öffentlich erreichbar sein muss, wird über die öffentliche IP geroutet, was natürlich vom Server abgelehnt wird. Der einzige von uns identifizierte Workaround besteht derzeit darin, die Verbindungsmetrik der VPN-Verbindung ggü. dem allgemeinen Netz zu verringern, damit eine entsprechende Priorisierung zu Gunsten der VPN-Verbindung erfolgt. Ist aber auch eher suboptimal...
Gibt es ggf. eine elegantere Lösung?
Viele Grüße
Michael
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 397368
Url: https://administrator.de/contentid/397368
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
14 Kommentare
Neuester Kommentar
Glaube hier würde sich ein Split-DNS anbieten, der DNS Server vom internen Netz bekommt den Eintrag:
intranet.domain.tld > IP: interneIP
Uns sofern du den OpenVPN Clients einen DNS Server mitlieferst, sollten DNS Abfragen über den VPN zum internen Netz DNS laufen, dieser löst intranet.domain.tld mit der internenIP auf, und somit wird intern geroutet und nicht öffentlich.
Hier mal auf die schnelle ein Artikel über Google gefunden zu SplitDNS:
https://www.einfaches-netzwerk.at/split-dns-fuer-ad-fs-einrichten/
intranet.domain.tld > IP: interneIP
Uns sofern du den OpenVPN Clients einen DNS Server mitlieferst, sollten DNS Abfragen über den VPN zum internen Netz DNS laufen, dieser löst intranet.domain.tld mit der internenIP auf, und somit wird intern geroutet und nicht öffentlich.
Hier mal auf die schnelle ein Artikel über Google gefunden zu SplitDNS:
https://www.einfaches-netzwerk.at/split-dns-fuer-ad-fs-einrichten/
Moin,
Gruß,
Dani
Gibt es ggf. eine elegantere Lösung?
ein (Host)route sollte dein Problem lösen.Gruß,
Dani
Das Problem scheint dahingehend zu bestehen, dass bei den beiden Netzwerk"geräten" standardmäßig stets die "Internet"-Leitung (also nicht die OpenVPN-Leitung) priorisiert wird; insofern wird auch von dieser der DNS abfragt, der dann natürlich die öffentliche IP ausgibt. Insofern werden die bei der OpenVPN-Verbindung hinterlegten DNS überhaupt nicht gefragt.
Dies wurde wohl mit Windows 10 eingeführt (https://docs.microsoft.com/de-de/windows-server/networking/technologies/ ..).
Dies wurde wohl mit Windows 10 eingeführt (https://docs.microsoft.com/de-de/windows-server/networking/technologies/ ..).
Hi,
Das habe ich noch nicht verstanden. Bei einer Host-Route müsste ich doch eine IP angeben, oder? Wie verhält sich diese mit der DNS-Auflösung?
Viele Grüße
Michael
Das habe ich noch nicht verstanden. Bei einer Host-Route müsste ich doch eine IP angeben, oder? Wie verhält sich diese mit der DNS-Auflösung?
Viele Grüße
Michael
unter der privaten Adresse intranet.verein.local erreichbar
Schlechte Domainwahl ! 
Root Domain .local wird weltweit als mDNS Domain genutzt und ist dieser durch die IANA fest zugewiesen:
Guckst du hier:
https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
und hier:
https://www.heise.de/select/ct/2017/26/1513540412603853
Ansonsten ist eine statische Hostroute mit einem 32 Prefix die Lösung wie oben schon gesagt. Die Erreichbarkeit des DNS Servers hat damit doch nichts zu tun !
Zitat von @m8ichael:
Das Problem scheint dahingehend zu bestehen, dass bei den beiden Netzwerk"geräten" standardmäßig stets die "Internet"-Leitung (also nicht die OpenVPN-Leitung) priorisiert wird; insofern wird auch von dieser der DNS abfragt, der dann natürlich die öffentliche IP ausgibt. Insofern werden die bei der OpenVPN-Verbindung hinterlegten DNS überhaupt nicht gefragt.
Dies wurde wohl mit Windows 10 eingeführt (https://docs.microsoft.com/de-de/windows-server/networking/technologies/ ..).
Doch du musst nur das DNS Suffix der Domain in der Verbindung eintragen.Das Problem scheint dahingehend zu bestehen, dass bei den beiden Netzwerk"geräten" standardmäßig stets die "Internet"-Leitung (also nicht die OpenVPN-Leitung) priorisiert wird; insofern wird auch von dieser der DNS abfragt, der dann natürlich die öffentliche IP ausgibt. Insofern werden die bei der OpenVPN-Verbindung hinterlegten DNS überhaupt nicht gefragt.
Dies wurde wohl mit Windows 10 eingeführt (https://docs.microsoft.com/de-de/windows-server/networking/technologies/ ..).
Und natürlich vorher mal den DNS Cache löschen.
Hallo,
Wie geschrieben, wird die Domain .local jetzt ja nicht mehr genutzt, sondern eine normale tld (hier: .de).
Zitat von @aqui:
Root Domain .local wird weltweit als mDNS Domain genutzt und ist dieser durch die IANA fest zugewiesen:
Guckst du hier:
https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
und hier:
https://www.heise.de/select/ct/2017/26/1513540412603853
Ansonsten ist eine statische Hostroute mit einem 32 Prefix die Lösung wie oben schon gesagt. Die Erreichbarkeit des DNS Servers hat damit doch nichts zu tun !
unter der privaten Adresse intranet.verein.local erreichbar
Schlechte Domainwahl ! Root Domain .local wird weltweit als mDNS Domain genutzt und ist dieser durch die IANA fest zugewiesen:
Guckst du hier:
https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
und hier:
https://www.heise.de/select/ct/2017/26/1513540412603853
Ansonsten ist eine statische Hostroute mit einem 32 Prefix die Lösung wie oben schon gesagt. Die Erreichbarkeit des DNS Servers hat damit doch nichts zu tun !
Wie geschrieben, wird die Domain .local jetzt ja nicht mehr genutzt, sondern eine normale tld (hier: .de).
Hallo.
Das funktioniert leider nicht. Ich habe mit ipconfig /flushdns den cache gelöscht, jedoch bringt ein nslookup intranet.domain.tld bei aktivierter OpenVPN-Verbindung nach wie vor die öffentliche IP (den Suffix habe ich in den Verbindungseinstellungen unter IPv4 auf domain.tld angepasst). Erst wenn ich wieder die Metrik auf einen Wert unterhalb der Hauptschnittstelle absenke, fragt er offensichtlich den DNS über die VPN-Verbindung ab und bringt so die interne IP-Adresse.
Zitat von @137846:
Doch du musst nur das DNS Suffix der Domain in der Verbindung eintragen.
Und natürlich vorher mal den DNS Cache löschen.
Doch du musst nur das DNS Suffix der Domain in der Verbindung eintragen.
Und natürlich vorher mal den DNS Cache löschen.
Das funktioniert leider nicht. Ich habe mit ipconfig /flushdns den cache gelöscht, jedoch bringt ein nslookup intranet.domain.tld bei aktivierter OpenVPN-Verbindung nach wie vor die öffentliche IP (den Suffix habe ich in den Verbindungseinstellungen unter IPv4 auf domain.tld angepasst). Erst wenn ich wieder die Metrik auf einen Wert unterhalb der Hauptschnittstelle absenke, fragt er offensichtlich den DNS über die VPN-Verbindung ab und bringt so die interne IP-Adresse.
Moin,
Gruß,
Dani
Das habe ich noch nicht verstanden. Bei einer Host-Route müsste ich doch eine IP angeben, oder?
Ja.Wie verhält sich diese mit der DNS-Auflösung?
Routing und DNS haben nichts miteinander zu tun. Der Client wählt die Route, die für ihn die bessere Metrik hat.Gruß,
Dani
Das funktioniert leider nicht.
Nö, kann ich nicht bestätigen.
Hallo Dani,
Zitat von @Dani:
Dann stehe ich jetzt völlig auf dem Schlauch. Denn so wie es aussieht, liegt es rein an der DNS-Auflösung, denn beide IP-Adressen (interne wie öffentliche) sind (auch ohne die Einrichtung einer gesonderten Route) erreichbar. Nur blöderweise wird halt ein DNS befragt, der nur die öffentliche IP kennt. Und eine richtige Priorisierung der VPN-Verbindung habe ich bislang nur über die manuelle Änderung der Metrik hinbekommen.Wie verhält sich diese mit der DNS-Auflösung?
Routing und DNS haben nichts miteinander zu tun. Der Client wählt die Route, die für ihn die bessere Metrik hat.
Normalerweise haben VPN Verbindungen per Default immer eine etwas geringere Metrik, da läuft bei dir also was schief.
Wenn du es sauber haben willst stellst du auf die Seite des Clients einen DNS-Server hin (kann auch ein Raspi sein) der im Netz als Default DNS arbeitet und für die interne Domain eine bedingte Weiterleitung enthält der auf den internen DNS Server verweist.
VPN herstellen lässt du am besten zentral dann entweder den Router herstellen oder das den Raspi (oder was auch immer) erledigen, fertsch.
Wenn du es sauber haben willst stellst du auf die Seite des Clients einen DNS-Server hin (kann auch ein Raspi sein) der im Netz als Default DNS arbeitet und für die interne Domain eine bedingte Weiterleitung enthält der auf den internen DNS Server verweist.
VPN herstellen lässt du am besten zentral dann entweder den Router herstellen oder das den Raspi (oder was auch immer) erledigen, fertsch.
Halli!
Ja, für den einzelnen wäre das sicher eine Lösung, aber für den DAU dann doch eher etwas überdimensioniert. Ich hatte halt die Hoffnung, dass es wg. der Priorisierung noch nen Trick gäbe. Im Zweifel muss halt einmalig bei den Clients die Metrik geändert/manuell erfasst werden (betrifft glücklicherweise derzeit nur Win10-Clients und keine Mobilgeräte) und gut ist. Ist halt Aufwand, den ich gerne vermieden hätte, insbesondere auch vor dem Hintergrund, dass man nie weiß, was MS beim nächsten Funktionsupdate wieder anstellt...
Zitat von @137846:
Normalerweise haben VPN Verbindungen per Default immer eine etwas geringere Metrik, da läuft bei dir also was schief.
Wenn du es sauber haben willst stellst du auf die Seite des Clients einen DNS-Server hin (kann auch ein Raspi sein) der im Netz als Default DNS arbeitet und für die interne Domain eine bedingte Weiterleitung enthält der auf den internen DNS Server verweist.
VPN herstellen lässt du am besten zentral dann entweder den Router herstellen oder das den Raspi (oder was auch immer) erledigen, fertsch.
Normalerweise haben VPN Verbindungen per Default immer eine etwas geringere Metrik, da läuft bei dir also was schief.
Wenn du es sauber haben willst stellst du auf die Seite des Clients einen DNS-Server hin (kann auch ein Raspi sein) der im Netz als Default DNS arbeitet und für die interne Domain eine bedingte Weiterleitung enthält der auf den internen DNS Server verweist.
VPN herstellen lässt du am besten zentral dann entweder den Router herstellen oder das den Raspi (oder was auch immer) erledigen, fertsch.
Ja, für den einzelnen wäre das sicher eine Lösung, aber für den DAU dann doch eher etwas überdimensioniert. Ich hatte halt die Hoffnung, dass es wg. der Priorisierung noch nen Trick gäbe. Im Zweifel muss halt einmalig bei den Clients die Metrik geändert/manuell erfasst werden (betrifft glücklicherweise derzeit nur Win10-Clients und keine Mobilgeräte) und gut ist. Ist halt Aufwand, den ich gerne vermieden hätte, insbesondere auch vor dem Hintergrund, dass man nie weiß, was MS beim nächsten Funktionsupdate wieder anstellt...
aber für den DAU dann doch eher etwas überdimensioniert.
Das sollte man etwas differenzierter sehen, denn so ein DNS filtert auch Malware usw, im Heimnetz und macht es eine ganze Ecke sicherer !! Siehe hier:https://www.heise.de/select/ct/2018/11/1526783668168592
Eine simple Flash Karte schreiben und in einen Schlitz zu stecken wie bei einem Fotoapparat sollte auch der blutigste DAU hinbekommen
