Good news! Ein Apache SSL-virtual host hört nun auf seinem Port. Es gab ein Paar Kniffe, die mit Win vs. Unix zu tun haben und einen ahnungslosen Anfänger (wie mich) in die Verzweifelung treiben können. Ist aber nun gelöst.
Falls jemand sowas nachbauen will, stehe ich zur Verfügung.
Das Entscheidende habe ich aber noch nicht gewagt: die Weiterleitung des cryptographierten Apache Virtual Host an den IPS-Webserver mittels Reverse Proxy. Mehr dazu folgt…
Also ich versuche es mal taktvoll, ich will Dir wirklich nichts boeses. Aber Deine Aussage ist so haarstraeubend fahrlaessig falsch und Du laesst auch irgendwie keine Argumente anderer gelten. Wenn Dir einer was boeses ist will ist es voellig wurscht welche Adressen Du hast.
Das kannst Du jetzt glauben oder aber auch nicht, es Dir weiter zu erklaeren wuerde den Rahmen hier sprengen.
Man kann ja auch den Adressblock 10.0.0.0/8 nehmen - da hat man auch sehr leicht zu merkende Adressen. Und genug Reserver-Adressen für zu Hause auch gleich:rolleyes:
Und dann nie wieder Raum das netz in zwei (oder mehrere) Subnetze zu teilen ohne gleich dann doch einen halboffiziellen 130er oder 172.16/192.168er range zusätzlich dazu zu nehmen.
Lösung: Man fängt im Hausgebrauch mal mit mit nem 10.x.x.0/24 an und kann dann entweder ein /23er draus machen (Falls einem 254 IP Adressen nicht reichen) oder aber ein 10.x.y.0/24er aufmachen.
Zur Vervollständigung: im httpd.conf müssen noch folgende Einträge rein:
<Proxy *>
AuthName "Can Be Anything, shows in dialog"
AuthType Basic
AuthUserFile "/path/to/.htpasswd"
Require valid-user
Order deny,allow
Deny from all
Allow from some.ip.address
</Proxy>
Damit wird festgelegt, dass alle externen User (welche durch den Proxy müssen) sich zwingend authentifizieren müssen. Das Ergebnis ist ein IPS-WebServer, welcher im LAN frei zugänglich ist, von aussen jedoch nur über Authentifizierung (basic oder digest, wie man es mag) und encrypted.