Hallo! Ich habe zu Hause einen Server laufen, auf dem ein Webserver(apache2), ein Teamspeakserver und ein Minecraftserver läuft. Diese 3 Dienste sind, jeweils auf ihren Standardports, alle per DDNS über sagen wir meinserver.ddns.net erreichbar. Jetzt möchte ich meine gekaufte Domain meinedomain.at nutzen, um mit meinedomain.at die Website, mit ts.meinedomain.at den TS und mit mc.meinedomain.at den MC Server zu erreichen. Ich könnte jetzt natürlich alle 3 Domains an meinserver.ddns.net weiterleiten. Dann kann ich aber mit jeder (Sub)domain jeden Dienst erreichen. Also gebe ich z.B. in Minecraft dann ts.meinedomain.at ein komme ich trotzdem hinein. Oder im Browser mit mc.meinedomain.at erreiche ich die Internetseite. Gibt es hier irgendeine Möglichkeit, dass ich mit jeder (Sub)domain wirklich nur den jeweiligen Dienst erreiche? Apache hat ja eine Funktion, die sich Virtual Host nennt, ich glaube das wäre soetwas. Das hilft mir aber nur mit der Website und nicht mit den beiden anderen Diensten. Danke für eure Hilfe, Christoph
Christoph K. schrieb: > Gibt es hier irgendeine Möglichkeit, dass ich mit jeder (Sub)domain > wirklich nur den jeweiligen Dienst erreiche? Apache hat ja eine > Funktion, die sich Virtual Host nennt, ich glaube das wäre soetwas. Geht, indem du jeden Dienst so konfigurierst, dass er nur auf die Anfrage, die über die jeweils gewünschte Subdomain reinkommt, reagiert. Anders macht man es mit dem Apachen und den namensbasierten vHosts auch nicht – der httpd bekommt erstmal alles, was auf dem Port über das Interface reinkommt, und reicht die Anfrage entsprechend des ServerNames an den entsprechenden vHost weiter. Wenn keiner passt, wird der Default-vHost genommen (sofern nicht anders konfiguriert, selbstredend). Sollte™ mit den anderen beiden Diensten auch so gehen – einfach mal ins Manual schauen.
Christoph K. schrieb: > Gibt es hier irgendeine Möglichkeit, dass ich mit jeder (Sub)domain > wirklich nur den jeweiligen Dienst erreiche? Apache hat ja eine > Funktion, die sich Virtual Host nennt, ich glaube das wäre soetwas. Das > hilft mir aber nur mit der Website und nicht mit den beiden anderen > Diensten. Bei HTTP(S) kommt die Domain im Aufruf mit, damit weiß der Apache wohin damit. Bei den Protokollen der beiden anderen Dienste ist das vielleicht auch so - oder nicht, dann hast du Pech gehabt.
Danke mal für eure Antworten! Jan H. schrieb: > Bei den Protokollen der beiden anderen Dienste ist das vielleicht > auch so - oder nicht, dann hast du Pech gehabt. Jack V. schrieb: > Sollte™ mit den anderen beiden Diensten auch so gehen – einfach mal ins > Manual schauen. Wenn ich euch also richtig verstehe, muss das der jeweilige Dienst, also Minecraft bzw Teamspeak, unterstützen? Es gibt also unter Linux keinen eigenen Dienst der das übernehmen kann? Und mit SRV Records kann ich hier auch nichts machen? Das habe ich in Google manchmal gefunden, glaube aber, dass es für etwas anderes ist, hab ich aber leider nicht zu 100% verstanden.
:
Bearbeitet durch User
Das ist so. Wenn du IPv6 benutzt hast du evtl mehrere Adressen zur Auswahl? Aber wer nutzt das schon...
Christoph K. schrieb: > Wenn ich euch also richtig verstehe, muss das der jeweilige Dienst, also > Minecraft bzw Teamspeak, unterstützen? Es gibt also unter Linux keinen > eigenen Dienst der das übernehmen kann? Du verstehst rudimentärste Sachen nicht und willst einen öffentlichen Server betreiben? Vielleicht erstmal ein paar Jahre in Virtualbox mit einem LAN spielen.
Christoph K. schrieb: > Wenn ich euch also richtig verstehe, muss das der jeweilige Dienst, also > Minecraft bzw Teamspeak, unterstützen? Schon das Protokoll des Dienstes muss es unterstützen. > Es gibt also unter Linux keinen eigenen Dienst der das übernehmen kann? Überleg doch, wie Namensauflösung funktioniert. Dann sollte klar sein, dass das nicht geht. Dein Server wird ja nicht über den Namen kontaktiert. Der Client fragt seinen Nameserver nach der IP-Adresse des Rechners mit dem gewünschten Namen. Dann nutzt er diese IP-Adresse, um deinen Server zu kontaktieren. Der verwendete Name ist an der Stelle gar nicht mehr involviert, und somit weiß dein Server ihn nicht. Bei http ist es so, dass nach dem Verbindungsaufbau der Client dem Server auf Anwendungsebene über das Protokoll nochmal explizit mitteilt, über welchen Namen er zugegriffen hat. Und so erfährt das dein Apache. Das gibt's aber nicht bei jedem Protokoll. Außerdem heißt es natürlich, dass ein Verbindungsaufbau schon erfolgt sein muss, bevor der Server weiß, ob die Anfrage überhaupt über den richtigen Namen durchgeführt worden ist. Man kann also auf die Weise keinen Server machen, der auf Verbindungsanfragen über den falschen Namen gar nicht erst antwortet.
:
Bearbeitet durch User
@Threadstarter: Vielleicht solltest Du mal erklären, welchen konkreten Vorteil Du Dir davon erhoffst, dass bspw. der Teamspeakserver nicht über mc.meinedomain.at erreicht werden kann (und anders herum).
Rolf M. schrieb: > Überleg doch, wie Namensauflösung funktioniert. Dann sollte klar sein, > dass das nicht geht. Dein Server wird ja nicht über den Namen > kontaktiert. Der Client fragt seinen Nameserver nach der IP-Adresse des > Rechners mit dem gewünschten Namen. > Dann nutzt er diese IP-Adresse, um deinen Server zu kontaktieren. Der > verwendete Name ist an der Stelle gar nicht mehr involviert, und somit > weiß dein Server ihn nicht. > Bei http ist es so, dass nach dem Verbindungsaufbau der Client dem > Server auf Anwendungsebene über das Protokoll nochmal explizit mitteilt, > über welchen Namen er zugegriffen hat. Und so erfährt das dein Apache. > Das gibt's aber nicht bei jedem Protokoll. Außerdem heißt es natürlich, > dass ein Verbindungsaufbau schon erfolgt sein muss, bevor der Server > weiß, ob die Anfrage überhaupt über den richtigen Namen durchgeführt > worden ist. Man kann also auf die Weise keinen Server machen, der auf > Verbindungsanfragen über den falschen Namen gar nicht erst antwortet. Vielen Dank für eine kompetente Aussage die man leicht nachvollziehen kann. So lernt man am schnellsten! Joachim S. schrieb: > @Threadstarter: > Vielleicht solltest Du mal erklären, welchen konkreten Vorteil Du Dir > davon erhoffst, dass bspw. der Teamspeakserver nicht über > mc.meinedomain.at erreicht werden kann (und anders herum). Es geht mir neben der eigentlichen Sache (ich finde es einfach die "sauberere" Lösung) auch darum Dinge zu lernen und da es bei Apache geht wollte ich wissen warum/wie und ob bei anderen Diensten auch
blub schrieb: > Das ist so. Wenn du IPv6 benutzt hast du evtl mehrere Adressen zur > Auswahl? Aber wer nutzt das schon... Z.B.: - Deutschland: 42,67% - Belgien: 52,08% - USA: 37,63% - Indien: 36,88% - Malaysia: 40,05% Willkommen im Jahr 2019!
Für eine saubere Lösung bräuchtest du für jeden Dienst eine eigene IP und das wird schwierig (zumindest für IPv4) Es ist ja so, dass alle Hostnames auf die gleiche IP zeigen. Der Connect erfolgt ja auf IP Ebene und da kann der Server ja nicht fest stellen, welcher Name vorher aufgelöst wurde. Erst das Protokoll (HTTP) überträgt den Host. Wenn dann noch Verschlüsselung dazu kommt, dann wird das noch schlimmer, da zusätzlich über SNI der Name übertragen werden muss. Das gibt dann vermutlich auch noch lustige Zertifikatswarnungen, wenn z. B jemand tc.domain.at im Browser eingibt und der Browser nur ein Zertifikat für www.domain.at hat. Gruß Roland
Sowas macht man mit einem reverse proxy. Du legst mehrere Subdomains an die alle auf deine (die gleiche) IP zeigen. (Ex. service1.domain.com, service2.domain.com, ...) Dann legst Du zum Beispiel unter nginx fuer jeden Dienst den Du betreiben willst eine eigene Konfigurationsdatei an. Unter dem directive proxy_pass traegst Du dann localhost:Port ein und die Anfrage wird an den entsprechenden Dienst weitergeleitet.
Eric schrieb: > Sowas macht man mit einem reverse proxy. Du legst mehrere Subdomains an > die alle auf deine (die gleiche) IP zeigen. (Ex. service1.domain.com, > service2.domain.com, ...) > Dann legst Du zum Beispiel unter nginx fuer jeden Dienst den Du > betreiben willst eine eigene Konfigurationsdatei an. > Unter dem directive proxy_pass traegst Du dann localhost:Port ein und > die Anfrage wird an den entsprechenden Dienst weitergeleitet. Aber das klappt doch eben nur für http(s). Du hast die Problemstellung vermutlich nicht richtig gelesen - es geht nicht darum, mehrere http-/Webserver für mehrere (Sub)domains auf ein und derselben Maschine laufen zu lassen, sondern um unterschiedliche Server-Dienste (Teamspeak-Server Minecraft-Server http-Server). > Joachim S. schrieb: >> @Threadstarter: >> Vielleicht solltest Du mal erklären, welchen konkreten Vorteil Du Dir >> davon erhoffst, dass bspw. der Teamspeakserver nicht über >> mc.meinedomain.at erreicht werden kann (und anders herum). > > Es geht mir neben der eigentlichen Sache (ich finde es einfach die > "sauberere" Lösung) auch darum Dinge zu lernen und da es bei Apache geht > wollte ich wissen warum/wie und ob bei anderen Diensten auch Ok, alles klar. Warum das bei IPv4 grundsätzlich nicht möglich ist, sofern das Protokoll das nicht explizit ermöglicht, hast Du mittlerweile ja verstanden. Obwohl Dein ursprüngliches Anliegen so also nicht möglich ist, kann es im Sinne einer "sauberen" Lösung übrigens trotzdem sinnvoll sein, unterschiedliche Subdomains für die unterschiedlichen Dienste anzulegen. Derzeit wäre bspw. der Minecraft-Server dann zwar trotzdem auch über ts.meinedomain.at erreichbar, die verschiedenen Subdomains also im Grunde ohne Wirkung. Weil sich das in Zukunft aber ändern könnte - z.B., weil Du vielleicht irgendwann einen vServer anmietest und manche (aber nicht alle) Dienste auf diesen vServer auslagerst - ist es schon jetzt sinnvoll, für die unterschiedlichen Dienste unterschiedliche Subdomains anzulegen. Die derzeit eher wirkungslosen Subdomains wären dann so eine Art Zukunftsversprechen, im Sinne von: "Mein Teamspeak-Server ist immer unter ts.meinedomain.at erreichbar. Derzeit ist es zwar auch möglich, ihn bspw. auch über mc.meinedomain.at zu erreichen - das könnte sich in der Zukunft aber jederzeit ändern, daher ist nur ts.meinedomain.at die richtige Adresse für den Teamspeak-Server"
Joachim S. schrieb: > Aber das klappt doch eben nur für http(s) Nein, es klappt auch fuer andere Protokolle. Ich selbst nutze es fuer uwsgi. Einen Minecraft-Server habe ich noch nie aufgesetzt, aber ich vermute mal dass man in dem Client (dem Spiel?) die Portnummer eingeben kann. Dann kann man natuerlich auch gleich auf den RevProxy verzichten.
Eric schrieb: > Joachim S. schrieb: >> Aber das klappt doch eben nur für http(s) > > Nein, es klappt auch fuer andere Protokolle. Ich selbst nutze es fuer > uwsgi. Du hast doch davon geschrieben, "unter nginx fuer jeden Dienst den Du betreiben willst eine eigene Konfigurationsdatei (anzulegen)". Das geht aber doch nur für http(s)? > Einen Minecraft-Server habe ich noch nie aufgesetzt, aber ich vermute > mal dass man in dem Client (dem Spiel?) die Portnummer eingeben kann. > Dann kann man natuerlich auch gleich auf den RevProxy verzichten. Ich vermute immer noch, dass Du das Problem falsch verstanden hast. Der Threadstarter will, dass der Teamspeak-Server nur unter ts.meinedomain.at erreichbar ist, nicht aber unter mc.meinedomain.at - obwohl beide DNS-Namen auf genau die gleiche IP-Adresse verweisen.
Eric schrieb: > Einen Minecraft-Server habe ich noch nie aufgesetzt, aber ich vermute > mal dass man in dem Client (dem Spiel?) die Portnummer eingeben kann. Das ist keine schöne Lösung, weil man dann, bei anderen Portnummern, die Nutzer immer zwingt, diese zu ändern oder auch noch anzugeben. Wenn die Nutzer aber sehr restriktive Firewallregeln haben, dann müssen sie für jede Portänderung die Firewall etwas weiter aufmachen, um alle möglichen Fälle bzw. Ports, bei der so ein MC Server laufen könnte, abzudecken. Wenn es also irgendwie möglich ist, sollte man beim Defaultport bleiben. Bei mehreren Servern hinter der gleichen IP geht es natürlich nicht anders, als andere Ports zu vergeben, aber wenn das der einzige MC Server ist, dann sollte man den default Port so belassen wir er ist.
Nano schrieb: > Wenn die Nutzer aber sehr restriktive Firewallregeln haben, dann befindet sich der User in einem Netzwerk, in dem er eh nicht MC spielen darf. ;-) Eric schrieb: > Joachim S. schrieb: >> Aber das klappt doch eben nur für http(s) > > Nein, es klappt auch fuer andere Protokolle. Ich selbst nutze es fuer > uwsgi. Nginx kann zwar mehr Protokolle, imap, smtp,... oder auch tcp/udp forward. Dennoch muss das Protokoll "virtual host" fähig sein. Woher soll der Proxy sonst wissen, ob der Client das UDP Paket an ts1.domain.de oder ts2.domain.de geschickt hat, wenn die Info nicht im Datenpaket mit enthalten ist. Das was Christoph vor hat, geht schlichtweg nicht, wenn er nur eine IP hat. Muss aber Joachim zustimmen, es jetzt schon so "halbsauber" zu machen ist der richtige Weg. Gruß Roland
Richte dir Let's Encrypt ein, und lasse dir automatisch regelmäßig ein neues Wildcard Zertifikat generieren. TLS beinhaltet die Domain Information, siehe TLS SNI (Obwohl, nicht jeder Service muss diesen zwingend mitliefern). In der Theorie also einfach darauf achten, die TLS variante der Protokolle zu nutzen imapS, smtpS, ftpS, httpS, etc. Da kann man dann nen Proxy vorschalten, der das richtig zuordnet (nginx kann das vermutlich). Einige Services unterstützen auch DNS-SD, und damit einen custom port+ip pro Service mit SRV Record https://de.wikipedia.org/wiki/SRV_Resource_Record Ausserhalb mDNS basierter Services ist die Unterstützung/Verbreitung aber nicht so gross. (Teamspeak gehört aber zu den Diensten, die dass können.)
Joachim S. schrieb: > Du hast doch davon geschrieben, "unter nginx fuer jeden Dienst den Du > betreiben willst eine eigene Konfigurationsdatei (anzulegen)". Das geht > aber doch nur für http(s)? Ich bin davon ausgegangen, dass man hier ducrch aufruf einer bestimmten Subdomain auf einen Service X zugreifen moechte, ohne direkt den Port dafuer mit angeben zu muessen. Genau dass erreicht man durch den RevProxy. Die Subdomain ruft den "virtuellen Host" auf, der unter dem directive server_name angegeben ist, e.g. minecraft.domain.com Das directive proxy_pass leitet es dann an den eigentlichen Server weiter, e.g. localhost:8000. Was dass bei einem Spiele-Server dann bringt, weiss ich nicht, aber so kann man es machen. Roland P. schrieb: > Nginx kann zwar mehr Protokolle, imap, smtp,... oder auch tcp/udp > forward. > Dennoch muss das Protokoll "virtual host" fähig sein. Woher soll der > Proxy sonst wissen, ob der Client das UDP Paket an ts1.domain.de oder > ts2.domain.de geschickt hat, wenn die Info nicht im Datenpaket mit > enthalten ist. Siehe oben. -> server_name |= proxy_pass
Dieser Minecraft Server scheint ja in der Tat kein Dienst zu sein, der ueber ein Webinterface aufgerufen wird. Das tut mir leid, es war mir nicht bekannt. Man kann es aber trotzdem realisieren: Durch einen SRV-Record. Ich gehe mal davon aus, dass die Subdomain schon besteht. Als Beispiel nehme ich hier mal minecraft.domain.com. Im SRV-Record wird dann der Name des Dienstes und der dazugehoerige Port angegeben. Als Protokoll _(Protokoll).minecraft Als Port der Port des Servers, e.g. 8000 Welches Protokoll dein Server verwendet, weiss ich nicht. Im Fall von udp lautet der Eintrag dann _udp.minecraft
Im oben verlinkten Wikipediaartiker steht _minecraft._tcp.example.com, wäre also _minecraft._tcp.mc.meinedomain.at. , um das Beispiel im Eingangspost wieder aufzugreifen.
Roland P. schrieb: > Nano schrieb: >> Wenn die Nutzer aber sehr restriktive Firewallregeln haben, > > dann befindet sich der User in einem Netzwerk, in dem er eh nicht MC > spielen darf. ;-) Ich habe früher einen alten 486er PC zu einem Router umfunktioniert und an den das DSL Modem angeschlossen, an den PC kam dann noch ein einfacher Hub, so dass die anderen Rechner im Haus sich den Internetanschluss teilen konnten. Die in Linux verfügbare Firewall ipchains und später iptables war jedenfalls schon damals sehr mächtig und bezüglich der Konfigurierbarkeit besser als das, was man damals als noch teure Konsumerkaufrouter bekam. Meine FW war sehr restriktiv eingestellt, so dass ich ständig Anpassungen vornehmen musste, wenn ein externer Spieleserver wieder mal einen anderen Port genutzt hat, als das, was für das jeweilige Spiel üblich war. Solange das nur vereinzelte Spieleserver waren, war's kein Problem, die wurden dann halt ignoriert, aber manche Ports wurden dann doch öfters belegt.
So, jetzt hab ich mal das grundsätzliche mit "standard"DNS einträgen verstanden, dann kommt schon das nächste für mich verwirrende: Eric schrieb: > Das tut mir leid, es war mir nicht bekannt. > Man kann es aber trotzdem realisieren: Durch einen SRV-Record. SRV-Record ist auch ein Begriff der mir schon untergekommen ist. Ich habe das so verstanden: Wenn ein Server (z.B. Minecraft) nicht auf dem Standardport läuft, muss ich beim anmelden ja ip:port bzw domain:port eingeben. Der SRV Record soll nun irgendwie den Port ersetzten, so dass die Domain alleine reicht. 2 Fragen: Wie macht der SRVRecord das und was würde passieren wenn ich die Domain mit dem Record dann in den Browser eintragen würde?
SRV Records sind nicht für den Server da, sondern für den Client. Da es hier um bestehende Protokolle geht, mit bestehenden Clients, bringen solche Records nur dann etwas, wenn diese Clients bereits so programmiert sind, dass sie nach nach passenden SRV Records fragen. Tun sie das nicht, kann man aufhören, sich darüber Gedanken zu machen.
Christoph K. schrieb: > Wenn ein Server (z.B. Minecraft) nicht auf dem > Standardport läuft, muss ich beim anmelden ja ip:port > bzw domain:port eingeben. Das ist recht selten die Ausgabe von SRV Records. Üblicherweise ist das Teil der Client-Konfiguration.
A. K. schrieb: > SRV Records sind nicht für den Server da, sondern für den Client. > Da es hier um bestehende Protokolle geht, mit bestehenden Clients, > bringen solche Records nur dann etwas, wenn diese Clients bereits so > programmiert sind, dass sie nach nach passenden SRV Records fragen. Tun > sie das nicht, kann man aufhören, sich darüber Gedanken zu machen. Ok, das sind auch sehr hilfreiche Infos! Danke.
Joachim S. schrieb: > Obwohl Dein ursprüngliches Anliegen so also nicht möglich ist, kann es > im Sinne einer "sauberen" Lösung übrigens trotzdem sinnvoll sein, > unterschiedliche Subdomains für die unterschiedlichen Dienste anzulegen. Ganz allgemein empfiehlt es sich, Dienste eines Servers über individuelle logische Namen anzusprechen. Also z.B. ein CNAME Record für jeden der diversen Dienste, das auf den realen Server verweist. Der reale Server hat einen eigenen getrennten Namen als A/AAAA Record, wird aber nicht über diesen Namen von Clients der Dienste angesprochen. Dieses Prinzip erleichtert Upgrades und Umzug von Diensten erheblich, weil nur Server und DNS angefasst werden müssen, währen die Clients überhaupt nichts davon mitkriegen.
:
Bearbeitet durch User
Beitrag #5964459 wurde vom Autor gelöscht.
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.