Wie internen Server über einen Domain von intern und extern erreichen?

[Domi_bas]

Hallo,

hoffe ich bin hier richtig, bin mir nicht sicher... habe leider keine passenden Beiträge für mein Problem gefunden, steht hier einfach auf dem Schlauch, schon seit 2 Tagen.

Das Netzwerk sieht folgendermaßen aus:
192.168.178.1 = Gateway1 (VDSL50)
192.168.178.2 = DNS Server (win2012)
192.168.178.10 = Gateway2 (DSL16k als Backup)
192.168.178.20 = Ubuntu Server 14 LTS (Webserver mit LAMPP)

Möchte folgendes Erreichen:
Die Domain example.tld ist bei Strato per DNS (A) Eintrag auf die statische IP des GW1 gerichtet. Dort habe ich eine Portweiterleitung für den Port 443 (https) auf die ip 192.168.178.20 eingestellt. Vom Handy kann ich nun die Seite unter example.tld erreichen. Möchte jetzt aber auch von intern den Server über die https://example.tld erreichen.
Mir ist aber wichtig, dabei quasi nicht "das Haus zu verlassen", da ich anhand der REMOTE_ADDR in php die Seite dann unterschiedlich aussehen lassen möchte. Soll quasi den "unsicheren" Login ersetzen.
Habe dafür im DNS-Server (...2) einen eintrag in die forward-lookupzonen erstellt, der auf die ip ...20 zeigt. Kann diese Domain auch im Netzwerk anpingen oder per smb auf die ...20 zugreifen, klappt alles wie es soll.

Leider komme ich aber per https://example.tld von intern nicht auf den Server, erhalte immer Fehlermeldung im Firefox, "Fehler Netzwerk Zeitüberschreitung".

Wenn ich nun das Gateway 2 bei mir einstelle, komme ich auf den Server. Wenn ich mir dann auf der Website dort meine ip anzeigen lasse (php: echo $_SERVER['REMOTE_ADDR']; ), ist es nicht eine aus dem Netzwerk, sondern die des Backup-DSL-Anschlusses zum Internet.


Meine Fragen:
- warum behandelt der DNS-Server https scheinbar anders als smb oder z.b. ping?
- wie löst man sowas "richtig", habe ich grundsätzlich einen Fehler?

Danke für eure Antworten !!!

 

[^Dodo.bW]

Kann dir nicht sagen, ob das best practice ist, wir haben das hier aber folgender maßen gelöst:

anlegen einer forward-lookupzone example.tld
anlegen eines Host-A Eintrages "www" mit der IP des Servers (unter der neuen lookupzone)

gibst du nun im Brwoser www.example.tld ein kommst du direkt am server raus. bei uns wird example.tld auch auf www.example.tld redirected. weiß gerade nicht ob das eine extra einstellung am webserver ist.

//PS: DNS-Auflösung hat erstmal nicht mit dem verwendeten Protokoll (HTTP, HTTPS) zu tun. das dürfte für die AUflösung irrelevant sein. Was kommt denn raus, wenn du über cmd nslookup example.tld/www.example.tld machst?

 

[Domi83]

Der Dodo.bW hat es eigentlich sehr gut erklärt... Du musst dem primären DNS bei euch im Büro / Gebäude etc. sagen das Anfragen an domain.tld direkt nach 192.168.178.20 geschickt werden (der erwähnte A Eintrag) und dann sollte es schon passen. Wenn der DNS diese nicht kennt, schickt er natürlich alle Anfrage über den DSL Anschluss raus und holt sich dort die IP Adresse der Domain und so kommt ihr dann wieder zurück zu euch ins Büro. Resultat hast du ja gesehen, in der Variable $_SERVER['REMOTE_ADDR'] steht dann die WAN IP von einem der DSL Anschlüsse.

Bei einem Kunden von mir existiert ein ähnliches Szenario... Domain liegt beim Domain-Reseller, die A Records zeigen auf die statische IP des DSL Anschlusses, im Router sind Port 80 und 443 zum passenden Endpunkt weitergeleitet und somit kommen die Leute auf die Domain. Der DNS bei dem Kunden im Haus hat die Information bekommen, dass er die Domain gleich haus-intern zu der IP Adresse weiterleiten kann.

