drpfiend
Goto Top

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.

Content-Key: 13180552385

Url: https://administrator.de/contentid/13180552385

Printed on: February 21, 2024 at 05:02 o'clock

Member: StefanKittel
StefanKittel Feb 11, 2024 at 14:27:24 (UTC)
Goto Top
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
Member: aqui
aqui Feb 11, 2024 updated at 15:12:22 (UTC)
Goto Top
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. face-sad
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... ­čĄö
Member: DrPfiend
DrPfiend Feb 11, 2024 updated at 17:45:14 (UTC)
Goto Top
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

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.

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)

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. face-sad

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 face-smile )
Member: BlueSkillz
BlueSkillz Feb 11, 2024 at 19:59:08 (UTC)
Goto Top
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.
Member: StefanKittel
StefanKittel Feb 11, 2024 at 20:23:59 (UTC)
Goto Top
Hallo,

Dein Stichwort sollte Split-DNS sein.
für eine URL liefert der interne DNS-Server eine interne IP-Adresse.

Stefan
Member: DrPfiend
DrPfiend Feb 12, 2024 at 20:59:27 (UTC)
Goto Top
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.

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...
bild_2024-02-12_215403656
Member: DivideByZero
DivideByZero Feb 12, 2024 at 21:26:15 (UTC)
Goto Top
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.

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
Member: DrPfiend
DrPfiend Feb 12, 2024 at 21:50:12 (UTC)
Goto Top
Zitat von @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.

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)
Member: aqui
aqui Feb 12, 2024 at 21:57:19 (UTC)
Goto Top
(was auch immer #53 soll)
Oha, wenn es schon an solch' einfachen Basics hapert... face-sad
https://de.wikipedia.org/wiki/Domain_Name_System
(Man achte rechts oben auf die von DNS verwendeten Ports!)
Member: DivideByZero
DivideByZero Feb 12, 2024 at 22:53:29 (UTC)
Goto Top
Name: example.domain (meinhostename der Nextcloud)
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
Member: DrPfiend
DrPfiend Feb 12, 2024 at 22:56:41 (UTC)
Goto Top
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.
log1
bild_2024-02-12_235232550