Hallo, ich habe bei mir 3 Linux-Server stehen welche alle unter der selben öffentlichen IP laufen. Nun ist Server 1 über einen Domain erreichbar und alle Anfragen gehen zu Server 1. Ist es möglich, Anfragen an Server 2 und 3 weiterzuleiten abhängig von der Sub-Domain? Also: domain -> Server 1 subdomain1 -> Server1 -> Weiterleiten aus Server 2 subdomain2 -> Server1 -> Weiterleiten auf Server 3 Mfg, Tropaion
:
Bearbeitet durch User
A. K. schrieb: > Könnte helfen, Protokoll und/oder Software zu nennen. Wenn du mit Subdomains subdomain.domain meinst, dann kannst du einfach entsprechende DNS Einträge anlegen.
Kann man so etwas mit einem Router machen? Irgendeine Software kann es sicher unter Linux.
:
Bearbeitet durch User
Hans schrieb: > Wenn du mit Subdomains subdomain.domain meinst, dann kannst du einfach > entsprechende DNS Einträge anlegen. Naheliegenderweise. Er wird aber vermutlich einen üblichen IPv4 Anschluss zu Hause haben, der nur über eine einzige öffentliche IP-Adresse verfügt. Da bringt ihm DNS nichts. Wie das bei http läuft wurde bereits genannt.
Ich brauche HTTP, TCP und UTP. Das was mir bis jetzt, nach tagelangem Lesen am sinnvollsten vorkommt ist Load Balancing/Reverse Proxy: https://www.nginx.com/products/application-load-balancing/ https://www.nginx.com/resources/admin-guide/tcp-load-balancing/ Weiß jemand, ob es Switches gibt, die das können?
Fabian P. schrieb: > welche alle unter der selben > öffentlichen IP laufen Ist es jeden Tag die selbe? Frage den öffentlichen Anbieter nach drei IP Adressen, ist ein Sonderwunsch, denke ich.
Bei Nginx ist das sicherlich möglich. In TCP/UDP oder darunter ist es nicht möglich, weil in diesen Protokollschichten keine Domainnamen identifizierbar sind. Folglich kann es auch keine L2/L3-Switches geben, die das ermöglichen.
Lutz H. schrieb: > Ist es jeden Tag die selbe? Nein, die ändert sich alle 24 Stunden. Leider bekommen bei A1 nur Business-Kunden festes IP-Adressen. Das ist jetzt aber nicht so das Problem, da ich bei meiner Domain CNAME-Record auf meinen MyFritz-Adresse habe. A. K. schrieb: > In TCP/UDP oder darunter ist es nicht möglich, weil in diesen > Protokollschichten keine Domainnamen identifizierbar sind. Nginx soll das anscheinend können.
:
Bearbeitet durch User
Fabian P. schrieb: >> In TCP/UDP oder darunter ist es nicht möglich, weil in diesen >> Protokollschichten keine Domainnamen identifizierbar sind. > > Nginx soll das anscheinend können. Klar. Nginx sitzt oberhalb von TCP. Netzwerkgrundlagen, OSI-Modell.
Was auch geht: Server 1 hört auf Port 80 Server 2 hört auf Port 8080 Server 3 hört auf Port 8086 Analog zum Reverse Proxy Verfahren kann dann Server 1 deine Subdomains per Redirect oder Rewrite auf die anderen verweisen. Im Unterschied zum Reverse Proxy finden dann keine Durchleitung von Server 1 auf 2/3 statt, sondern der Client bekommt als Teil des HTTP Protokolls von Server 1 statt HTML die Antwort, es bei Server 2 Port 8080 zu probieren. Kriegst du nichts von mit, passiert automatisch, man sieht es aber anschliessend in der URL-Leiste. Also http://server2.deine.domain/... => http://deine.domain:8080/... http://server3.deine.domain/... => http://deine.domain:8086/... Das geht auch ohne Subdomain, also http://deine.domain/server2/... => http://deine.domain:8080/... http://deine.domain/server3/... => http://deine.domain:8086/...
:
Bearbeitet durch User
A. K. schrieb: > Analog zum Reverse Proxy Verfahren kann dann Server 1 deine Subdomains > per Redirect oder Rewrite auf die anderen verweisen. Ja, die Methode kenne ich, gefällt mir aber ehrlich gesagt nicht besonders. Habe gerade mit nginx telefoniert, die free-Version kann nur HTTP reverse proxy. Die Plus-Version kostet 1900 Dollar im Jahr, kann aber auch UTP und TCP.
Fabian P. schrieb: > Die Plus-Version kostet 1900 Dollar im Jahr, kann aber auch UTP und TCP. Dann zahl mal schön. ;-) Was immer du per Nginx machst: Der erste Server, also der unter Port 80, verteilt die Anfragen ggf. weiter. Ob das per Proxy-Config geschieht, per Rewrite oder sonstwie, das ändert daran nichts. Worin liegt in deinem Fall also der Vorteil von einer Konfiguration per SRV-Record, statt Rewrite? https://www.nginx.com/blog/dns-service-discovery-nginx-plus/ NB: TCP kann jeder Webserver und UTP kenne ich als Kabeltyp.
:
Bearbeitet durch User
Grundsätzlich kann man jedes Protokoll per Domain name weiter routen, welches den Domainnamen enthält. TCP und UDP enthalten noch keine Domain, SSL und HTTP schon. Für HTTP(s) kann man z.B. haproxy nehmen, oder apache + mod_proxy/rewrite. Bei reinem SSL kenne ich keine Anwendung, ich hatte aber mal eine geschrieben: https://github.com/Daniel-Abrecht/DPA-SSL-SNI-Forwarder
Über den Umweg eines öffentlichen Servers, auf dem man echte Subdomains einrichten kann. Dann aus der jeweiligen Subdomain eine Weiterleitung (per Metatag/refrsh, per PHP oder JS) auf die öffentliche Adresse von zuhause, aber über verschiedene Portnummern (hinter Doppelpunkt an der IP). Diese weitergeleiteten Zugriffe kann wiederum ein Home-Router per Protfowarding anhand der Ports auf unterschiedleiche Entgeräte leiten ...
:
Bearbeitet durch User
Die UDP/TCP Ports kannst du mit iptables weiterleiten. Beispiel: meine.domain:8000 leitet auf server2.intern:7000 um. Die Antwort geht dann von server2.intern:7000 über meine.domain:8000 zurück. Man kann aber auch eine Umleitung von 8000 nach server2:8000 machen. Aber der Port 8000 ist dann für server1 "tot". Sowas kannst du aber auch direkt per Router machen. Stichwort: Port-Forwarding
Fabian P. schrieb: > Nun ist Server 1 über einen Domain erreichbar > und alle Anfragen gehen zu Server 1. Ist es möglich, Anfragen an Server > 2 und 3 weiterzuleiten abhängig von der Sub-Domain? Ich denke, das könnte sogar funktionieren. Hast Du Windows oder Linux?
Daniel A. schrieb: > Grundsätzlich kann man jedes Protokoll per Domain name weiter routen, > welches den Domainnamen enthält. Das geht allerdings nur dann, wenn der Netzanbieter diese Funktion unterstützt. Bei manchen Kabelnetzbetreibern bspw. bekommt man eine "gesperrte" Fritzbox, will heissen, man kann sie nicht richtig frei parametrieren, weil die Grundsoftware etwas vom Kabelanbieter verändert wurde und nicht alle Einstellmöglichkeiten freigeschaltet wurden.
@Bueroboss (Gast) Gut, was ist wahr, aber ich bezeichne das lieber als nicht unterbinden statt unterstützen. Ich finde schon lange, dass was die ISPs den Kunden anbieten müssen zu schlecht geregelt ist. Mögliche Einschränkungen durch ISPs: * Gesperrte Ports * Umgeleitete Ports (MitM, beispiel SIP/Voip nach aussen, bei sunrise, handy, schweiz) * Proxies * teilweise Drosselung bestimmter Dienste Verbindungstypen: * NAT (keine Verbindung von Aussen nach innen) * Öffentliche dynamische IP * Öffentliche statische IP Zusätzliche Dienstleistung nur durch ISP möglich: * Reverse DNS einträge Ich finde, die Punkte unter Einschränkungen sollte man den ISPs verbieten. NAT sollte man nur für IPv4 erlauben, und bei IPv6 sollte eine statische IP pflicht sein. Ausserdem finde ich, dass auch ohne teures SLA angebote mit Reverse DNS und statischer IP vorhanden sein sollten, auch bei IPv4. Aber um sowas durchzusetzen müsste ich wohl politisch aktiv werden. Ich präzisiere meine Aussage im vorherigen Post nun etwas. Grundsätzlich kann man jedes Protokoll per Domain name weiter routen, welches den Domainnamen enthält, wenn man einen PC mit Öffentlicher IP hat und der ISP keine Ports blockiert.
blubb schrieb: > Sowas kannst du aber auch direkt per Router machen. > Stichwort: Port-Forwarding Genau das will ich vermeiden, sonst bräuchte ich hier gar nicht Fragen ;). Bueroboss schrieb: > Hast Du Windows oder Linux? Auf Server natürlich immer Debian ;). Bueroboss schrieb: > Bei manchen Kabelnetzbetreibern bspw. bekommt man eine > "gesperrte" Fritzbox Trifft bei mir nicht zu, habe die FritzBox selbst gekauft und ersetzt denn Router vom Provider. Daniel A. schrieb: > Ich finde, die Punkte unter Einschränkungen sollte man den ISPs > verbieten. Stimme dir vollkommen zu! Daniel A. schrieb: > Grundsätzlich > kann man jedes Protokoll per Domain name weiter routen, welches den > Domainnamen enthält, wenn man einen PC mit Öffentlicher IP hat und der > ISP keine Ports blockiert. Ports werden bei mir nicht blockiert. Wie macht nginx dann das bei TCP und UDP? Mfg, Tropaion
Fabian P. schrieb: > Wie macht nginx dann das bei TCP und UDP? Magie. Im Ernst, wie soll der nginx ein x-beliebiges Paket an eine IP-Adresse richtig weiterrouten können? Wenn er aus dem Paket den Domainnamen herausbekommt, dann klappt es. Aber nachdem die benötigten Protokolle ein Geheimnis sind bzw. du wohl selbst nicht genau weißt was du brauchst, ist es schwierig mit der Hilfe.
Jan H. schrieb: > Magie Das ich nicht lache! Jan H. schrieb: > bzw. du wohl selbst nicht genau weißt was du > brauchst, ist es schwierig mit der Hilfe. Ich habe GENAU gesagt was ich will/brauche. Erst lesen, dann Kommentar abgeben. Mfg, Tropaion
Fabian P. schrieb: > Jan H. schrieb: >> Magie > > Das ich nicht lache! Das ist durchaus die einfachste Methode, denn nginx kann das nicht. Load Balancing ist da, um Verbindungen gleichmässig auf mehrere Server zu verteilen, nicht primär um diese nach bestimmten regeln an einen bestimmten Server weiterzuleiten. Eine Alternative wäre, mit einem RFC eine neue Option für Servernamen in IP Packete zu definieren, hoffen dass es angenommen wird, ein paar jahre zu warten, damit es vielleicht vom grossteil implementiert wird, und die Funktion dann in nginx einzubauen. Glaub mir, Magie ist einfacher als dass. Ausserdem, wenn du die Configuration für tcp und für http load balancing in nginx ansiehst, bei letzterem kannst du einen server-name angeben, bei ersterem nicht.
Auf IPv6 umsteigen und schon hat man mehr als genug IP-Adressen für interne Server. Die IPs dann als dyn-Adressen beispielsweise bei dynv6.com oder ähnlichen mit aussagekröftigen Namen registrieren.
Fabian P. schrieb: > Ich habe GENAU gesagt was ich will/brauche. Wer aufgrund fehlender Ahnung das Unmögliche fordert, muss mit solchen Antworten leben. Warum es unmöglich ist, wurde dir bereits (mehrfach) mitgeteilt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.