Wichtig wäre noch (hoffe ich irre mich da jetzt nicht), dass auf dem Ubuntu-Server in der Konfig des Webservers drin steht, dass er Domain-Anfrage über alle IPs akzeptiert. Wenn ihr sagt das domain.tld nur auf 192.168.178.20:80 oder 192.168.178.20:443 reagieren darf, könntet ihr sie noch vom Internet erreichen, genauso umgekehrt.

Gruß, Domi

 

[Renegade334]

Der Dodo.bW hat es eigentlich sehr gut erklärt... Du musst dem primären DNS bei euch im Büro / Gebäude etc. sagen das Anfragen an domain.tld direkt nach 192.168.178.20 geschickt werden (der erwähnte A Eintrag) und dann sollte es schon passen.

Sollte der nicht eher auf die 192.168.178.1 zeigen? Von da wird er ja dann per Weiterleitung auf die 20 umgeleitet. Wenn noch mehr Services auf anderen Servern eingerichtet werden, laufen die ja sonst im Internen Netzwerk ins Leere.

 

[konkretor]

das was du suchst nennt sich split dns

http://www.medic-daniel.de/microsoft-window-server/2012/10/split-dns-split-brain-fluch-oder-segen

 

[Raijin]

Prinzipiell ist der Ansatz über den DNS der optimale Weg. @Renegade: Nein. Es geht ja gerade darum, dass man bei Eingabe der eigentlich externen URL innerhalb des lokalen Netzwerks bleibt und statt über den Router direkt auf dem Zielgerät landet. Das was du vielleicht im Hinterkopf hast, ist NAT-hairpin bzw. NAT-loopback.

Bei NAT-harpin bzw. -loopback merkt der Internetrouter selbst, dass die Ziel-IP ja seine eigene WAN-IP ist. Dann dreht er den Traffic quasi im WAN-Port um - und leitet ihn durch die komplette NAT- bzw. Firewall-Pipeline. Das geht prinzipiell auch, aber dann läuft der Traffic eben so:

Client ---LAN---> Router (WAN) <--loopback--> (WAN) Router ---LAN---> Server

Dabei wird jedes Paket diesen Umweg nehmen.

Wenn man stattdessen wie hier ja angestrebt wird den DNS-Server dazu bewegt, bei der vermeintlich externen Domain gar nicht erst eine WAN-IP zurückzugeben, sondern stattdessen direkt die lokale LAN-IP des Servers, liefe das so:

Client --LAN--> Server

Der Router bzw. DNS würde dabei ausschließlich einmalig den DNS-Request sehen und an der eigentlichen Verbindung gar nicht beteiligt sein.

 

[DeusoftheWired]

Sollte der nicht eher auf die 192.168.178.1 zeigen? Von da wird er ja dann per Weiterleitung auf die 20 umgeleitet.

Aber nur, wenn man von außen kommt. Internen kann man ja gleich die richtige IP 192.168.178.20 sagen, ohne sie den Umweg über die .1 nehmen zu lassen.

 

[h00bi]

Wie du es intern lösen kannst weiß du ja jetzt, passende Konfig auf dem DNS.
Hast du auch schon einen Plan was du machst wenn das Gateway1 ausfällt sodass der Server über Gateway2 von außen erreichbar bleibt?

 

[Raijin]

Je nachdem wie Gateway1 und 2 überhaupt genutzt werden sollen, bietet sich in solchen Situationen auch ein Multi-WAN-Router an, der sich potentiell um LoadBalancing, Fallback und dergleichen kümmert. Provider-Router sind für solche Zwecke meist ungeeignet bzw. man muss sich dann eben irgendeine gefrickelte Lösung einfallen lassen.

 

[h00bi]

Der Multi-WAN Router kann aber nicht die auf example.tld hinterlegte public-IP-Adresse ändern, sodass example.tld auf Gateway2 landet. Und selbst wenn hilft das auch erst dann wenn die Gegenstelle den DNS nach Ablauf der TTL neu angefragt hat, vorher ist der Server nicht erreichbar.

