Verständnisfrage: Gekaufte Domain auf lokalen Webserver zeigen lassen

[FAN4TIC]

Hallo Community,

ich beschäftige mich seit kurzem mit der Funktionsweise von Netzwerken und co. und versuche derzeit zu verstehen, wie ich eine URL auf meinen lokalen Webserver zeigen lassen kann. Angenommen folgendes Setup existiert um den Webserver herum:

Gateway:
Linux Kiste mit 3 NICs,
Läuft DNS (bind9), DHCP (isc-dhcpd), NAT (nftables)
-> eth0: WAN (angenommen, die IP ist statisch)
-> eth1: Subnetz 1 (192.168.1.0/24) -> Clients mit dynamische IPs
-> eth2: Subnetz 2 (192.168.3.0/24) -> (Web-) Server mit statische IPs

Der Webserver ist in diesem Beispiel ein einfacher Apache und hat die IP 192.168.3.50 und hört auf Port 8000


Was ich bis jetzt verstanden hab:
- Ich kaufe eine Domain bei einem Anbieter und ergänze meine öffentliche IP in deren DNS.
- Jetzt werden alle Besucher der Webseite auf meine öffentliche IP weitergeleitet und landen beim Router.
- Die eingehende Verbindung muss vom Router auf die lokale IP & Port des Webserver weitergeleitet werden, damit die Webseite angezeigt wird.

Ich vermute, dass ich mein nftables um eine Regel ergänzen muss, bspw. sowas:

nft add rule nat prerouting iif eth0 tcp dport 80 dnat 192.168.3.50

Was ich nicht verstanden hab:
- Wie / an welcher Stelle wird der Port des Webservers ergänzt ?
Die nftables Route wird bei einer eingehenden Verbindung, die den Port 80 enthält, ausgelöst. Beim Domain-Anbieter trage ich ja eigentlich keinen Port ein (oder doch?).


Danke für die Aufklärung


VG

 

[PUNK2018]

Der Port wird bei deinem Router eingetragen... die Webanfrage wird ja über Port80 laufen, dein Router muss diesen dann auf 8000 umleiten

Keinen täglichen IP Wechsel durch den Provider?

 

[razzy]

leite die Ports 80 für http sowie 443 https auf die Ports deines Webservers im Router um. Jenachdem auf welchen Port du den http/s server "horchen" lässt

 

[Wilhelm14]

WAN (angenommen, die IP ist statisch)

Zu deinen konkreten Fragen kann ich nichts sagen, aber bei dynamischer IP kann man bei manchen Hostern DynDNS nutzen. Konkret kann man bei Strato schlicht eine Domain ohne alles kaufen und diese auf den Router zeigen lassen. In Fritzboxen trägt man eben Strato als DnyDNS-Anbieter ein, siehe: https://www.strato.de/faq/article/671/So-einfach-richten-Sie-DynDNS-fuer-Ihre-Domains-ein.html
Zur Linux-"Kiste" kann ich nur raten, dass du das auch eintragen kannst. Mir ist das von z.B. Synology-NAS bekannt, ob das bei deinem Linux klappt, kann ich nur raten.

Edit: Hier auf die Schnelle Bilder zu Routern und darunter gleich diverse Clients für Linux: https://wiki.ubuntuusers.de/DDNS-Clients/

 

[Raijin]

Was ich nicht verstanden hab:
- Wie / an welcher Stelle wird der Port des Webservers ergänzt ?
Die nftables Route wird bei einer eingehenden Verbindung, die den Port 8000 enthält, ausgelöst. Beim Domain-Anbieter trage ich ja eigentlich keinen Port ein (oder doch?).

Also mit nftables habe ich bisher noch keine Berührungspunkte gehabt. Prinzipiell wird das aber nicht viel anders sein als iptables mit etwas anderer Syntax.

Das was du bezüglich Domain und DNS beschreibst ist im Prinzip das was als DDNS (Dynamic DNS) gilt. Wobei das dynamic daher rührt, dass die besagte Domain regelmäßig mit der aktuellen, wechselnden IP des Internet-Anschlusses aktualisiert wird. Bei einer statischen öffentlichen IP ist das sogar noch simpler, weil man da im Prinzip den DDNS-Account nur einmalig aktualisieren muss. Alternativ kann man bei einer statischen IP aber auch bei einer gebuchten Domain bei einem beliebigen Domain-Anbieter - zB febas - in die Domain-Konfiguration gehen und dort direkt Subdomains erstellen und sie quasi fest auf die statische IP zeigen lassen. So habe ich beispielsweise bei meiner Domain diverse Subdomains, die auf mehrere Miet-vServer, über die ich meine VPNs abwickle. Die Miet-vServer haben nix mit meinem Domain-Anbieter zu tun, ich biege nur den Domain-DNS auf die IPs der Server um.

