Das einfachste Setup beim Internet Information Server 6 besteht aus einer normalen Installation des IIS in einem Rechner mit einer Netzwerkkarte – beim Multi-Homing können jedoch durchaus Fälle eintreten, bei denen mehrere Karten sinnvoll sind. Zunächst gehen wir aber einmal auf das „einfache“ Setup ein.
Um im Rahmen einer Domäne einen WWW-Dienst anzubieten, muss für diesen Dienst im DNS die IP-Adresse eines Rechners eingetragen sein. Damit der IIS diese Webseite auch identifizieren kann, geben Sie im einfachsten Fall genau die gleiche IP-Adresse für die Webseite an.
Gelangen nun Anfragen zum IIS, die an diese IP-Adresse gerichtet sind, beantwortet er diese Anfragen mit den Inhalten der zugeordneten Site. Allerdings müssen die Anfragen erst einmal bis zum IIS durchkommen. Das tun Sie nur dann, wenn sich die externe Netzwerkkarte des Rechners ebenfalls für diese IP-Adresse verantwortlich fühlt. Im einfachsten Fall ist das von Haus aus so, denn schon bei der Installation des Netzwerks selbst haben Sie vermutlich diese IP-Adresse verwendet: Daher kommt es überhaupt, dass diese eine Adresse überall im System auftaucht.
Das einfachste Setup
Das einfachste denkbare Setup sieht folgendermaßen aus. Es gibt nur eine einzelne IP-Adresse, nur eine Website und nur eine Netzwerkkarte – von Komplexität keine Spur. Das ändert sich aber schnell, wenn Sie mehr von Ihrem IIS wollen und zur ersten Website eine zweite hinzufügen möchten.
Dazu haben Sie im Wesentlichen zwei mögliche Wege. Entweder Sie machen die zusätzliche Webseite unter der gleichen IP-Adresse erreichbar wie die erste oder Sie vergeben an die zweite Site eine andere Adresse.
Im Normalfall geben Sie am besten der zweiten Site die gleiche Adresse. Das ist durch einen entsprechenden DNS-Eintrag für die zusätzliche Domain einfach möglich. Wie Sie gleich sehen werden, ist eine Konfiguration, bei der mehrere Webserver aus unterschiedlichen Domains die gleiche IP-Adresse haben, mit dem IIS leicht zu bewältigen.
Allerdings: Es gibt auch durchaus Gründe, der neuen Website eine andere IP-Adresse zu geben. Einer davon ist eine gute Planung für die Zukunft, denn unter Umständen möchten Sie ja später nicht nur zwei, sondern wesentlich mehr Websites hosten. Und diese multiplen Sites werden Sie dann schon allein auf Grund der besseren Übersicht nach IP-Adressen gruppieren wollen. So könnten Sie zum Beispiel alle eigenen Sites unter einer Adresse und die von Kunden unter einer anderen Adresse anbieten.
Ein anderer Grund, wohl der häufigere, ist der, dass alle Webseiten eines Kunden die gleiche Adresse haben sollen – die Sites der Kunden untereinander sollen aber unterschiedliche Adressen haben. Das Resultat: Jeder Kunde bekommt eine IP, unter der dann alle seine Angebote gehostet werden.
Zwei Websites: Der einfache Fall
Doch zunächst der einfache Fall. Dabei würden Sie eine zusätzliche Webseite betreiben, die der Einfachheit halber unter der gleichen IP erreichbar sein soll. Die Namen der Sites sind also eigentlich nur für den Surfer gedacht – der kann dann zum Beispiel unter www.MeineDomain.de das normale Internet-Angebot betrachten und findet gleichzeitig unter www.MeineBetas.de Ihre Beta-Test-Angebote oder auch unter forum.MeineDomain.de ein Diskussionsforum rund um Ihre Dienstleistungen oder Vergleichbares. Eine Konfiguration mit und ohne „www“ ist ähnlich gelagert. Dabei bekommt der Surfer unter www.MeineDomain.de das gleiche Angebot wie unter MeineDomain.de.
Für eine solche Konfiguration setzen Sie die so genannten „Host-Header“ ein. Dazu müssen Sie aber zunächst einmal wissen, was diese Host-Header eigentlich sind und wie sie funktionieren. Damit eine Anfrage an einen Webserver überhaupt ein Ergebnis liefert, muss es für den Webserver einen DNS-Eintrag geben. Dabei kann der Rechner unter verschiedenen Host-Namen im DNS bekannt sein. So zum Beispiel unter www.MeineDomain und unter MeinDomain.de.
Im einfachsten Fall verweisen die Einträge für beide Hosts auf die gleiche IP-Adresse eines Ihrer Rechner, und eine Anfrage an diese Hosts landet dann bei Ihrer IIS-Installation. Eine Anfrage an den Webserver enthält die unterschiedlichsten Daten. Unter anderem gehört dazu auch ein Feld mit der Information, welcher Host eigentlich gemeint ist. Der Name des befragten Hosts steht also nicht nur in der URL, sondern auch im Header der http-Anfrage des Browsers: Genau dieses Feld ist der Host-Header.
Host-Header einsetzen
Die Zuordnung im IIS erfolgt normalerweise von IP-Adresse zu Website, es gibt aber auch die Möglichkeit, eine Zuweisung von einem Host-Header zu einer Site anzulegen. Im Normalfall liefert der IIS also Daten von einer Site aus, die er über die IP-Adresse identifiziert. Sind hingegen Host-Header konfiguriert, so überprüft der IIS zunächst, ob es eine Website gibt, die zum Host-Header aus der Anfrage passt. Ist das der Fall, wird diese Webseite verwendet, um die Daten an den Browser auszuliefern.
Die Konfiguration von Host-Headern nehmen Sie im Dialog zum Einstellen der Eigenschaften einer Webseite vor. Sie gehen dazu auf den Reiter Web Site. Dort finden Sie die von Haus aus eingetragene IP-Adresse der Site. Diese stammt von der Domain, für die diese Website gedacht ist. Hinter dem Textfeld für die IP-Adresse finden Sie zusätzlich einen Button mit der Beschriftung Advanced. Dieser öffnet einen Dialog, über den Sie weiter gehende Einstellungen vornehmen können.
Der Dialog erlaubt drei Angaben: Es ist möglich, eine IP-Adresse, eine Portnummer und einen Host Header Value einzutragen. Diese drei Angaben schnürt der IIS dann zu einem Paket zusammen und verwendet dieses als Identifizierungsmerkmal für eine bestimmte Website. Dabei können Sie den IIS dazu veranlassen, beliebig viele von diesen Paketen zu erstellen, indem Sie einfach weitere Sammlungen aus diesen drei Angaben anlegen. Auf diese Weise sind Sie in der Lage, sehr flexibel auf http-Anfragen zu reagieren.
Host-Header, IP und Port bilden ein Päckchen
Als IP-Adresse geben Sie dabei die IP-Adresse ein, bei der die Anfragen für die Webseite eingehen. Als Portnummer vergeben Sie 80, also den Standardport für http. Auf Wunsch können Sie auch eine andere Portnummer eingeben, denn die Portnummer ist eine weitere Möglichkeit, Multi-Homing zu betreiben. Allerdings eine wenig benutzerfreundliche – denn der Surfer muss die Portnummer bei der URL mit angeben, um die Site zu erreichen. Das werden aber nur die wenigsten Internet-Benutzer beim Ansurfen einer Seite erwarten.
Schließlich geben Sie den Host-Header-Wert an und klicken auf OK – Ihr Päckchen taucht dann in der Liste der Identitäten Ihrer Website auf. Dabei sollten Sie von Haus aus für jede Website zumindest eine Variante mit komplettem Host-Namen (inklusive „www.“) und eine Variante ohne „www.“ anlegen. Unter der Voraussetzung, dass Sie sich auch um einen entsprechenden DNS-Eintrag bemühen, können die Surfer dann beide Sites sowohl mit als auch ohne vorangestelltes „www.“ erreichen.
Komplizierter: Unterschiedliche IPs
Etwas aufwendiger wird die Sache, wenn Sie unterschiedliche IP-Adressen für die beiden Seiten verwenden möchten. Auf den ersten Blick erscheint es so, als müssten Sie dafür nicht viel tun. Letztlich können Sie die IP-Adresse der Site ja einfach in den Eigenschaften der Website im IIS eintragen – und man könnte meinen, dass die Arbeit damit erledigt ist. Das ist sie aber nicht, denn in diesem Fall fehlt noch ein Arbeitsschritt.
Angenommen Sie haben die zweite Website bereits angelegt, sich um einen passenden DNS-Eintrag gekümmert und die IP-Adresse im Eigenschaftendialog der Site eingetragen: Woran kann es dann noch liegen, dass Anfragen an diese Site nicht beantwortet werden? Ganz einfach: Der IIS weiß dann zwar, dass Anfragen an die zweite IP-Adresse zur zweiten Site gehen sollen – er sieht diese Anfragen aber gar nicht erst.
Der Grund ist so offensichtlich, dass man ihn gern übersieht, zumindest ist das dem Autoren schon häufiger passiert. Es reicht nun mal nicht, dem IIS mitzuteilen, dass eine Site und eine IP zusammengehören, man muss auch dem Windows-Networking mitteilen, dass es sich um eine zusätzliche IP kümmern soll.
Wichtig: Netzwerk nicht vergessen
Per Default wird Ihr Windows-Server so konfiguriert sein, dass er mit einer Netzwerkkarte ans Internet angeschlossen ist – und diese Netzwerkkarte hat von Haus aus nun mal nur eine IP-Adresse, beispielsweise die 194.77.231.40. Dementsprechend lautet die IP-Adresse der ersten Website auf dem Server mit Sicherheit auch 194.77.231.40. Mit dieser Site haben Sie dann garantiert keine Probleme.
Für die zusätzliche Website verwenden Sie nun aber zum Beispiel die Adresse 194.77.231.41. In diesem Fall kommen Anfragen an diese IP-Adresse niemals an, denn die Netzwerkkarte weiß ja gar nicht, dass sie Pakete an diese Adresse ebenfalls bearbeiten soll. Sie müssen der Karte diesen Umstand also erst einmal mitteilen, und das ist der fehlende Arbeitsschritt.
TCP konfigurieren
Lange Rede, kurzer Sinn: Zusätzlich zur Konfiguration der neuen Site im IIS müssen Sie auch die Konfiguration Ihrer Netzwerkkarte ändern. Das geht einfach über den Dialog zur Einstellung der Eigenschaften der Karte beziehungsweise zur Einstellung von TCP/IP, die Sie auf diesem Dialog finden.
Wenn Sie den Eigenschaftendialog für TCP/IP öffnen, finden Sie dort zunächst die bereits eingetragene IP-Adresse und die zugehörige Subnetzmaske. Links unten im Dialog finden Sie aber wieder einen Button Advanced. Dieser öffnet einen neuen Dialog, mit dem Sie die zusätzlich benötigten Angaben machen können. Auf dem Reiter IP Settings tragen Sie dazu die zusätzliche IP-Adresse und deren Subnetzmaske ein. Diese landet in der Liste der IP-Adressen, für die sich die Netzwerkkarte zuständig fühlt. Kaum ist das erledigt, kommen die Anfragen auch beim IIS an – und der liefert dann wie gewünscht die zweite Webseite aus.
Interface schützen
Nun sollten Sie sich aber auch darum bemühen, dass das physische Interface gegen Angriffe von außen geschützt wird – und das sollten Sie mit dem IP-Routing-Teil von „Routing and Remote Access“ tun: Im Gegensatz zur Desktop Firewall von XP SP2, die in minimal veränderter Form auch Bestandteil des Server 2003 ist, finden Sie dort die „richtige“ Firewall für Ihren Server.
Um diese Firewall zu aktivieren, gehen Sie in der Systemsteuerung auf „Routing and Remote Access“, dort in den Ast „IP-Routing“ und von dort in den Ast „NAT/Basic Firewall“. Dabei erhalten Sie eine Liste aller Interfaces in Ihrem System – im Falle einer einzelnen Netzwerkkarte enthält diese Liste eben genau diese eine Netzwerkkarte.
Bei deren Eigenschaften aktivieren Sie dann auf dem Reiter „NAT/Basic Firewall“ die Option „Basic Firewall only“. Ab diesem Zeitpunkt kommen überhaupt keine Anfragen mehr bei Ihrem IIS an. Das ist natürlich nicht wünschenswert. Sie müssen also eine Ausnahme konfigurieren – und mit dieser Ausnahme stehen Sie dann vor dem nächsten Problem beim Multi-Homing: Auf dem Reiter „Services and Ports“ finden Sie zwar eine Liste der auf Ihrem Rechner als Ausnahmen zu behandelnden Dienste, und einer davon ist auch der „Web Server (HTTP)“. Wenn Sie diese Option aber einschalten und damit den HTTP-Dienst als Ausnahme konfigurieren, klappt trotzdem nicht alles so, wie Sie sich das wünschen würden. Stattdessen kommen zwar Anfragen an Ihre erste Webseite beim IIS an, auf Anfragen an die zweite Site erhalten Sie jedoch keine Antworten.
Neuen Dienst freigeben
Der Grund für das Problem wird klar, wenn Sie mit dem Button „Edit“ einen Blick auf die Eigenschaften von „Web Server (HTTP)“ werfen: Dort ist nämlich explizit die erste IP-Adresse Ihres Systems eingetragen. In Folge dessen werden Anfragen an die andere IP-Adresse direkt verworfen und kommen darum nicht beim IIS an. Mit „Web Server (HTTP)“ ist nämlich nicht gemeint „Alle Anfragen, die auf Port 80 hereinkommen und HTTP darstellen“, sondern „HTTP-Anfragen auf die Default-IP-Adresse“. Mit anderen Worten: Der IP-Filter weiß nicht, für welche IP-Adressen sich der IIS verantwortlich fühlt, und darum gilt die Regel nur für die erste Adresse des Systems.
Sie müssen also per „Add“ einen neuen Dienst in die Liste eintragen. Für diesen Dienst geben Sie die zweite IP-Adresse als „Private Address“ an, spezifizieren für ein- und ausgehenden Port die 80 und legen als „Public Address“ den Wert „On this interface“ fest. Dann geben Sie auch diesen Dienst frei – und nun werden auch Anfragen an die zweite Website vom IIS korrekt beantwortet.
Mehrere Netzwerkkarten
Es gibt noch eine weitere Spielart fürs Multi-Homing, und das ist die, bei der Sie mehrere Netzwerkkarten verwenden. Grundsätzlich ist der Einsatz mehrerer Karten gar nicht notwendig – es gibt aber durchaus Fälle, bei denen Sie dies nicht verhindern können. Ein solcher Fall tritt zum Beispiel ein, wenn Sie nur eine einzelne Installation des IIS verwenden möchten, um sowohl eine lokale Intranet-Site als auch öffentliche Sites zu hosten.
Der Zugang zu den Intranet-Sites wird dabei oft so geregelt sein, dass die Verbindung des Intranets zum IIS-Rechner über eine separate Netzwerkkarte erfolgt. Der IIS Rechner hängt also mit einem physischen Interface am Internet oder zumindest am Gateway Richtung Internet und mit dem anderen Interface an einem Gateway Richtung LAN.
Hier müssen Sie also zunächst beide Netzwerkkarten so konfigurieren, dass diese sich auch für die passenden IP-Adressen verantwortlich fühlen. Ist das erledigt, so haben Sie danach zwei Möglichkeiten:
Sie konfigurieren die Sites im IIS so, dass es solche für öffentliche und solche für private Adressen gibt.
Sie lassen den IIS nur auf eine einzelne Adresse horchen und biegen die Pakete dann im „Routing and Remote Access“ von der äußeren IP-Adresse auf diese eine „private“ Adresse um.
Letzteres ist allerdings ein bisschen umständlich und schlägt obendrein fehl, wenn Sie im Rahmen der Website auch FTP-Anfragen beantworten wollen: Diese lassen sich vom „Routing and Remote Access“ nicht auf eine andere Adresse umbiegen.
Schließlich sollten Sie beim Multi-Homing noch berücksichtigen, wie die Webanwendungen Ihrer Websites betrieben werden. Eine Webanwendung ist in diesem Zusammenhang eine Anwendung, die Sie mit ASP.Net 1.0/1 oder ASP.Net 2.0/Beta entwickelt haben.
Application-Pools anlegen
Von Haus aus werden beim IIS alle Anwendungen innerhalb eines Prozesses betrieben. Dazu legt die IIS Installationsroutine den „DefaultAppPool“ an, und innerhalb dieses Pools (der eigentlich einen Prozess verkörpert) laufen dann die einzelnen Anwendungen.
Das hat interessante Auswirkungen: Läuft eine der Anwendungen Amok und blockiert den Prozess, dann sind dadurch auch die anderen Anwendungen blockiert. Das sollten Sie allerdings möglichst vermeiden, indem Sie einen eigenen AppPool anlegen. Zumindest jede Ihrer Sites sollte dabei einen eigenen bekommen. Auf diese Weise kann zwar eine einzelne Site abstürzen, das stört aber nicht den Betrieb der anderen Sites.
Besser ist es allerdings, für jede Webanwendung einen eigenen AppPool anzulegen, denn über diesen können Sie auch die der Anwendung zugestandenen Ressourcen konfigurieren und damit besser Einfluss auf die Antwortzeiten des Servers nehmen.
In diesem Beitrag haben Sie erfahren, dass der IIS eine ganze Palette an Möglichkeiten für das Hosten von mehreren Websites oder aber für das Abbilden der gleichen Inhalte unter verschiedenen Host-Namen bietet. Wenn Sie dies irgendwie bewerkstelligen können, so sollten Sie sich immer für die einfachste Art der Konfiguration entscheiden: Mit einer Netzwerkkarte und einer IP-Adresse für alle WWW-Angebote ist die Arbeit schlicht und ergreifend am schnellsten erledigt und bleibt auch am übersichtlichsten. (mha)