12
Webserver nicht aus dem LAN zu erreichen (Unifi UDM-Pro)
Hallo liebes Forum, da mir beim Aufbau meines Netzwerks hier schon super geholfen wurde, wende ich mich mit einer erneuten Frage an euch.
Ich betreibe einen Proxmox-Server mit einer Nextcloud und einem nginx-reverse-Proxy. Mein Netzwerk ist in mehrere VLAN´s eingeteilt und geht über ein UDM-Pro und Vigor 165 ins Netz. Im Netzwerk übernimmt ein PiHole mit eigenem VLAN die Rolle des DNS-Servers. Das Routing wird durch einen Cisco SG350X übernommen.
Jetzt zum Problem: Meine Nextcloudinstanz erreiche ich ohne Probleme aus jedem berechtigten VLAN über die IP. Steuere ich aber direkt den Server an, erhalte ich den Fehler "Die Webseite ist nicht erreichbar, hat zu lange gedauert... Err_Connection_Timed_OUT". Gehe ich über die Mobilen Daten auf die Adresse meines DYNDNSS-Server klappt die Verbindung ohne Probleme. (SSL mit Lets enrycpt)
In der UDM Pro sind die benötigten Ports freigegeben, (443 und 83) im PiHole habe ich bereits versucht die Webserveradresse zu hinterlegen. Leider alles ohne Erfolg.
nslookup homeserver.de liefert:
Server: one.one.one.one
Adress: 1.1.1.1
Nicht autorisierende Antwort
Name: homeserver.de
Adresse: Meine Public IP
tracert homeserver.de
Routenverfolgung über das Gateway meines VLANS zur PublicIP 2 Hops
Ich habe das Gefühl, das etwas mit dem DNS (DoubleNAT) nicht stimmt, habe aber keine Ahnung, wo der Fehler sitzt? Das PiHole ist im Cisco als DNS hinterlegt, der Unify hat keinen definiert. (klappt auch nicht, wenn dort auf die IP des PiHole verwiesen wird). Es ist zudem unerheblich, ob der Webserver via http oder https als ProxyHost eingerichtet und angefragt wird. Zugriff von extern klappt, aus dem LAN nicht.
Ich betreibe einen Proxmox-Server mit einer Nextcloud und einem nginx-reverse-Proxy. Mein Netzwerk ist in mehrere VLAN´s eingeteilt und geht über ein UDM-Pro und Vigor 165 ins Netz. Im Netzwerk übernimmt ein PiHole mit eigenem VLAN die Rolle des DNS-Servers. Das Routing wird durch einen Cisco SG350X übernommen.
Jetzt zum Problem: Meine Nextcloudinstanz erreiche ich ohne Probleme aus jedem berechtigten VLAN über die IP. Steuere ich aber direkt den Server an, erhalte ich den Fehler "Die Webseite ist nicht erreichbar, hat zu lange gedauert... Err_Connection_Timed_OUT". Gehe ich über die Mobilen Daten auf die Adresse meines DYNDNSS-Server klappt die Verbindung ohne Probleme. (SSL mit Lets enrycpt)
In der UDM Pro sind die benötigten Ports freigegeben, (443 und 83) im PiHole habe ich bereits versucht die Webserveradresse zu hinterlegen. Leider alles ohne Erfolg.
nslookup homeserver.de liefert:
Server: one.one.one.one
Adress: 1.1.1.1
Nicht autorisierende Antwort
Name: homeserver.de
Adresse: Meine Public IP
tracert homeserver.de
Routenverfolgung über das Gateway meines VLANS zur PublicIP 2 Hops
Ich habe das Gefühl, das etwas mit dem DNS (DoubleNAT) nicht stimmt, habe aber keine Ahnung, wo der Fehler sitzt? Das PiHole ist im Cisco als DNS hinterlegt, der Unify hat keinen definiert. (klappt auch nicht, wenn dort auf die IP des PiHole verwiesen wird). Es ist zudem unerheblich, ob der Webserver via http oder https als ProxyHost eingerichtet und angefragt wird. Zugriff von extern klappt, aus dem LAN nicht.
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: 13180552385
Url: https://administrator.de/contentid/13180552385
Ausgedruckt am: 21.11.2024 um 16:11 Uhr
12 Kommentare
Neuester Kommentar
Moin,
wo kommt denn die 1.1.1.1 her?
Das ist eine IP-Adresse von Cloudflare und keine die man im privaten Netzwerk nutzen darf/kann.
Möglicherweise deshalb schickt der Router die Daten falsch durch die Gegend.
Stefan
wo kommt denn die 1.1.1.1 her?
Das ist eine IP-Adresse von Cloudflare und keine die man im privaten Netzwerk nutzen darf/kann.
Möglicherweise deshalb schickt der Router die Daten falsch durch die Gegend.
Stefan
Der Satz: "Meine Nextcloudinstanz erreiche ich ohne Probleme aus jedem berechtigten VLAN über die IP. Steuere ich aber direkt den Server an, erhalte ich den Fehler" ist ja auch ein Widerspruch in sich.
"Direkt" steuert man den Server ja auch aus jedem berechtigten VLAN und insbesondere dem gleichen VLAN das den Server beheimatet an?! Lokale IP Adresse im Browser angeben...fertisch. Direkter gehts ja eigentlich nicht mehr?! 🤔
Mit der recht wirren Beschreibung meint der TO vermutlich das er lokal eine andere DNS Auflösung der Server IP Adresse bekommt als extern. Oder was auch immer mit der kryptischen Beschreibung insbesondere auch den falschen IPs gemeint ist! (1.1.1.1 ist bekanntlich die IP eines Cloudflare DNS Servers)
Hört sich also eher nach einer Hairpin NAT Problematik an aber ob der Beschreibung kann man auch hier wieder nur kristallkugeln.
Und wieso auch "double NAT" wenn nur die UDM Gurke NAT macht?? Der Cisco L3 Switch kann es in einem L3 Switchdesign was der TO ja betreibt gar nicht und ein reines NUR Modem wie der Vigor kann gar kein Routing geschweige denn NAT?! Es kann also ganz ohne Router Kaskade nur single NAT geben?!
Viele ungelöste Fragezeichen also... 🤔
"Direkt" steuert man den Server ja auch aus jedem berechtigten VLAN und insbesondere dem gleichen VLAN das den Server beheimatet an?! Lokale IP Adresse im Browser angeben...fertisch. Direkter gehts ja eigentlich nicht mehr?! 🤔
Mit der recht wirren Beschreibung meint der TO vermutlich das er lokal eine andere DNS Auflösung der Server IP Adresse bekommt als extern. Oder was auch immer mit der kryptischen Beschreibung insbesondere auch den falschen IPs gemeint ist! (1.1.1.1 ist bekanntlich die IP eines Cloudflare DNS Servers)
Hört sich also eher nach einer Hairpin NAT Problematik an aber ob der Beschreibung kann man auch hier wieder nur kristallkugeln.
Und wieso auch "double NAT" wenn nur die UDM Gurke NAT macht?? Der Cisco L3 Switch kann es in einem L3 Switchdesign was der TO ja betreibt gar nicht und ein reines NUR Modem wie der Vigor kann gar kein Routing geschweige denn NAT?! Es kann also ganz ohne Router Kaskade nur single NAT geben?!
Viele ungelöste Fragezeichen also... 🤔
Zitat von @StefanKittel
Moin, wo kommt denn die 1.1.1.1 her? Das ist eine IP-Adresse von Cloudflare und keine die man im privaten Netzwerk nutzen darf/kann. Möglicherweise deshalb schickt der Router die Daten falsch durch die Gegend. Stefan
Moin, wo kommt denn die 1.1.1.1 her? Das ist eine IP-Adresse von Cloudflare und keine die man im privaten Netzwerk nutzen darf/kann. Möglicherweise deshalb schickt der Router die Daten falsch durch die Gegend. Stefan
Kann das ein Schutz von dem Reverse-Proxy sein?
In meinem PiHole ist Cloudflare (DNSSEC) als Upstream DNS Server für IPv4 gesetzt. Dort habe ich auch bei
"List of local CNAME records" die Domains meines Servers auf eine Target (Die IP des Containers) gesetzt.
Zitat von @aqui:
Der Satz: "Meine Nextcloudinstanz erreiche ich ohne Probleme aus jedem berechtigten VLAN über die IP. Steuere ich aber direkt den Server an, erhalte ich den Fehler" ist ja auch ein Widerspruch in sich.
Der Satz: "Meine Nextcloudinstanz erreiche ich ohne Probleme aus jedem berechtigten VLAN über die IP. Steuere ich aber direkt den Server an, erhalte ich den Fehler" ist ja auch ein Widerspruch in sich.
Stimmt. Also die direkte Ansteuerung (über die IP-Adresse des LXC) aus dem LAN klappt, über den vHostnamen des DynDNS-Service bekomme ich aber o.g. Fehler. Externer Zugriff vice versa (so wie es sein soll). Die Ansteuerung brauche ich aber für die App über den Hostnamen und zwar aus dem heimischen LAN und von außerhalb.
Zitat von @aqui:
Mit der recht wirren Beschreibung meint der TO vermutlich das er lokal eine andere DNS Auflösung der Server IP Adresse bekommt als extern. Oder was auch immer mit der kryptischen Beschreibung insbesondere auch den falschen IPs gemeint ist! (1.1.1.1 ist bekanntlich die IP eines Cloudflare DNS Servers)
Mit der recht wirren Beschreibung meint der TO vermutlich das er lokal eine andere DNS Auflösung der Server IP Adresse bekommt als extern. Oder was auch immer mit der kryptischen Beschreibung insbesondere auch den falschen IPs gemeint ist! (1.1.1.1 ist bekanntlich die IP eines Cloudflare DNS Servers)
Die 1.1.1.1 habe ich nur als sekundären DNS-Server im Cisco eingetragen. Ich bin mir hier über den Fehler leider nicht bewusst.
Zitat von @aqui:
Hört sich also eher nach einer Hairpin NAT Problematik an aber ob der Beschreibung kann man auch hier wieder nur kristallkugeln.
Hört sich also eher nach einer Hairpin NAT Problematik an aber ob der Beschreibung kann man auch hier wieder nur kristallkugeln.
Wie kann ich herausfinden, dass es daran liegt?
Zitat von @aqui:
Und wieso auch "double NAT" wenn nur die UDM Gurke NAT macht?? Der Cisco L3 Switch kann es in einem L3 Switchdesign was der TO ja betreibt gar nicht und ein reines NUR Modem wie der Vigor kann gar kein Routing geschweige denn NAT?! Es kann also ganz ohne Router Kaskade nur single NAT geben?!
Viele ungelöste Fragezeichen also... 🤔
Stimmt, dann kann es das nicht sein. (Die mehrheitliche Haltung zu Unifi-Geräten kenne ich hier Und wieso auch "double NAT" wenn nur die UDM Gurke NAT macht?? Der Cisco L3 Switch kann es in einem L3 Switchdesign was der TO ja betreibt gar nicht und ein reines NUR Modem wie der Vigor kann gar kein Routing geschweige denn NAT?! Es kann also ganz ohne Router Kaskade nur single NAT geben?!
Viele ungelöste Fragezeichen also... 🤔
)
Moin,
also das Problem wird sein, dass du vom internen Netz über deine öffentliche IP auf deine öffentliche IP zugreifen möchtest.
Das funktioniert in der Regel nicht ohne weitere Konfiguration.
Also du hast zwei Möglichkeiten:
1. Du hinterlegst in dem Pihole für den Domänen-Namen für die Nextcloud die private IP-Adresse von dem Webserver, dann solltest du da auch ohne Probleme zugreifen können.
2. Du erstellst eine Loopback-Regel, wodurch deine private IP durch die öffentliche IP ersetzt wird usw. (Gibt dazu viele Anleitungen im Netz.
Die gängige Möglichkeit wäre die zweite Möglichkeit, aber beide sollten funktionieren.
also das Problem wird sein, dass du vom internen Netz über deine öffentliche IP auf deine öffentliche IP zugreifen möchtest.
Das funktioniert in der Regel nicht ohne weitere Konfiguration.
Also du hast zwei Möglichkeiten:
1. Du hinterlegst in dem Pihole für den Domänen-Namen für die Nextcloud die private IP-Adresse von dem Webserver, dann solltest du da auch ohne Probleme zugreifen können.
2. Du erstellst eine Loopback-Regel, wodurch deine private IP durch die öffentliche IP ersetzt wird usw. (Gibt dazu viele Anleitungen im Netz.
Die gängige Möglichkeit wäre die zweite Möglichkeit, aber beide sollten funktionieren.
Hallo,
Dein Stichwort sollte Split-DNS sein.
für eine URL liefert der interne DNS-Server eine interne IP-Adresse.
Stefan
Dein Stichwort sollte Split-DNS sein.
für eine URL liefert der interne DNS-Server eine interne IP-Adresse.
Stefan
Zitat von @BlueSkillz:
Moin,
also das Problem wird sein, dass du vom internen Netz über deine öffentliche IP auf deine öffentliche IP zugreifen möchtest.
Das funktioniert in der Regel nicht ohne weitere Konfiguration.
Also du hast zwei Möglichkeiten:
1. Du hinterlegst in dem Pihole für den Domänen-Namen für die Nextcloud die private IP-Adresse von dem Webserver, dann solltest du da auch ohne Probleme zugreifen können.
2. Du erstellst eine Loopback-Regel, wodurch deine private IP durch die öffentliche IP ersetzt wird usw. (Gibt dazu viele Anleitungen im Netz.
Die gängige Möglichkeit wäre die zweite Möglichkeit, aber beide sollten funktionieren.
Moin,
also das Problem wird sein, dass du vom internen Netz über deine öffentliche IP auf deine öffentliche IP zugreifen möchtest.
Das funktioniert in der Regel nicht ohne weitere Konfiguration.
Also du hast zwei Möglichkeiten:
1. Du hinterlegst in dem Pihole für den Domänen-Namen für die Nextcloud die private IP-Adresse von dem Webserver, dann solltest du da auch ohne Probleme zugreifen können.
2. Du erstellst eine Loopback-Regel, wodurch deine private IP durch die öffentliche IP ersetzt wird usw. (Gibt dazu viele Anleitungen im Netz.
Die gängige Möglichkeit wäre die zweite Möglichkeit, aber beide sollten funktionieren.
Danke für die Hinweise. Die Domain-Namen in dem PiHole zu hinterlegen klappt leider nicht. Ich habe diese jeweils versucht als DNS records als auch unter CNAME hinzuzufügen. Die 172.16.60.50 ist mein nginx.
Ich komme leider mit der Loopback Regel in der Unifi UDM PRo nicht weiter. Ich weiß ehrlich gesagt nicht was ich dort einstellen muss, trotz vieler Suchen. Bisher ist dort die Regel Portforwarding 80 443 und 465 auf die jeweiligen Ports des nginx gesetzt. Unifi sagt dass die Loopback Nat Regeln selbstständig erstellt werden...
Zitat von @DrPfiend:
Danke für die Hinweise. Die Domain-Namen in dem PiHole zu hinterlegen klappt leider nicht. Ich habe diese jeweils versucht als DNS records als auch unter CNAME hinzuzufügen.
Danke für die Hinweise. Die Domain-Namen in dem PiHole zu hinterlegen klappt leider nicht. Ich habe diese jeweils versucht als DNS records als auch unter CNAME hinzuzufügen.
Was bedeutet das konkret? Du hast sie eingetragen (als DNS record), und dann?
Was sagt denn dann "nslookup meinhostname IP"?
meinhostname=Der Hostname im DNS des PiHole
IP = IP des PiHole
Hast Du so mal getestet, was der PiHole jeweils bei Direktbafrage zurückliefert?
Gruß
DivideByZero
Zitat von @DivideByZero:
Was bedeutet das konkret? Du hast sie eingetragen (als DNS record), und dann?
Was sagt denn dann "nslookup meinhostname IP"?
meinhostname=Der Hostname im DNS des PiHole
IP = IP des PiHole
Hast Du so mal getestet, was der PiHole jeweils bei Direktbafrage zurückliefert?
Gruß
DivideByZero
Zitat von @DrPfiend:
Danke für die Hinweise. Die Domain-Namen in dem PiHole zu hinterlegen klappt leider nicht. Ich habe diese jeweils versucht als DNS records als auch unter CNAME hinzuzufügen.
Danke für die Hinweise. Die Domain-Namen in dem PiHole zu hinterlegen klappt leider nicht. Ich habe diese jeweils versucht als DNS records als auch unter CNAME hinzuzufügen.
Was bedeutet das konkret? Du hast sie eingetragen (als DNS record), und dann?
Was sagt denn dann "nslookup meinhostname IP"?
meinhostname=Der Hostname im DNS des PiHole
IP = IP des PiHole
Hast Du so mal getestet, was der PiHole jeweils bei Direktbafrage zurückliefert?
Gruß
DivideByZero
Ich habe über SSH des PiHole die Anfrage geschickt und erhalte:
Server: 172.16.2.3 (PiHole)
Address: 172.16.2.3 #53 (was auch immer #53 soll)
Name: example.domain (meinhostename der Nextcloud)
Address: 172.16.60.50 (nginx-IP)
(was auch immer #53 soll)
Oha, wenn es schon an solch' einfachen Basics hapert... https://de.wikipedia.org/wiki/Domain_Name_System
(Man achte rechts oben auf die von DNS verwendeten Ports!)
1Name: example.domain (meinhostename der Nextcloud)
Address: 172.16.60.50 (nginx-IP)
Address: 172.16.60.50 (nginx-IP)
Dann ist an diesem Punkt doch alles perfekt. PiHole läuft, macht, was es soll. Also hast Du ein Problem mit der Zuweisung der Nameserver bei den Clients. Die fragen eben nicht den PiHole ab, sondern - wahrscheinlich - externe Server im Internet, und nichts lokales. Und da kommt dann natürlich auf die Abfrage von example.domain die öffentliche IP.
Also im Netz ansetzen und schauen, was Du da wie an Nameservern verteilst.
Wie überhaupt? Per DHCP? Dann dürfte da etwas falsch konfiguriert sein.
Nimm mal einen der Clients, wo es nicht lief, konfiguriere den statisch und setze statisch als (einzigen) Nameserver die 172.16.2.3. Dann sollte es an dem Client laufen (dort dann eben auch mit nslookup, dann aber ohne angegebenen Nameserver testen).
Gruß
DivideByZero
1
Was mir noch aufgefallen ist, dass im PiHole folgende Fehlermeldung mit zugehörigem Log erscheint:
172.16.1.1 ist meine UDM-Pro. Ping zwischen den Geräten (PiHole <-> UDM <-> Clients) ist problemlos möglich, und der PiHole funktioniert auch mit allen Geräten innerhalb des lokalen Netzwerks einwandfrei.
172.16.1.1 ist meine UDM-Pro. Ping zwischen den Geräten (PiHole <-> UDM <-> Clients) ist problemlos möglich, und der PiHole funktioniert auch mit allen Geräten innerhalb des lokalen Netzwerks einwandfrei.
1
Wenn es das denn nun war:
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
