von Wenn man einen Webserver als VServer bei einem Provider betreibt, ist die Benachrichtigung darüber, dass dieser seinen Internetanbieter wechselt und neue IP-Adressen vergeben werden müssen schon ärgerlich. Die alten IP-Adressen sind dann nur noch einen begrenzten Zeitraum nutzbar.
Warum ist das ganze ärgerlich?
- Wegen der zu ändernden Ziel-IP-Adresse im DNS-Eintrag ist die durchgehende Erreichbarkeit der Webseiten nicht gewährleistet.
- In diesem Fall gab es einen Kunden in der Schweiz, laut dessen Aussage sich selbst ein großer Provider in der Schweiz 24 Stunden Zeit lässt den DNS-Eintrag neu auszuwerten. Selbst bei niedrigster TTL kann es also im schlimmsten Fall passieren, dass die Ziel-Webseite einen Tag lang für viele Benutzer nicht erreichbar ist.
Vorgehen für einen nahtlosen Übergang ohne Erreichbarkeitsprobleme:
- Die TTL im Vorfeld möglichst niedrig konfigurieren.
- Durch den Provider einen weiteren Netzwerkadapter im VServer konfigurieren lassen, auf dem die neue Adresse konfiguriert wird. Dadurch soll die Webseite gleichzeitig unter der neuen und der alten IP-Adresse erreichbar sein. So bekommen auch Clients, bei denen die DNS-Abfrage während der Umstellung noch die alte IP ergibt, in jedem Fall die Webseite angezeigt. Diese Nutzung von mehreren Netzwerkadaptern nennt man „Dual“ bzw. „Multi Homing“.
- Im Apache oder IIS müssen die entsprechenden Bindungen an die neue IP-Adresse eingerichtet werden.
Problem bei diesem Vorgehen:
- Eigentlich darf es nur ein Standardgateway geben, über welches Traffic an IP-Adressen außerhalb des eigenen Netzes geschickt wird. Dies betrifft die IP-Adressen der Websiteaufrufer. Für Anfragen, welche über die alte IP kommen, kann während der Umstellung nicht das neue Gateway verwendet werden. Dies wird in den meisten Fällen von der Firewall des Providers geblockt. Dies kann man bereits vor der Umstellung prüfen, indem man beim neuen Netzwerkadapter kein Gateway einträgt und versucht die Webseite über die neue IP-Adresse aufzurufen. Man sollte dann keinen Reply bekommen. Sollte man wider Erwarten doch die Webseite angezeigt bekommen, sollte man mit der Konfiguration bereits nun am Ende sein 😉
- Um das Gateway-Problem zu lösen, benötigt man eigentlich Regeln, laut denen Traffic, der über eine bestimmte IP ankommt, auch über ein bestimmtes Gateway beantwortet wird:
12Wenn Traffic von Router1 ankommt, dann beantworte ihn über Router1Wenn Traffic von Router2 ankommt, dann beantworte ihn über Router2Unter Windows ist dieses sogenannte „Policy Based“ bzw. „Source Based Routing“ (zu diesem Thema wird es noch einen Artikel geben) nicht wirklich umsetzbar. Zumindest nicht mit Windows-Bordmitteln. Unter Linux sieht es da anders aus.
Vorübergehende Lösung:
- Auf dem neuen Netzwerkadapter muss man das neue Standardgateway parallel zur alten Konfiguration eintragen. Die Warnung bzgl. Redundanz muss man ignorieren. Der Effekt ist, dass für Anfragen über die neue IP-Adresse die richtige Rückroute über das neue Gateway benutzt wird. Es gilt das gleiche auch für die alte IP-Adresse und das alte Gateway. So hat man eine Art „Pseudo Policy Based Routing“, damit Anfragen über das Standardgateway des Netzwerkadapters beantwortet werden, über welchen sie beim Server ankamen. Dies genügt für diesen Fall.
- Zu beachten: Dies entspricht natürlich keiner empfohlenen Standard-Konfiguration! Den Server sollte man während der Übergangsphase am besten nicht neu starten. In meinen Tests hatte dies dann Auswirkungen auf die priorisert verwendete Standard-Route. Nach der Verbreitung der neuen DNS-Einträge sollte man diese Konfiguration möglichst schnell wieder loswerden.
Getestet habe ich dieses Vorgehen sowohl unter „Windows Server 2008 R2“, wie auch unter „Windows Server 2012 R2“. Ein SSL-Zertifikat funktionierte übrigens parallel unter beiden IP-Adressen fehlerfrei.
Info von Microsoft zur Nutzung mehrer Standardgateways:
https://windows.microsoft.com/de-de/windows/configuring-multiple-network-gateways#1TC=windows-7
