Vor ein paar Tagen habe ich einen kleinen Erfahrungsbericht zu einem aktuellen Kundenprojekt in die deutschsprachige ISA-NG gestellt. Diesen poste ich als ersten fachlichen Beitrag noch einmal hier:
Für besagten Kunden haben wir ein ISA2006 Enterprise-Array bestehend aus zwei Knoten eingerichtet. Haupteinsatzzweck ist momentan Reverse-Proxying zwecks sicherem Zugriff auf OWA und EAS.
Nachdem wir das NLB aktiviert hatten fingen die ersten Probleme an: das Array und die Swichte wollten nicht miteinander atmen. Die Firmware auf den Switchen konnte mit dem NLB nicht umgehen. Einen der installierten ISAs haben wir daraufhin auf Eis gelegt und den anderen via modifizierter masksourcemac mit den Switchen zum sprechen gebracht (http://support.microsoft.com/kb/193602).
Nach passenden strategischen Vorbereitungen wurden die zwei redundant ausgelegten Core-Switche auf eine aktuelle (NLB-fähige) Firmware gepatcht. Kein Vorgang, der mal eben so schnell erledigt werden konnte. Wir reden hier von einer recht sensiblen Infrastruktur, in der man sich so gut wie keinerlei Ausfälle leisten kann. Ergo mussten alle Backbone-Admins zum Core-Switch-patchen antanzen, da der gesammte Backbone an den guten Teilen hängt.
Lange Rede kurzer Sinn: Switche gepatcht, VLAN aufgespannt – NLB-Funktionalität auf den Switchen für das VLAN eingeschaltet – ISAs ins VLAN reingehängt – masksourcemac rausgenommen – beide ISA-Knoten hochgefahren um das Array zu vervollständigen.
Erste Tests ergaben, das die eingehende Last (wie gesagt hauptsächlich reverse-proxy für OWA und EAS) nur auf einem der ISA-Knoten hängt (nämlich auf dem, der eh die letzten Wochen/Monate lief). Der neue (aus dem dornröschenschlaf erweckte) ISA hatte nur ein paar ausgehende Connects zu verzeichnen (aus der Admin-Abteilung selber), eingehende aber gar keine. Um dies zu forcieren und die Redundanz zu testen haben wir auf dem “alten” ISA den Firewalldienst beendet. Jetzt wurde es spannend: es klappten keinerlei Zugriffe mehr aufs OWA/EAS. Wir bekamen von Extern noch via telnet einen “offenen Port” auf dem Zielsocket angezeigt (IP:443), aber sobald wir mit dem Browser aufs OWA zugreifen wollten kam es zu einer absolut nichtssagenden Fehlermeldung, gleiches Verhalten via EAS, sprich pushmail.
Wir versuchten das Problem einzugrenzen und haben einige Tests vorgenommen, bei denen wir folgendes festgestellt haben: ausgehende Zugriffe (WPC) klappten einwandfrei! Flux einen neuen Http-Listener gebaut und unverschlüsselt sowie unauthentifizert auf eine interne Http-Präsenz zugegriffen: einwandfrei! Die Webveröffentlichungsregel modifiziert (extern http – intern https): einwandfrei! Sobald ich allerdings in den Webveröffentlichungsregeln den fürs OWA/EAS angelegten Https-Listener verwendet habe fuhr uns die Karre an die Wand, sprich: Fehlermeldung. Nebenbei sei erwähnt, das die Authentifizierungsmethoden und -delegierungen korrekt eingestellt waren. Auch die Switchte auf der internen und externen Seite konnten wir ausschließen, da die Connects schon bis zum ISA durchgereicht wurden.
Dann klingelte es bei mir irgendwo im Hinterstübchen. Keine Ahnung ob ich darüber mal in einer der einschlägigen ISA-Ngs was gelesen habe, oder bei Dr.Tom. Ich hatte durch die Tests bestätigt bekommen, das eigentlich alles funzt, nur die Https-Connects zu diesem einen jetzt neu in Betrieb genommenen ISA scheiterten. Zertifikatsfehler oä Signifikantes waren aber nirgendswo irgendswo ersichtlich (ja, die Zertifikate sitzen im richtigen Zertifikatsspeicher). Unnötig zu erwähnen, das sämtliche Logs clean waren.
Ich habe daraufhin den Weblistener geöffnet und unter der Registerkarte “Zertifikate” über die Schaltfläche “Zertifikate auswählen” das passende OWA-Zertifikat nochmals ausgewählt und dieses nochmal übernommen (obwohl dies ja schon passend konfiguriert war). Tata, die Zugriffe funktionierten direkt einwandfrei auf allen Array-Members. Unfassbar. Vor dem Aktualisieren des NLB sind auf beiden ISA-Hosts die Zertifikate importiert worden. In stiller Abwesenheit von einem ISA-Knoten (aufgrund der oben genannten Switch-Problematik) haben wir einen Weblistener auf der per NLB eingerichteten VIP gebaut. Als dann nach dem Switchupdate der zweite Host reanimiert wurde hat er diese Konfiguration (warum auch immer) nicht einwandfrei übernommen oder umgesetzt. Erst wo beide Knoten online waren und ich dann das Zertifikat nochmals zugeordnet habe klappt das Ganze.
Vielleicht sagen jetzt einige von euch: ja klar, ist doch logisch, liegt da und daran. Mir wars ehrlich neu und hat uns auch einige Zeit und Energie gekostet (für einen an und für sich lapidaren Konfigurationsschritt).
Jens Mander…
|<-|