Ich suche nämlich auch schon lange genau dafür eine Lösung... die einzige praktikable Lösung ist aktuell massiv Geld in eine möglichst ausfallsichere Hauptleitung zu pumpen.

 

[^Dodo.bW]

Der Multi-WAN Router kann aber nicht die auf example.tld hinterlegte public-IP-Adresse ändern, sodass example.tld auf Gateway2 landet. Und selbst wenn hilft das auch erst dann wenn die Gegenstelle den DNS nach Ablauf der TTL neu angefragt hat, vorher ist der Server nicht erreichbar.

Ich suche nämlich auch schon lange genau dafür eine Lösung... die einzige praktikable Lösung ist aktuell massiv Geld in eine möglichst ausfallsichere Hauptleitung zu pumpen.

Denke, was ihr sucht ist das round-robin-Prinzip, normalerweise für failover-webserver gedacht, würde sich aber auch zweckentfremden lassen, um über zwei Leitungen mit unterschiedlicher öffentlicher IP auf den selben Webserver zu verweisen: https://www.stsoftware.com.au/site/ST/blog/article/how-to-configure-load-balancer/

 

[Renegade334]

Aber nur, wenn man von außen kommt. Internen kann man ja gleich die richtige IP 192.168.178.20 sagen, ohne sie den Umweg über die .1 nehmen zu lassen.

Der Gedanke war halt, wenn man mehrere Dienste im Internen Netz hat die man über die externe Domain erreichen kann, die aber intern auf verschiedenen Server liegen. Dann wäre es nicht so toll, dass man immer auf die 192.168.178.20 umgeleitet wird, wenn der 2. Service (z.B. Mail) vielleicht auf der 192.168.178.21 liegt.
Wenn man aber immer auf die 192.168.178.1 geleitet wird, leitet die einen ja automatisch passend an die 192.168.178.20 oder 192.168.178.21 weiter. Und man bleibt trotzdem im internen Netzwerk.

Solange aber alle Dienste auf der gleichen IP intern laufen, ist das nicht wichtig...

 

[Raijin]

DNS round robin ist in dem Falle aber nicht gut geeignet. Man sagt dem DNS zwar, daß eine Domain zB zwei IPs hat, aber man hat keine Kontrolle darüber welche tatsächlich genutzt wird. Jeder DNS Request kann eine andere IP zurückgeben und wenn's dumm läuft wird die vermeintliche Fallback-IP zur Haupt-IP, weil durch den round robin Zufall quasi 20 Leute IP#2 bekommen haben und nur 3 Leute die eigentliche Haupt-IP#1. Eine Priorisierung ist schlicht und ergreifend nicht vorgesehen.

Man könnte aber mit Scripts tricksen. Im Hintergrund werden WAN#1 und WAN#2 geprüft und sobald WAN#1 down geht wird ein DDNS-Update für WAN#2 gestartet. Sobald WAN#1 wieder online ist, wird DDNS wieder auf WAN#1 gesetzt.

 

[Domi_bas]

Wow viele und schnelle Antworten, Danke.
Musste gestern fluchtartig das Büro verlassen, Kinder krank...

Das ganze dient dazu eine intern genutzte Software (php/mysql) unter der angegebenen Adresse zu erreichen, da sich unsere Mitarbeiter keine ips merken können
Jetzt soll ein Teil dieser Software für eine Hand voll Kunden zugänglich sein, daher der externe Zugriff.

Da bin ich schon mal froh, dass ich nicht ganz falsch unterwegs war.


@h00bi und nachfolgende: Die Backupleitung ist für andere Zwecke, sollte VDSL mal ausfallen, is halt Ruhe am Server...

Zum Thema: Werde mir die ganze Konfiguration im Büro nochmal ansehen, bin nun ja bestätigt, dass ich es theoretisch richtig mache.

 

[Raijin]

Wie verfügbar muss das denn sein? Es klingt irgendwie nicht so nach super duper wichtig und hoch verfügbar. Zur Not kann man DNS auch händisch aktualisieren, wenn die eine Leitung mal ausfällt.

Je nach Software kann man evtl auch dort ansetzen und einen alternativen Server hinzufügen. Dann verbindet sich der Client eben standardmäßig mit IP#1 und wenn da ein timeout kommt, wird IP#2 versucht.