[GELÖST] OwnCloud intern über externen Hostnamen erreichen?

[r.weber]

Hallo,

ich habe gerade folgende Situation:
Ich betreibe einen OwnCloud Server im internen LAN (192.168.1.100) mit einem statischen DNS Eintrag owncloud.intern.lan in der OPNsense. Soweit so gut. Bei meinem Provider habe ich ebenfalls einen Hosteintrag erstellt owncloud.domain.tld mit meiner externen IP. Auf der OPNsense ist ein Portforwarding "WAN address" "https" auf die 192.168.1.100 eingerichtet. Auch das funktioniert, allerdings nur von ausserhalb meines internes LANs.

Jetzt zu meinem Problem:
Wie schaffe ich es, dass ich auch vom internen LAN meinen OwnCloud Server über owncloud.domain.tld erreichen kann?

Wenn ich aus dem internen LAN versuche owncloud.domain.tld aufzurufen, dann löst mein Client zwar den DNS Namen mit meiner externen IP Adresse auf, aber es findet ja kein forwarding der Pakete statt, da die ja von der LAN Schnittstelle kommen. Ein generelles https forwarding an der LAN Schnittstelle will ich aber auch nicht, sondern nur für https://owncloud.domain.tld. Bin mir nicht mal sicher ob das überhaupt funktionieren würde.

Habe es auch schon versucht im DNS einen alias einzurichten, aber durch das cachen der Clients dauert das ewig, bis die das mitbekommen würden. Hat jedenfalls nicht geklappt.

Hat noch jemand eine Idee?

Grüße
Ralf

[franco]

Hi Ralf,

Wird leider nicht viel anders funktionieren als mit DNS Overrides im Forwarder/Resolver. Alternativ könnte man die Domain des internen Netzwerkes auch auf "domain.tld" anstelle "intern.lan" setzen, dann kann man über Static DHCP Leases "automatisch" den Namen korrekt auflösen für alle internen Clients.


Gruss
Franco

[Zeitkind]

Das is ein altes Problem. Je nach Firewall funktiert das mal - und mal nicht. Wenn du von intern eine externe IP aufrufst, die wieder "zurückge-NAT-et" wird, landet das meist im Nirvana. Das Problem hast du btw. auch, wenn du eine DMZ-Zone einrichtest, und dein Server in der DMZ-Zone zwar die z.B. 10.0.0.10, aber laut (offiziellem) DNS der Server die 234.56.23.12 hat. Die Firewall müßte dann die Pakete erst nach draußen auf die WAN-Schnittstelle 234.56.23.12 bringen und dann wieder zurück über eine NAT-Regel ins DMZ.
https://doc.pfsense.org/index.php/Why_can't_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks
Die IMHO beste Lösung in diesem Fall: Nicht die externe Adresse/DNS-Name aufrufen sondern direkt die 10.0.0.10. Wenn man den "echten" Namen verwenden will, muss der interne DNS entweder die 10.0.0.10 statt der 234.56.23.12 zurückgeben (split DNS) oder man verändert lokal am stationären Rechner die host-Datei.

[r.weber]

Ok. Soweit so gut.

Aber wie bekomme ich den "DNS Resolver" dazu, bei Anfragen von Clients die unter "Overrides" eingetragene interne IP zurückzugeben und nicht die, die meinem Provider für den A-Eintrag eingetragen ist?

Wobei ich es komisch finde. Mache ich ein ping auf den FQDN meines OwnCloud Servers, dann geht der ping auf die WAN Adresse (Provider Eintrag), mache ich aber ein nslookup/dig bekomme ich vom DNS Server die richtige interne Adresse geliefert. Versteht das einer und kann mir das erklären?

[r.weber]

Kleines Update

Es geht jetzt, aber ich verstehe noch nicht warum.

Ich habe einzig zwei Änderungen in System => Firewall/NAT gemacht (siehe Screenshot):
1. Reflection for port forwards: von Disable auf Enable (Pure NAT) umgestellt
2. Enable automatic outbound NAT for Reflection: Checkbox angehakt

und voila, ich kann jetzt meinen OwnCloud Server unter dem selben FQDN sowohl von extern, wie auch intern erreichen.

Vielleicht kann mir jemand noch die Auswirkung dieser Optionen erklären?

[Zeitkind]

Naja, für dich wird es keine Auswirkungen haben.
Generell macht man das ungerne, da unnötig NAT involviert wird - wo eigentlich reines Routing (DMZ) oder gar kein Router (Ziel steht im gleichen LAN) nötig wäre. Man schickt also Pakete unnötigerweise durch eine Paketverarbeitung einer Firewall (und belastet sie damit), obwohl man es direkt oder durch einfaches Routing auch haben könnte. Je nach Anwendungsfall ist das weniger tragisch oder eben auch mal voll daneben, da bei viel Traffic die Firewall in die Knie geht. Deshalb wird i.d.R. in Firmennetzen ein Split-DNS verwendet oder eine andere Lösung gesucht (multihomed Server usw.).

[r.weber]

Deshalb wird i.d.R. in Firmennetzen ein Split-DNS verwendet oder eine andere Lösung gesucht (multihomed Server usw.).

Da stimme ich Dir voll und ganz zu. Wenn es sich bei mir nicht um einen privaten Anwendungsfall handeln würde, wäre mir reines routing auch lieber. Aber die reine routing Geschichte habe ich irgendwie nicht hinbekommen. Und für zu Hause nur wegen OwnCloud ein Split-DNS aufzubauen erschien mir etwas zu viel des guten (obwohl es meinem IT-Ruf entsprechen würde: Mit Kanonen auf Spatzen zu schiessen  )

Aber die NAT Geschichte funktioniert und meine Familie ist Glücklich endlich von überall mal schnell an Daten zu kommen. (Ist doch schon komisch, wenn die Familie mal einen Nutzen aus meinen "Spinnereien" ziehen konnte ist es auf einmal toll)