lokale IP-Adressen im Netzwerk erreichen
hangar
- https
0 Blubb0 mrjerk
Hallo,
folgende Ausgangssituation im Netzwerk:
1 Server (Windows 2008), auf diesem läuft ein Apacheserver. Auf diesem sollen verschiedene Webanwendungen laufen, die unter jeweils einer lokalen IP-Adresse erreichbar sind (127.0.0.1, 127.0.0.2, etc.). So weit kein Problem. (Alternativ wären mir auch Subdomains recht, wenn das folgende Anliegen damit zu erreichen ist.)
Jetzt will ich sowohl innerhalb des Netzwerkes als auch von "außen" bspw. auf dem Server auf bspw. 127.0.0.9 oder 127.0.0.15 zugreifen.
Wie kann ich das erreichen? Per dyndns und Routingeintrag auf dem Server für jede einzelne Adresse? Mein Halbwissen hilft mir momentan nicht richtig weiter...
Danke für eure Denkanstöße
hangar
Hallo,
Auf diesem sollen verschiedene Webanwendungen laufen, die unter jeweils einer lokalen IP-Adresse erreichbar sind (127.0.0.1, 127.0.0.2, etc.).
Das Hauptwort ist hier: lokal. Siehe: http://de.wikipedia.org/wiki/Localhost
Jetzt will ich sowohl innerhalb des Netzwerkes als auch von "außen" bspw. auf dem Server auf bspw. 127.0.0.9 oder 127.0.0.15 zugreifen.
Das geht nicht mit lokalen Adressen. Benutze eine aus dem privaten Bereich (zB 192.168. ...) und richte auf deinem Router ein Portforwarding ein.
WARNUNG: Ein falsch konfiguriertes System führt immer zu Sicherheitsproblemen jedweder Art! Im vorliegenden Fall wäre der Webserver über deine externe IP erreichbar. Möchtest du das?
Per dyndns und Routingeintrag auf dem Server für jede einzelne Adresse?
Nein, dyndns zur Namensauflösung und Routingeintrag auf dem Router.
Grüße
Moin Moin!
Per dyndns und Routingeintrag auf dem Server für jede einzelne Adresse?
Nein, dyndns zur Namensauflösung und Routingeintrag auf dem Router.
Ergänzend: Einige dyndns-Anbieter erlauben Wildcards, d.h. man kann unterhalb des registrierten Namens beliebige Subdomains erfinden.
Kurz: Man registriert sich foobar.dyndns.example, und kann dann den Webserver hinter dem Router z.B. über rot.foobar.dyndns.example, gelb.foobar.dyndns.example, gruen.foobar.dyndns.example, blau.foobar.dyndns.example erreichen. Das Aufdröseln der unterschiedlichen Hostnamen zu unterschiedlichen Angeboten erledigt der Webserver, Stichwort "Name-based virtual Hosts".
Alexander
Hallo,
Kurz: Man registriert sich foobar.dyndns.example, und kann dann den Webserver hinter dem Router z.B. über rot.foobar.dyndns.example, gelb.foobar.dyndns.example, gruen.foobar.dyndns.example, blau.foobar.dyndns.example erreichen. Das Aufdröseln der unterschiedlichen Hostnamen zu unterschiedlichen Angeboten erledigt der Webserver, Stichwort "Name-based virtual Hosts".
also es würde dann reichen
<VirtualHost *>
ServerName rot.foobar.dyndns.example
DocumentRoot /www/rot
</VirtualHost>
<VirtualHost *>
ServerName gelb.foobar.dyndns.example
DocumentRoot /www/gelb
</VirtualHost>
in der httpd-vhosts.conf einzutragen?
Gruß hangar
Moin Moin!
Was spricht dagegen, es auszuprobieren?
Alexander
Hallo,
Was spricht dagegen, es auszuprobieren?
Das es bisher theoretische Überlegungen/Planungen sind, wird erst in 1-2 Wochen losgehen.
Danke
Hello,
Was spricht dagegen, es auszuprobieren?
Das es bisher theoretische Überlegungen/Planungen sind, wird erst in 1-2 Wochen losgehen.
Das kannst Du sogar auf einem XAMPP ausprobieren und über die Hosts-Datei des Systems dann den DNS für die Domainzugriffe bewerkstelligen lassen. Das mache ich für jede neue Entwicklung so...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hallo,
Wie kann ich das erreichen? Per dyndns und Routingeintrag auf dem Server für jede einzelne Adresse? Mein Halbwissen hilft mir momentan nicht richtig weiter...
Mit mehreren IP-Adressen für eine Netzwerkkarte kenne ich mich ehrlich gesagt nicht aus.
Müssen es denn unterschiedliche IP-Adressen sein?
Sonst könntest Du das ganze über unterschiedliche Ports und entsprechende Virtuelle Hosts (sozusagen "Server im Server") realisieren: Jeder Virtuelle Host bekommt einen eigenen Port, und ist somit eindeutig ansprechbar.
Alternativ dazu wäre das auch über Subdomains möglich.
Auch hier kannst Du im Apache virtuelle Hosts definieren, die dann jeweils auf eine bestimmte Subdomain reagieren.
Zu Beachten ist allerdings, dass Du für Domains, die SSL-verschlüsselt werden sollen, jeweils eine eigene IP-Adresse brauchst.
Z.b.:
https://example.com
https://www.example.com
https://www.webservice.example.com
"example.com", "www.example.com" und "www.webservice.example.com" müssen eigenständige IP-Adressen haben.
Wenn Du keine Verschlüsselung brauchst, ist das schnuppe.
Viele Grüße,
Jörg
Moin Moin!
Zu Beachten ist allerdings, dass Du für Domains, die SSL-verschlüsselt werden sollen, jeweils eine eigene IP-Adresse brauchst.
Falsch. SNI kommt mit einer IP-Adresse für beliebig viele VHosts aus.
Alexander
Moin,
Falsch. SNI kommt mit einer IP-Adresse für beliebig viele VHosts aus.
Ui cool. Schau an, schau an, wieder was gelernt. Danke für den Hinweis.
Viele Grüße,
Jörg
Hello,
Falsch. SNI kommt mit einer IP-Adresse für beliebig viele VHosts aus.
Ui cool. Schau an, schau an, wieder was gelernt. Danke für den Hinweis.
Ja ist schon doll, dass eine Technik, die vor ca. 50 Jahren ersonnen wurde, die ganeze Zeit benutzt wurde, sich erst heute so richtig bemerkbar macht.
An die Notwendigkeit von IPV6 glaube ich noch nicht wirklich. Aber das müsste dann ja wenigstens 100 weitere Jahre ausreichen :-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Tach,
Falsch. SNI kommt mit einer IP-Adresse für beliebig viele VHosts aus.
Ui cool. Schau an, schau an, wieder was gelernt. Danke für den Hinweis.
dank Microsoft ist allerdings vermutlich noch lange nicht an einen Einsatz zu denken, der Internet Explorer unter Windows XP in egal welcher Version erhält dafür keinen Patch.
mfg
Woodfighter
Moin Moin!
dank Microsoft ist allerdings vermutlich noch lange nicht an einen Einsatz zu denken, der Internet Explorer unter Windows XP in egal welcher Version erhält dafür keinen Patch.
Ich erinnere mich noch an die ersten Webserver, die Name-based VHosts anboten. Wenn man da mit einem alten HTTP/1.0-Client aufschlug, bekam man nur die freundliche Mitteilung, dass man sich doch besser einen HTTP/1.1-Client suchen sollte.
Die gibt's übrigens immer noch, z.B. bei Strato:
echo -en "GET / HTTP/1.0\r\n\r\n" | nc antbase.net 80
HTTP/1.1 200 OK
Date: Fri, 02 Dec 2011 09:02:51 GMT
Server: Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/0.9.8r
Last-Modified: Wed, 22 Sep 2004 15:30:14 GMT
ETag: "bd18-3de-3e4af6c172d80"
Accept-Ranges: bytes
Content-Length: 990
Connection: close
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>Bitte benutzen sie nicht die IP Adresse des Servers</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<BR><BR><BR><BR>
<H1 ALIGN="CENTER">
Bitte benutzen sie nicht die IP Adresse des Servers, sondern immer
www.<Wunschname>.de !!
</H1>
<HR>
<DIV ALIGN="CENTER">
<TABLE BORDER="0">
<TR>
<TD ALIGN="center" colspan=2>
<A HREF="http://www.wunschname.de"><IMG SRC="http://www.strato.de/setup/images_setup/visual.gif" BORDER="0" ALT="www.WUNSCHNAME.de"></A>
</TD>
<TR></TR>
<TD ALIGN="center">
<A HREF="http://www.strato.de"><IMG SRC="http://www.strato.de/images/wir/navlinks/a.gif" HEIGHT="149" BORDER="0" ALT="STRATO AG"></A>
</TD>
</TR>
</TABLE>
</DIV>
</BODY>
</HTML>
(Und natürlich ist die Meldung von Stato technisch gesehen Quatsch, denn das Problem ist nicht die IP-Adresse des Webservers, sondern die Tatsache, dass der Client keinen Host-Header mitgeschickt hat.)
Warum also soll man das für SSL nicht genauso machen?
Bei tiggersWelt.net wird ein Standard-Zertifikat ausgeliefert, dass nicht zur angeforderten Domain paßt und damit eine Warnung provoziert.
Zitat: "Sofern der Client bzw. Browser keinen SNI-Support bietet, wird bei tiggersWelt.net das Standard-Zertifikat für ssl.tiggerswelt.net ausgeliefert, was in der Regel mit einer Warnung („CommonName stimmt nicht mit dem Hostname überein“) quittiert wird. Die Verbindung bleibt aber weiterhin verschlüsselt."
Es sollte möglich sein, in genau diesem Fall (SNI-unfähiger Client) nicht auf den eigentlich angeforderten Name-based VHost zuzugreifen, sondern stumpf wie oben eine Warnseite auszuliefern. Ob SNI benutzt wurde oder nicht, weiß der Webserver lange bevor die Regeln für die VHosts ausgewertet werden, also kann diese Information in die Entscheidung mit einfließen. Um die CommonName-Warnung kommt man damit natürlich nicht herum, aber anschließend kann man den Benutzer aufklären, dass er mit veralteter Software unterwegs ist.
Wer mag, kann dann noch den Browser erraten und beim vermutlich häufigsten Problem Internet Explorer auf altem Windows zu alternativen Browsern raten.
Alexander
Tach,
Es sollte möglich sein, in genau diesem Fall (SNI-unfähiger Client) nicht auf den eigentlich angeforderten Name-based VHost zuzugreifen, sondern stumpf wie oben eine Warnseite auszuliefern. Ob SNI benutzt wurde oder nicht, weiß der Webserver lange bevor die Regeln für die VHosts ausgewertet werden, also kann diese Information in die Entscheidung mit einfließen. Um die CommonName-Warnung kommt man damit natürlich nicht herum, aber anschließend kann man den Benutzer aufklären, dass er mit veralteter Software unterwegs ist.
das Problem ist, dass der User erstmal mit einer Warnung konfrontiert wird und nur falls er da entscheidet sie zu ignorieren, hast du überhaupt die Chance ihm zu erklären, was daran Schuld ist. Aus meiner Erfahrung würde ich sagen, der User wird deine Erklärung nie sehen und selbst wenn er sie sieht, wird das ohne externen Eingriff nichts ändern.
Wichtig ist auch, dass die Warnmeldung ja ihren Sinn hat; wir dürfen die User nicht darauf trainieren diese automatisch zu ignorieren!
mfg
Woodfighter
Moin Moin!
das Problem ist, dass der User erstmal mit einer Warnung konfrontiert wird und nur falls er da entscheidet sie zu ignorieren, hast du überhaupt die Chance ihm zu erklären, was daran Schuld ist. Aus meiner Erfahrung würde ich sagen, der User wird deine Erklärung nie sehen und selbst wenn er sie sieht, wird das ohne externen Eingriff nichts ändern.
Du hast recht, man muß sich erst einmal an der Zertifikat-Warnung vorbei arbeiten.
Wichtig ist auch, dass die Warnmeldung ja ihren Sinn hat; wir dürfen die User nicht darauf trainieren diese automatisch zu ignorieren!
Hmmm, ja, schon richtig.
Wenn ich aber so sehe, was der typische Mausschubser auf seinem Rechner hat, dann fällt die Zertifikat-Warnung in den Unmengen von sinnfreien Portscan-Alarmmeldungen vom "Alles wird sicher"-Snakeoil und den tausenden "beachte mich"-, "aktualisiere mich"- und "kauf die Vollversion"-Meldungen von irgendwelcher irgendwann mal mitinstallierten Software kaum noch auf. Die durchschnittlichen Benutzer *sind* bereits darauf trainiert, alles was nach Aufmerksamkeit schreit, ohne nachzudenken wegzuklicken.
(Was mich bei einer Kollegin aus der EDV echt auf die Palme treibt: Kommando starten, Fehlermeldung im Popup sofort ungelesen wegklicken, und dann fragen, warum das wieder nicht geht. Nicht ab und zu, sondern immer.)
Sauberer wäre natürlich, die Hinweis-Seite ohne Zertifikatswarnung auf den Schirm zu zaubern. Man müßte SSL/TLS mittendrin abbrechen und auf HTTP zurückfallen, um die Warnung zu vermeiden. Ob das geht, hab ich allerdings noch nicht nachgeforscht. Vermutlich nicht.
Alexander
Tach,
Sauberer wäre natürlich, die Hinweis-Seite ohne Zertifikatswarnung auf den Schirm zu zaubern. Man müßte SSL/TLS mittendrin abbrechen und auf HTTP zurückfallen, um die Warnung zu vermeiden. Ob das geht, hab ich allerdings noch nicht nachgeforscht.
ich kann mir auch nicht vorstellen, dass das möglich ist.
mfg
Woodfighter