Sollen mehrere, unterschiedliche IP-Adressen auf einem Windows-System zum Einsatz kommen, taucht zwangsläufig der Begriff Multihoming auf. Bei dieser Technik geht es grundsätzlich darum, dass auf einem Computersystem mehrere IP-Adressen oder auch Netzwerkkarten verwendet werden. Die bekannteste Spielart dürfte dabei der Einsatz mehrerer Netzwerkkarten in einem Serversystem sein - eine Konfiguration, die heute fast schon zum Standard gehört.
Auf diese Weise können die Netzwerkadapter dann beispielsweise so konfiguriert werden, dass sie die gleiche IP-Adresse verwenden. Dadurch funktioniert die Netzwerkverbindung auch dann noch, wenn eine der Karte defekt ist. Ebenso gut ist es natürlich möglich, mehrere Netzwerkkarten so zu konfigurieren, dass sie mit verschiedenen Internetzugangspunkten beziehungsweise Routern verbunden sind. Mit solch einer Konfiguration kann dann beispielsweise eine größere Bandbreite durch den Einsatz mehrerer Router erreicht werden.
Eine andere bekannte Form des Multihoming funktioniert auch mit einer einzelnen Netzwerkkarte: Dabei werden diesem einen Netzwerkadapter mehrere IP-Adressen zugeordnet. So findet sich bereits bei Windows XP in den erweiterten TCP/IP-Einstellungen die Möglichkeit, IP-Adressen hinzuzufügen.
Durch diese Vorgehensweise ist es beispielsweise auch möglich, den von anderen Systemen ankommenden Netzwerkverkehr besser und vor allen Dingen feiner granuliert zu kontrollieren. Mit IPv6 stehen dann noch erweiterte Möglichkeiten zur Verfügung, um Multihoming-Techniken besser einzusetzen. Auch wenn es um den mobilen Einsatz von Systemen und Anwendungen geht, ist Multihoming im Einsatz: Der Wechsel zwischen verschiedenen Netzwerken, wie er beim mobilen Einsatz häufig nötig ist, lässt sich so weitaus einfacher durchführen.
TCP/IP-Stack im Wandel: von schwachen und starken Host-Modellen
Kommen auf einem Rechner mehrere IP-Adressen zum Einsatz, so ist mit einem Blick in die Netzwerkeinstellungen nicht immer sofort ersichtlich, welche der zur Verfügung stehenden IP-Adressen beispielsweise dann an der Reihe ist, wenn der Rechner Netzwerkpakete verschickt. Der Netzwerk-Stack verwendet dazu einen Vorgang, der als Source IP Address Selection (Adressauswahl für die Quell-IP) bezeichnet wird.
Die Übergabe der lokalen IP-Adresse, also der Source-IP, geschieht dann, wenn mittels Windows Sockets eine entsprechende Verbindung aufgebaut wird. Bis zu den Versionen Windows XP und Windows Server 2003 setzten die Microsoft-Entwickler hier auf ein sogenanntes "schwaches Hostmodell" für alle IPv4-Netzwerkschnittstellen: Diese Vorgehensweise gab Entwicklern größtmögliche Freiheiten, wenn sie Programme entwarfen, die Netzwerkzugriffe ausführten.
Allerdings verlagert dieses Modell auch die Verantwortung für die Art und Weise, wie sich das Netzwerkprogramm verhält, komplett auf die Entwickler: Sie legten fest, auf welche Art ihr Programm auf den TCP/IP-Stack zugriffen hat, und auch, wie das Programm sowohl ein- als auch ausgehende Netzwerkpakete abarbeitete.
Der IP-Stack muss jedes Mal, wenn auf dem System ein Unicast-Paket eintrifft, entscheiden, ob das Paket an den lokalen Computer gesendet wurde. Dass trifft grundsätzlich dann zu, wenn das Ziel dieses Pakets mit einer der Adresse übereinstimmt, die einer Netzwerkschnittstelle des Systems zugewiesen wurde. Bei einem schwachen Host-Modell wird jedes Paket akzeptiert, das an dieses lokale System geschickt wurde. Das ist dabei völlig unabhängig davon, über welche der Schnittstellen dieses Paket empfangen wurde. So bietet das schwache Host-Modell zwar im Prinzip eine bessere Netzwerkkonnektivität, doch dafür das System ist weitaus anfälliger für bestimmte Formen der Netzwerkangriffe: So kann ein Angreifer von außerhalb Netzwerkpakete an dieses System senden, die dann Dienste angreifen, die eigentlich nur für Rechner im Intranet erreichbar sind.
Beginnend mit dem neuen TPC / IP-Stack in Windows Vista hat Microsoft alle Windows-Systeme mit einem starken Host-Modell ausgestattet. Bei dieser Implementierung sind Sende- und Empfangsverhalten anders: Pakete an den lokalen Computer werden nur dann akzeptiert, wenn die Adresse, an die das Paket gesendet wurde, mit der Adresse der Schnittstelle übereinstimmt, über die das Paket auch empfangen wurde. Standardmäßig wird auf allen aktuellen Windows-Systemen die Einstellung so gewählt, dass dieses starke Host-Modell zum Einsatz kommt. Allerdings können Administratoren die Einstellung auch explizit verändern. Dazu stehen entsprechende netSh-Kommandos bereit, die sowohl eingehende (WeakHostReceive) als auch ausgehende (WeakHostSend) Pakete betreffen:
netsh interface IPv4 set interface <Name_Netzwerkschnittstelle> WeakHostSend=enabled Ok
netsh interface IPv4 set interface <Name_Netzwerkschnittstelle> WeakHostReceive=enabled Ok
Dabei steht "Name_Netzwerkschnittstelle" für den Adapter, auf dem diese Einstellung vorgenommen werden soll. Wollen Sie wieder zur Standardeinstellung zurückkehren, so gelingt das mit den gleichen Aufrufen, nur dass in diesem Fall disabled verwendet werden muss. Wer sich noch tiefer in die technischen Hintergründe zum Thema "Host-Modell" einarbeiten möchte, findet im "Cable Guy Blog" auf Microsofts TechNet einen schon etwas älteren englischsprachigen Artikel, der detailliert die Aspekte rund um schwache und starke Host-Modelle darstellt.
Wo und wie werden IP-Adressen auf dem System registriert?
Zurück zu den mehr praktischen Aspekten: Fragt man einen Administrator danach, an welcher Stelle die IP-Adressen eines Windows-Systems registriert werden, so fällt die Antwort eindeutig aus: Sie werden im DNS registriert. Das passiert fast immer automatisch, da bei allen Windows-Systemen (schon bei Windows XP) in den erweiterten TCP / IP-Eigenschaften beim Eintrag Adressen dieser Verbindung in DNS registrieren der Haken standardmäßig bereits gesetzt ist.
Wenn es um Systeme geht, in denen nur eine Netzwerkkarte mit einer IP-Adresse zum Einsatz kommt, funktioniert diese Art der Einstellung hervorragend. In diesem Fall ist es auch von Vorteil, dass etwaige Änderungen an der IP-Adresse auf diese Weise sofort und automatisch ins DNS übertragen werden. Auch mit zwei Netzwerkkarten, die mit unterschiedlichen IP-Adressen arbeiten, lässt sich so noch gut arbeiten: Eine gängige Konfiguration besteht darin, dass eine der beiden Karten für den "normalen" Netzwerkverkehr regelt, während die zweite Netzwerkkarte nur für den Remote-Zugriff des Administrators oder auch Backup-Aufgaben reserviert wird - die üblichen Anwender sollen hier kein Zugriff haben.
Der Systembetreuer kann der zweiten Karte den Haken bei der DNS-Option wegnehmen, sodass diese Karte nicht registriert wird. Die Anwender können dann den Namen dieses Servers mit der IP-Adresse nicht mehr auflösen, ein Routing zu dieser Schnittstelle wäre von ihnen aus nicht möglich. Eine solche Lösung ist leicht zu installieren und kommt in der Praxis relativ häufig zum Einsatz.
Wird allerdings ein System mit einer Netzwerkkarte eingesetzt, die mit mehreren IP-Adressen verbunden ist, wie es beispielsweise bei einem Webserver der Fall ist, der mehrere unterschiedliche Websites beherbergt, dann ist das mit diesen Konfigurationsmöglichkeiten nicht so leicht machbar: Wollte der Administrator bei Systemen bis Windows XP und Windows Server 2003 erreichen, dass nicht alle, sondern nur bestimmte IP-Adresse im DNS registriert werden, so musste er zunächst diese Option abschalten und dann per Hand die IP-Adressen einzeln am DNS-Server registrieren. Wenn nämlich alle IP-Adressen für die gleiche Netzwerkkarte im DNS registriert wären, würden die Client-Systeme immer wieder falsche IP-Adressen zurückgeliefert bekommen.
Als Quelle überspringen: skipassource-Flag kann helfen
Bei den aktuellen Windows-Systemen steht den Administratoren jedoch mit der Netshell eine sehr gute Möglichkeit zur Verfügung, IP-Adressen selektiv im DNS zu registrieren. Dies gelingt mithilfe des neuen Netsh-Flags "skipassource". Diese Einstellung wird auf deutschen Systemen dann mit "Als Quelle überspringen" angezeigt.
Eine solche Möglichkeit wurde erstmals mit dem Hotfix 975808 für ältere Windows-Server-2008-SP2- und Vista-Systeme sowie mit dem Hotfix 2386184 für Systeme unter Windows Server 2008 R2 und Windows 7 bereitgestellt. Wer noch Vista-Systeme im Einsatz hat, wird wahrscheinlich diesen Hotfix einspielen müssen, um die im folgenden Abschnitt beschriebenen Möglichkeiten nutzen zu können. Auf allen uns im Testumfeld zur Verfügung stehenden aktuellen Systemen unter Windows Server 2008 R2 und Windows 7 war das allerdings nicht nötig, da Microsoft diesen Hotfix in einen der letzten generellen Updates integriert hat. Ganz aktuelle Rechner unter Windows 8 und Windows Server 2012 benötigen diesen Hotfix ebenfalls nicht, da bei ihnen der NetShell-Befehl bereits entsprechend erweitert ist.
Achtung: Weder dieser Hotfix noch die Updates ändern das grundsätzliche Verhalten der Windows-Systeme. Nach wie vor werden standardmäßig alle IP-Adressen in DNS registriert, auch wenn sie nicht für ausgehenden Netzwerkverkehr verwendet werden. Dadurch können dann beispielsweise auch Probleme mit der richtigen Konfiguration der Firewall auftauchen.
Mit dem zusätzlichen Flag steht Administratoren nur eine vereinfachte Möglichkeit zur Verfügung, dieses Verhalten nach ihren Vorgaben zu beeinflussen. Mit folgendem Aufruf kann eine IP-Adresse entsprechend konfiguriert werden:
netsh interface ipv4 add address <Name_Netzwerkschnittstelle> <IP-Adresse> skipassource=true
In diesem Zusammenhang ist ein Hinweis wichtig: Sie können dieses Kommando nicht auf bereits bestehende IP-Adresse ausführen. Es funktioniert nur, wie hier gezeigt, mit dem Anlegen einer neuen Adresse. Bestehende IP-Adressen müssen also zunächst einmal gelöscht und dann mit diesem neuen Flag wieder hinzugefügt werden. Danach zeigt der folgende Befehl, ob die Umstellung funktioniert hat:
netsh interface ipv4 show ipaddresses level=verbose
In der Auflistung aller IP-Adressen ist dann unter dem Abschnitt "Als Quelle überspringen" der Wert "true" oder "false" zu sehen. Diese Adressen werden nun auch nicht mehr für ausgehende Pakete verwendet.
Sollen mehrere Adressen auf diese Weise bearbeitet werden, lässt sich das mithilfe einiger PowerShell-Kommandos leicht realisieren:
$Aktuelle_IPs = "10.1.1.15","10.1.1.16","10.1.1.17","10.1.1.18"
foreach ($ip in $Aktuelle_IPs){
netsh interface ip delete address offen $ip
write-host "$ip gelöscht!"
netsh interface ip add address "offen" $ip 255.255.255.0 skipassource=true
write-host "$ip hinzugefügt"
}
In diesem Code müssen natürlich die richtigen Namen der Netzwerkschnittstelle und der Subnetzmaske eingesetzt werden. Wir haben hier bewusst nur PowerShell-2.0-Code verwendet, weil so ein Script zur Verfügung steht, das auch auf älteren Systemen problemlos abläuft.
Geprüft haben wir es unter Windows 7 und Windows 8 sowie unter Windows Server 2008 R2 und Windows Server 2012. Natürlich sollten Sie zudem darauf achten, dass Sie die IP-Adresse, die Sie als die primäre IP-Adresse für Ihren Server verwenden möchten, nicht mit diesen Befehlen verarbeiten.
Denken Sie bitte auch daran, dass wir zwar nach wir vor den Begriff "primäre IP-Adresse" in diesem Zusammenhang verwenden, aber die aktuellen Windows-System standardmäßig keine IP-Adresse als primäre Adresse ausweisen, wie es noch unter Windows XP oder bei Windows Server 2003 der Fall war.
Hotfix bei Fehlverhalten
Abschließend müssen wir noch auf einen weiteren Hotfix hinweisen, der nötig sein kann, damit diese Art der Manipulation auch wirklich funktioniert.
Es kann durchaus vorkommen (so auch bei einem unserer Testsysteme geschehen), dass Sie diese Änderungen mittels Netsh-Kommando und "skipassource"-Flag durchgeführt und danach Änderungen an einer oder mehrerer der IP-Adressen über die grafische Oberfläche vorgenommen haben. So hatten wir beispielsweise die Subnetzmaske einer der IP-Adressen, die wir zuvor mit "skipassource" markiert hatten, über die grafische Oberfläche nachträglich verändert
Da in diesem Fall ebenfalls die alte IP-Adresse gelöscht und durch die neue ersetzt wird, kann es passieren, dass danach die Markierung für "Als Quelle überspringen" verschwunden ist - die GUI hat sie gelöscht. Auch für dieses "Fehlverhalten", das bei Systemen mit Windows 7 oder Windows Server 2008 R2 auftreten kann, stellt Microsoft unter der Artikel-ID 2554859 einen Hotfix zum Download bereit. Auf aktuellen Systemen wie Windows 8 oder Windows Server 2012 treten diese Probleme hingegen nicht auf. (mje)