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:<\/p>\n
F\u00fcr besagten Kunden haben wir ein ISA2006 Enterprise-Array bestehend aus zwei Knoten eingerichtet. Haupteinsatzzweck ist momentan\u00a0Reverse-Proxying zwecks sicherem Zugriff auf OWA und EAS.<\/p>\n
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\u00a0Eis gelegt und den anderen via modifizierter masksourcemac mit den Switchen zum sprechen gebracht (http:\/\/support.microsoft.com\/kb\/193602<\/a>). Erste Tests ergaben, das die eingehende Last (wie gesagt haupts\u00e4chlich reverse-proxy f\u00fcr OWA und EAS) nur auf einem der ISA-Knoten h\u00e4ngt (n\u00e4mlich auf dem, der eh die letzten Wochen\/Monate lief). Der neue (aus dem dornr\u00f6schenschlaf erweckte) ISA hatte nur ein paar ausgehende Connects zu verzeichnen (aus der Admin-Abteilung selber), eingehende aber gar keine. Um dies\u00a0zu forcieren und die Redundanz zu testen haben wir auf dem “alten” ISA den Firewalldienst beendet.\u00a0Jetzt wurde es spannend: es klappten keinerlei<\/strong> 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.<\/p>\n 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\u00fcsselt sowie unauthentifizert auf eine interne Http-Pr\u00e4senz zugegriffen: einwandfrei! Die Webver\u00f6ffentlichungsregel modifiziert (extern http –\u00a0intern https): einwandfrei! Sobald ich allerdings in den Webver\u00f6ffentlichungsregeln den f\u00fcrs OWA\/EAS angelegten Https-Listener verwendet habe fuhr uns die Karre an die Wand, sprich: Fehlermeldung. Nebenbei sei erw\u00e4hnt, das die Authentifizierungsmethoden und -delegierungen korrekt eingestellt waren. Auch die Switchte auf der internen und externen Seite konnten wir ausschlie\u00dfen, da die Connects schon bis zum ISA durchgereicht wurden.<\/p>\n Dann klingelte es bei mir irgendwo im Hinterst\u00fcbchen. Keine Ahnung ob ich dar\u00fcber mal in einer der einschl\u00e4gigen ISA-Ngs was gelesen habe, oder bei Dr.Tom. Ich hatte durch die Tests best\u00e4tigt bekommen, das eigentlich alles funzt, nur die Https-Connects zu diesem einen jetzt neu in Betrieb genommenen\u00a0ISA scheiterten. Zertifikatsfehler o\u00e4 Signifikantes waren aber nirgendswo irgendswo ersichtlich (ja, die Zertifikate sitzen im richtigen Zertifikatsspeicher). Unn\u00f6tig zu erw\u00e4hnen, das s\u00e4mtliche Logs clean waren.<\/p>\n Ich habe daraufhin den Weblistener ge\u00f6ffnet und unter der Registerkarte “Zertifikate” \u00fcber die Schaltfl\u00e4che “Zertifikate ausw\u00e4hlen” das passende OWA-Zertifikat nochmals ausgew\u00e4hlt\u00a0und dieses nochmal \u00fcbernommen (obwohl dies ja schon passend konfiguriert war). Tata, die Zugriffe funktionierten direkt einwandfrei auf allen Array-Members. Unfassbar. Vor dem Aktualisieren des\u00a0NLB 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\u00a0NLB eingerichteten VIP gebaut. Als dann nach dem Switchupdate der zweite Host reanimiert wurde hat er diese Konfiguration (warum auch immer) nicht einwandfrei \u00fcbernommen oder umgesetzt. Erst wo beide Knoten online waren und ich dann das Zertifikat nochmals zugeordnet habe klappt das Ganze.<\/p>\n 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\u00fcr einen an und f\u00fcr sich lapidaren Konfigurationsschritt).<\/p>\n Jens Mander…<\/p>\n |<-|<\/p>\n","protected":false},"excerpt":{"rendered":" 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\u00fcr besagten Kunden haben wir ein ISA2006 Enterprise-Array bestehend aus zwei Knoten … Continue reading
\nNach passenden strategischen Vorbereitungen wurden die zwei redundant ausgelegten Core-Switche auf eine aktuelle (NLB-f\u00e4hige) 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\u00e4lle leisten kann. Ergo mussten alle Backbone-Admins zum Core-Switch-patchen antanzen, da der gesammte Backbone an den guten Teilen h\u00e4ngt.
\nLange Rede kurzer Sinn: Switche gepatcht, VLAN aufgespannt –\u00a0NLB-Funktionalit\u00e4t auf den Switchen f\u00fcr das VLAN eingeschaltet – ISAs ins VLAN reingeh\u00e4ngt – masksourcemac rausgenommen – beide ISA-Knoten hochgefahren um das Array zu vervollst\u00e4ndigen.<\/p>\n