Routing nach Host-Header unter Windows
Karl-Heinz Epple
ich suche nach einer eleganten M�glichkeit, hobbym�ssig auf einem Windows
Home (2003) Server mehrere Domains zu hosten.
Der Internet Information Server l�sst sich nicht so konfigurieren, wie ich
das gerne h�tte. Muss aber bleiben.
Von einem Reverse-Proxy via Apache oder Squid habe ich f�rs erste Abstand
genommen, nachdem ich mich in die Problematik eingelesen habe.
Gibt es f�r Windows Server 2003 eine (nat�rlich) kostenlose (Personal)
Firewall, die schlicht anhand der Host-Header auf unterschiedliche IPs
intern routen kann?
Danke f�rs Lesen,
K.-H.
Juergen Ilse
Karl-Heinz Epple <lovel...@nsw.ath.cx> wrote:
> ich suche nach einer eleganten Möglichkeit, hobbymässig auf einem Windows
> Home (2003) Server mehrere Domains zu hosten.
Das Stichwort lautet "named virtual host" und hat rein gar nichts mit
Firewalls zu tun ...
> Der Internet Information Server lässt sich nicht so konfigurieren, wie ich
> das gerne hätte. Muss aber bleiben.
Wie soll der denn konfiguriert werden? Der kann sehr wohl "named virtual
hosts", auch wenn ich dir jetzt nicht genau sagen kann, wie das einzustellen
ist, das es schon laenger her ist, dass ich das mal machen musste ...
> Von einem Reverse-Proxy via Apache oder Squid habe ich fürs erste Abstand
> genommen, nachdem ich mich in die Problematik eingelesen habe.
Was willst du denn ueberhaupt erreichen?
> Gibt es für Windows Server 2003 eine (natürlich) kostenlose (Personal)
> Firewall, die schlicht anhand der Host-Header auf unterschiedliche IPs
> intern routen kann?
Was soll dir denn eine Firewall dabei helfen? Konfiguriere deinen IIS
so dass ddeine verschiedenen virtuellen Hosts als "named virtual hosts"
laufen, dann brauchst du sowas nicht.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Karl-Heinz Epple
Hi,
> Wie soll der denn konfiguriert werden? Der kann sehr wohl "named virtual
> hosts", auch wenn ich dir jetzt nicht genau sagen kann, wie das einzustellen
> ist, das es schon laenger her ist, dass ich das mal machen musste ...
>
>> Von einem Reverse-Proxy via Apache oder Squid habe ich f�rs erste Abstand
>> genommen, nachdem ich mich in die Problematik eingelesen habe.
>
> Was willst du denn ueberhaupt erreichen?
Der Knackpunkt war "SSL host headers cannot be configured by using the IIS
[6] Manager UI."
Weil ich diese Funktionalit�t im GUI nicht fand, dachte ich, die gibt es im
IIS 6 eben noch nicht.
>> Gibt es f�r Windows Server 2003 eine (nat�rlich) kostenlose (Personal)
>> Firewall, die schlicht anhand der Host-Header auf unterschiedliche IPs
>> intern routen kann?
>
> Was soll dir denn eine Firewall dabei helfen? Konfiguriere deinen IIS
> so dass ddeine verschiedenen virtuellen Hosts als "named virtual hosts"
> laufen, dann brauchst du sowas nicht.
Ich wollte die nicht vorhandene Problematik dadurch erschlagen, dass ich
eine M�glichkeit finde, schon vor dem Webserver die Anfragen auf
unterschiedliche interne IPs umzuleiten. ISA oder die Kerio WinRoute k�nnen
das und ich hatte ein �hnliches kommerzielles Produkt kostenlos f�r
Privaties im Hinterkopf, von dem ich vor 1 oder 2 Jahren geh�rt hatte, aber
nat�rlich keine Notizen mehr habe.
Egal, kann ja erstmal weiter frickeln.
Gruss,
K.-H.
Juergen Ilse
Karl-Heinz Epple <lovel...@nsw.ath.cx> wrote:
> Am 30 Dec 2009 18:54:15 GMT schrieb Juergen Ilse:
>> Was willst du denn ueberhaupt erreichen?
>
> Genau das:
> http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/596b9108-b1a7-494d-885d-f8941b07554c.mspx
>
> Der Knackpunkt war "SSL host headers cannot be configured by using the IIS
> [6] Manager UI."
Da hilft dir auch kein reverse-Proxy oder dergleichen weiter. Die Kombination
IP-Adresse + Port muss fuer jeden HTTPS-Server eindeutig sein, sonst bekommst
du ein "Henne-EI" Problem: Der SSL-Handshake findet bei HTTPS statt, *bevor*
der HTTP-Header uebertragen wird. Zu diesm Zeitpunkt ist die Information,
welcher virtuelle Server angesprochen werden soll, also noch gar nicht bekannt.
Genau diese Information wird aber vom Server benoetigt, um zu entscheiden,
welches SSL-Zertifikat fuer die Verbindung zu verwenden ist. Dieses Dilemma
fuer HTTPS-Serrver laesst sich nicht loesen, solange man bei diesem Protokoll
bleibt. Es gibt zwar einen RFC, der dieses Dilemma auch ohne "eigene IP-
Adresse pro virtuellem HTTPS-Server" loesen koennte, aber die darin vorge-
schlagenen Protokollerweiterungen werden von vielen Browsern noch nicht
unterstuetzt, so dass das bislang eher nur wenig hilfreich waere ...
>>> Gibt es für Windows Server 2003 eine (natürlich) kostenlose (Personal)
>>> Firewall, die schlicht anhand der Host-Header auf unterschiedliche IPs
>>> intern routen kann?
>> Was soll dir denn eine Firewall dabei helfen? Konfiguriere deinen IIS
>> so dass ddeine verschiedenen virtuellen Hosts als "named virtual hosts"
>> laufen, dann brauchst du sowas nicht.
> Ich wollte die nicht vorhandene Problematik dadurch erschlagen, dass ich
> eine Möglichkeit finde, schon vor dem Webserver die Anfragen auf
> unterschiedliche interne IPs umzuleiten.
Im Prinzip eine gute Idee, bei HTTPS verlagerst du das Problem jedoch nur
auf den vorgeschalteten Proxy, du loest es nicht (weil es sich nicht loesen
laesst). Und mit Firwalls hat das immer noch nichts zu tun.
> ISA oder die Kerio WinRoute können das
Nicht das, was du zu wollen scheinst.
Juergen Ilse
Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
> Karl-Heinz Epple <lovel...@nsw.ath.cx> wrote:
>> Am 30 Dec 2009 18:54:15 GMT schrieb Juergen Ilse:
>>> Was willst du denn ueberhaupt erreichen?
>> Genau das:
>> http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/596b9108-b1a7-494d-885d-f8941b07554c.mspx
>>
>> Der Knackpunkt war "SSL host headers cannot be configured by using the IIS
>> [6] Manager UI."
>
> Da hilft dir auch kein reverse-Proxy oder dergleichen weiter. Die Kombination
> IP-Adresse + Port muss fuer jeden HTTPS-Server eindeutig sein, sonst bekommst
> du ein "Henne-EI" Problem: Der SSL-Handshake findet bei HTTPS statt, *bevor*
> der HTTP-Header uebertragen wird. Zu diesm Zeitpunkt ist die Information,
> welcher virtuelle Server angesprochen werden soll, also noch gar nicht bekannt.
Nachtrag: Mittels Wildcard-Zertifikat )dessen zugehoeriger NAme auf *alle*
Namen der vortuellen HTTPS-Server matched) koennte man das von mir ange-
sprochene Problem zwar loesen, aber das steht ja auch schon in jenem Artikel
bei M$ auf der Website ... Ich vermute, dass du eben *nicht* auf die Loesung
mit dm wildcard-Zertifikat hinauswillst.
> Genau diese Information wird aber vom Server benoetigt, um zu entscheiden,
> welches SSL-Zertifikat fuer die Verbindung zu verwenden ist. Dieses Dilemma
> fuer HTTPS-Serrver laesst sich nicht loesen, solange man bei diesem Protokoll
> bleibt. Es gibt zwar einen RFC, der dieses Dilemma auch ohne "eigene IP-
> Adresse pro virtuellem HTTPS-Server" loesen koennte, aber die darin vorge-
> schlagenen Protokollerweiterungen werden von vielen Browsern noch nicht
> unterstuetzt, so dass das bislang eher nur wenig hilfreich waere ...
Bei der Loesung mittels "wildcard-Zertifikat" tritt das Problem nur deswegen
nicht auf, weil fuer alle HTTPS-Server das selbe Zertifikat verwendet wird,
und somit die Entscheidung welches Zertifikat zu nutzen ist nicht anfaellt.
Wenn nicht alle Servernamen in der selben Domain liegen, und fuer diese
Domain ein Wildcard-Zertifikat vorliegt, entfaellt aber diese Moeglichkeit.