An dieser Stelle ist schon mal die gründsätzliche Erreichbarkeit über die Domain gegeben, sei es statisch oder dynamisch. Wenn nun auf deinem Server ein Webserver laufen soll, dann passiert dies über die http/https Ports (tcp 80 / 443). Ein Browser wird diese Ports im Hintergrund automatisch ergänzen, wenn man eine Domain in die Adresszeile eingibt und vorneweg http:// bzw. https:// steht. Möchte man einen gezielten Port erreichen, kann man auch domain:irgendeinport eingeben, also im Browser zB hieris.nix:8000. Nun kommen an deiner öffentlichen IP - also am WAN-Port des Routers - Daten auf diesen Ports an und der Router muss dementsprechend eine Portweiterleitung auf deinen Webserver im Netzwerk einrichten. domain:80 --> localIP:80 oder auch domain:8000 --> localIP:80. Der lokale Port des Servers muss also nicht zwangsläufig mit dem externen Port übereinstimmen, das nennt sich Port Translation, also Portübersetzung. Generell würde ich die lokalen Server stets mit Standard-Ports laufen lassen und etwaige Alternativ-Ports dann über den Router umleiten lassen. Es besteht kein Grund, einen Server im lokalen Netzwerk auch mit irgendwelchen Fantasie-Ports einzurichten.


Im übrigen bestehen NAT-Regeln in den iptables und vermutlich auch in nftables prinzipiell aus dem Matching und der Aktion. Die Aktion wiederum ändert einzig und allein das was angegeben ist. Wenn eine Portweiterleitung daher nur eine neue Ziel-IP hat, dann wird 1:1 der Port durchgereicht und eben nur die Ziel-IP geändert. Möchte man den Port auch ändern, muss man ihn explizit angeben.

 

[Sun_set_1]

Entweder stellst Du das bei Portforwarding im Router feste ein, oder aber änderst den Eingangsport vom 8000 auf 80 am Server. Kommt aufs gleiche raus, da wenn keine gegensätzliche Regel vorliegt, die Anfrage über Port 80 im wahrsten Sinne des Wortes "durchgeroutet" wird.

Den Rest hast Du korrekt verstanden. Jedoch beachte die vorhergehenden Beiträge bzgl der statischen IP bzw DynDNS.

Wenn Du Portforwarding nutzt, achte darauf, dass die eingehende Kommunikation auf Port 80/443 ausschließlich von den Domainaufrufen akzeptiert wird. Ansonsten wirst Du in Nullkommanichts durch IP/Port-Sniffer belästigt.

 

[Raijin]

Eins hab ich noch vergessen: Macht man ein Gerät im lokalen Netzwerk aus dem Internet erreichbar, muss man sich auch die Firewall des Geräts anschauen. In den meisten Fällen wird die dortige Firewall sämtliche eingehenden Verbindungsanfragen von unbekannten Quellen (=> nicht lokal = Internet = unbekannt) ablehnen. Das heißt, die lokale Firewall des Webservers muss explizit erlauben, dass man Port 80, 443 oder eben auch 8000 aus dem Internet erreichen darf. Sonst leitet der Router pflichtbewusst weiter und der Webserver sagt einfach "nö, ich bin nur lokal erreichbar"

 

[FAN4TIC]

Keinen täglichen IP Wechsel durch den Provider?

Wollte die Frage so einfach wie möglich halten, deshalb bin ich hier von den Szenario ausgegangen, dass die IP statisch ist.

Der Port wird bei deinem Router eingetragen... die Webanfrage wird ja über Port80 laufen, dein Router muss diesen dann auf 8000 umleiten

@Raijin, Sun_set_1
Danke für eure umfangreichen Erklärungen zu Routing und auch DDNS. Tatsächlich hört der Server auf Port 80, es war lediglich ein Fehler meinerseits. Jetzt wird mir auch einiges klarer bezüglich Routing.


VG

 

[Sun_set_1]

Gerne!

Achte wie gesagt darauf, die Kommunikation in der Firewall nur vom Routingpunkt/Server deiner Domain aus zu erlauben.
Es kann sein, dass Du dafür einen besseren Router benötigst. Ich bin mir nicht sicher, ob das Blocken auf dem Server reicht. Denn wenn die Anfrage vom Router erstmal weitergeleitet wird, müsste dies theoretisch per tracert von Sniffern zu erkennen sein. Kann sein, dass ich mich Irre. Länger nicht mehr damit zu tun gehabt.

In jedem Falle ist aber immer der richtige Ansatz, jegliche unerwünschte Kommunikation bereits am allerersten Gateway zu blockieren, damit wirklich nichts ins interne Netzwerk gelangen kann.

 

[Raijin]

traceroutes arbeiten mit Pings und Pings gehen bei NAT immer nur genau bis zur NAT-Grenze. Es ist von außen nicht erkennbar ob die Antwort direkt vom Router kommt oder von einem Gerät dahinter.

 

[Hayda Ministral]

In jedem Falle ist aber immer der richtige Ansatz, jegliche unerwünschte Kommunikation bereits am allerersten Gateway zu blockieren, damit wirklich nichts ins interne Netzwerk gelangen kann.

Ohne ins Detail gehen zu wollen: Es kann auch vorteilhaft sein einen gängigen Port nicht zu blocken. Wer auf 20 oder 80 ankommt wird bei mir für x Minuten in die Blacklist eingetragen und kann somit auch auf dem tatsächlich aktiven Port keinen Schaden mehr anrichten.