hangar: lokale IP-Adressen im Netzwerk erreichen

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

  1. 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

    1. 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

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
      1. 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

        1. Moin Moin!

          Was spricht dagegen, es auszuprobieren?

          Alexander

          --
          Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
          1. Hallo,

            Was spricht dagegen, es auszuprobieren?

            Das es bisher theoretische Überlegungen/Planungen sind, wird erst in 1-2 Wochen losgehen.

            Danke

            1. 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

              --
               ☻_
              /▌
              / \ Nur selber lernen macht schlau
              http://bergpost.annerschbarrich.de
  2. 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

    1. 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

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
      1. 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

        1. 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

          --
           ☻_
          /▌
          / \ Nur selber lernen macht schlau
          http://bergpost.annerschbarrich.de
        2. 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

          1. 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.&lt;Wunschname&gt;.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

            --
            Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
            1. 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

              1. 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

                --
                Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
                1. 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