Automatisches Initial Update der URL Database eines Clearswift Secure Web Gateways schlägt fehl

Wenn ein automatisches oder manuelles Initial Update der URL Database (Web Categorization Database) fehlschlägt, lohnt sich ein Blick in das entsprechende Log unter “System – Logs & Alarms – System Logs –  URL Category Database Update Log”.

Hier können meistens relativ schnell die Gründe für das Scheitern ermittelt werden. In unserem Beispiel-Log schlägt z.B. die Validierung des Downloads fehl. Dies erkennt man zum einen an den unterschiedlichen md5-Hashes (Remote md5 <-> Local md5) und zum anderen an der anschließenden Fehlermeldung.

URL Category Database Update Log:

[Timestamp] Validating /var/msw/data/websettings/webcat/db/wcd-r1/v023-1093.rd

[Timestamp] Remote md5: 94646d4d917ecf43098736e267b3eb89

[Timestamp] Local md5:  50188b9b34fc73ec152569e874462a17

[Timestamp] warning: Validation of /var/msw/data/websettings/webcat/db/wcd-r1/v023-1093.rd failed. retrying.

Ein Grund für die Bildung von unterschiedlichen md5-Hashes kann z.B. ein nicht vollständig heruntergeladenes Update sein. Um dieses überprüfen zu können, aktiviert man den ssh-Zugriff auf die Appliance und meldet sich dort via PuTTY an. Dann wechselt man in das Verzeichnis /var/msw/data/websettings/webcat/db/wcd-r1/ und lässt sich die Dateigröße der Datei v023-xxxx.rd anzeigen. Diese Größe vergleicht man mit der Größe der gleichnamigen Datei unter folgender URL http://url3.clearswift.net:80/ufs/./feeds/wcd-r1/combined. Um auf die URL zugreifen zu können, wird ein Benutzername und ein Passwort benötigt. Diese Informationen können vom Clearswift Support erfragt werden. Stellt man nun eine Differenz fest, empfiehlt es sich, die Datei manuell herunterzuladen und das System händisch auf einen aktuellen Stand zu bringen. Hierzu geht man wie folgt vor:

1. Aufbau einer ssh-Session zur Appliance (wenn nicht bereits erfolgt)

2. sudo – su

3. mkdir /tmp/downloads

4. wget –http-user USERNAME –http-passwd PASSWORT http://url3.clearswift.net/ufs/feeds/wcd-r1/combined/v023-xxxx.rd

5. cd /var/msw/data/websettings/webcat/db

6. mv wcd-r1.rd to wcd-r1.rd_backup

7. cp /tmp/downloads/v023-xxxx.rd /var/msw/data/websettings/webcat/db

8. mv v023-xxxx.rd wcd-r1.rd

9. cd /var/msw/data/websettings/webcat/db/wcd-r1/

10. mv download.history download.history_backup

11. Anfordern einer aktuellen download.history über den Clearswift Support

12. Die erhaltene Datei unter /var/msw/data/websettings/webcat/db/wcd-r1/ ablegen

13. cd /var/msw/data/websettings/webcat

14. cp WebCatVersion WebCatVersion_backup

15. vi WebcatVersion

16. Der “wcd:”-Eintrag muss auf den entsprechenden Unix-Timestamp und die Versionsnummer geändert werden (z.B. 1326182405,1111). Diesen erfährt man ebenfalls vom Clearswift Support.

17. :wq

Nun sollte die Appliance die aktuelle Web Categorization Database verwenden. Das Ergebnis kann über die WebGUI unter dem Menüpunkt “Health” überprüft werden. Von diesem Zeitpunkt an kann die Appliance dann auch die automatischen Updates ohne Probleme durchführen.

NetScaler Training in Hannover

20.02.2012: Basic Administration for Citrix NetScaler 9.2

In diesem Kurs werden Ihnen Grundkenntnisse der Administration und der Konfiguration des NetScalers vermittelt. Ebenfalls werden die aktuellen Hard- und Software Updates der Version 9.2 sowie die virtuelle NetScaler Appliance VPX besprochen.

Zielgruppe
Das Citrix NetScaler Training – Basic Administration for Citrix NetScaler 9.2 richtet sich an Systemadministratoren, Systemingenieure, Systemarchitekten oder Netzwerkspezialisten.

Seminarziele
Der Kurs macht Sie auf effektive und praxisnahe Weise mit der Konfiguration und Administration von Citrix NetScaler 9.2 vertraut. Es vermittelt Ihnen die NetScaler Eigenschaften wie Load Balancing, SSL Offload sowie das Erstellen von klassischen und erweiterten Richtlinien, Expressions, Rate Limiting und Applikationstemplates. Nach dem Seminar sind Sie in der Lage, Einsatzgebiete für NetScaler 9.2 richtig einzuschätzen, NetScaler eigene IP Adressen zu erkennen und VLANs (virtual local area networks), RNAT (reverse network address translation) und Zugriffsberechtigungslisten (ACLs) zu konfigurieren.

Vorkenntnisse
Voraussetzung für eine erfolgreiche Teilnahme sind gute Kenntnisse von TCP/IP und HTTP-Protokollen sowie des OSI-Modells. Weiterhin sollten Sie über Erfahrungen mit Netzwerkkomponenten und Systemadministrationskonzepten inkl. Logging, Softwareupgradeverfahren und Hochverfügbarkeitsszenarien verfügen. Basiskenntnisse in Bezug auf DNS, SSL und Kompression, Server Load Balancing und Content Switching sowie Vertrautheit mit Webserver-Software (z.B. IIS, Apache, WebSphere) und Themen wie Netzwerksicherheitsbedrohungen und Absicherungskonzepte (Firewalls usw.) sind ebenfalls von Vorteil.

Wann?
20. bis 24.02.2012
09.00 – 17.00 Uhr

Wo?
michael-wessel.de
Krausenstraße 50
30171 Hannover

Kosten?
2595,- €* inkl. Tagesverpflegung, original Citrix Learning Courseware und Zugriff auf Citrix Learning Labs
*zzgl. MwSt.

Bei Interesse kontaktieren Sie Frau Wegrich unter 0511 260 911-44 oder per E-Mail über nw@consulting-lounge.de.

In Kooperation mit dem Citrix Authorized Learning Center „CALC“ ADN Distribution GmbH.

How to configure Kerberos Authentication on a Clearswift Secure Web Gateway for different Windows environments

To enable kerberos user authentication on a Clearswift Secure Web Gateway for different Windows environments, you have to complete the following steps:

1. Create a service-user account in Active Directory

User logon name: HTTP/FQDN_OF_APPLIANCE

User logon name (pre-Windows 2000): for example svc_123

Check “User cannot change password

– Check “Password never expires

Only for Windows Server 2008 / Windows 7 environments:

– Check “This account supports Kerberos AES 256 bit encryption

– CheckAccount expires never

2. Create a Keytab-File

– Open a DOS command prompt on Windows domaincontroller and enter the following command for a Windows Server 2008 / Windows 7 environment:

“ktpass –princ HTTP/HOSTNAME_OF_APPLIANCE@DOMAIN –mapuser svc_123@DOMAIN –crypto AES256-SHA1 –ptype KRB5_NT_Principal –pass COMPLEX_PASSWORD –out C:/keytabfile.key”

Use this command for a Windows Server 2008 / 2003 – Windows 7 / Windows XP mixed environment:

“ktpass –princ HTTP/HOSTNAME_OF_APPLIANCE@DOMAIN –mapuser svc_123@DOMAIN –crypto RC4-HMAC-NT –ptype KRB5_NT_Principal –pass COMPLEX_PASSWORD –out C:/keytabfile.key”

Make sure that the DOMAIN is written in capital letters!

3. Upload Keytab-File and configure CSWG

           CSWG: System – Proxy Settings – Authentication Settings

– User Authentication is Enabled

– Your users will be asked for authentication details.

– The Web Proxy will respond to Kerberos protocol only.

– The Web Proxy will reject responses made using other protocols.

– Kerberos Distribution Center

– The Kerberos Distribution Center is located at “FQDN_OF_DOMAINCONTROLLER”

– Kerberos Key Tab File

– Upload the Keytab-File

– Apache Access Log is Enabled

– Apache access logs are being generated by the Web Gateway.

4. Test authentication

– Enter “Domain User Name

– Enter “User Password

Run Test

You should get now a “successfully authenticated” message.

Most Certified Citrix Networking Partner

Zwar gibt es keine offizielle Auszeichnung dafür, aber nach unserem Kenntnisstand sind wir mindestens für Deutschland der most committed und vor allem most certified Citrix Networking Partner: Stand heute haben wir 5 (fünf) Citrix Certified Administrators (CCA) für Citrix NetScaler und einen Citrix Certified Instructor 2012 for Networking (CCI, der natürlich auch CCA für NetScaler und Access Gateway Enterprise ist) im Team.

Das musste einfach mal gesagt werden. 😉

Alles Gute für 2012

Wir wünschen allen Partnern – dazu zählen wir unsere Kunden wie auch Lieferanten und Hersteller – ein gesundes und erfolgreiches neues Jahr!

PowerShell Seminar mit Dr. Tobias Weltner

10.-13.01.2012: Windows PowerShell 2.0 (WPS) für System- und Netzwerkadministratoren in Hannover.

Zielgruppe
Dieser Kurs richtet sich vornehmlich an Systemadministratoren.

Vorkenntnisse
Administration von Windows Server 2003/2008, Active Directory und Exchange 2007/2010.

Schulungsinhalt
Einführung
– Architektur der PowerShell (alias Microsoft Shell (MSH)/Monad)
– Systemvoraussetzungen und Installation
– Einsatz der Microsoft Windows PowerShell zur Interaktiven Systemadministration und zum Scripting
– PowerShell-Editoren: PowerShell Integrated Scripting Environment (ISE), PowerShellPlus, PowerGUI, u.a.
– Unterschiede zwischen den Versionen

Basiswissen
– Commandlets, Commandlet-Parameter
– Hilfefunktionen
– Objekt-Pipelining
– Ausgabefunktionen
– Navigationsmodell (PowerShell-Provider)

Scripting
– PowerShell Language (PSL): Variablen und Kontrollstrukturen
– Sicherheitsfunktionen (Execution Policy)
– Vordefinierte Variablen
– Profilskripte
– Datenbereiche, Datendateien, Internationalisierung/Lokalisierung/Mehrsprachigkeit

Aufbauwissen
– Fernaufruf/Fernadministration mit WS-Management (“PowerShell Remoting”)
– Zugriff auf .NET-Objekte
– Zugriff auf COM-Objekte
– Zugriff auf WMI-Objekte
– Ereignissystem
– Transaktionen
– PowerShell-Erweiterungen (Module, Snap-Ins) installieren
– Profilskripte
– Datenbereiche, Datendateien, Internationalisierung/Lokalisierung/Mehrsprachigkeit
– PowerShell-Module in Windows Server 2008 Release 2: Active Directory, Server Manager, BITS, App Locker, Best Practices, PSDiagnostics, TroubleShootingPack, etc.

Einsatzbeispiele
– Prozesse
– Dienste
– Dateisystem
– Netzwerkkonfiguration
– Berechtigungen/Sicherheitsfunktionen
– Freigaben
– Active Directory/Verzeichnisdienste
– Registry
– Drucker
– Hardware
– Software
– Ereignisprotokolle
– Dokumente (Textdateien, XML-Dokumente)
– Datenbanken
– DNS
– DHCP
– usw.

Profiwissen
– Fehlerbehandlung und Fehlersuche
– Tracing
– Script Debugging
– Asynchrone Befehlsausführung (Background Jobs, PSJobs)
– Commandlets erstellen in PowerShell Skriptsprache
– PowerShell-Module erstellen
– Sicherheitsfunktionen (Execution Policy)

Ausblick auf die kommenden Versionen der PowerShell
Tipps und Tricks
Antworten auf Ihre Fragen

Dozent
Dr. Tobias Weltner gehört mit über 50 Büchern zu den bekanntesten Fachbuchtoren zum Thema Windows in Deutschland. Er arbeitet als Trainer und Consultant für Großkonzerne in ganz Europa. Sein Spezialgebiet sind Window Scripting-Techniken, insbesondere die Windows PowerShell. Er ist Entwickler der PowerShell-Entwicklungsumgebung “PowerShellPlus” und Autor der Bücher „Scripting mit Windows PowerShell – Der Einsteiger-Workshop“ sowie „PowerShell-Scripting für Administratoren“ (beide erschienen bei Microsoft
Press) . Von Microsoft ist er aufgrund seines Fachwissens ausgezeichnet mit dem Titel “Microsoft Valuable Professional” (MVP) für die Kategorie “Windows PowerShell”.

Wo?
michael-wessel.de
Krausenstraße 50
30171 Hannover

Kosten?
1800,- €* statt 2.249€ p.P. inkl. Tagesverpflegung
*zzgl. MwSt.

Bei Interesse kontaktieren Sie uns unter 0511 260 911-44 oder service [at] michael-wessel.de.

NetScaler High Availability

Ein wie selbstverständlich schon genanntes Feature des NetScalers ist der Betrieb in einem Verbund mehrerer Systeme zur Sicherstellung von Hochverfügbarkeit. Durch seine Funktionalität als intelligenter Load Balancer stellt der NetScaler Hochverfügbarkeit für die Backend Services her, die er beliefert, wird damit aber zugleich zum hochkritischen Punkt der Infrastruktur, von dessen Verfügbarkeit zahlreiche zentrale Dienste abhängig sind.

Active/Standby Modus

Die am häufigsten eingesetzte und angebrachte Variante der HA Modus ist Active/Standby. In dieser Betriebsart bilden zwei NetScaler Appliances ein HA Paar, in dem lediglich die NSIPs individuell sind, während alle anderen Adressen „floating“ beim Failover vom Standby System übernommen werden. Konfigurationsänderungen sind nur auf dem aktiven Knoten (Primary) möglich bzw. dauerhaft. Solange beide Systeme in Betrieb sind, werden alle auf dem Primary ausgeführten Kommandos (also alle Konfigurationsänderungen) per „Command Propagation“ auch auf dem Secondary Node ausgeführt. Bei einem Reboot zieht sich das startende Standby System die Konfiguration einmal komplett vom Primary Node (HA Synchronization).

Active/Standby mit INC

Eine Spielart des Active/Standby Modus ist die Independent Network Configuration (INC), die dann erforderlich ist, wenn ein HA Paar auf zwei Standorte verteilt ist, in denen unterschiedliche IP-Netze verwendet werden oder zwischen denen die Layer 2 Verbindung ausfallen könnte oder gar nicht erst existiert. Die INC erlaubt es jedem Knoten im HA Paar, die Backends jederzeit selbst zu überwachen und damit auch ohne Verbindung mit dem HA Partner den Monitor Status zu kennen, da neben der NSIP auch die SNIPs/MIPs individuell und damit jederzeit aktiv sind. Im Unterschied zu einem Deployment mit Global Server Load Balancing (GSLB), das als nächste Abstraktionsstufe der Hochverfügbarkeit gelten kann, handelt es sich aber immer noch um ein HA Paar, das eine gemeinsame Konfiguration synchronisiert.

Befinden sich die Knoten nicht im selben Layer 2 Segment, müssen die VIPs wiederum per Route Health Injection bekannt gemacht werden, d.h. es muss ein dynamisches Routing Protokoll zum Einsatz kommen. Anderenfalls reicht der normale IP Failover mit anschließender Gratuitious ARP (GARP) Bekanntgabe an alle Teilnehmer des Segmentes aus.

NetScaler Pools, Active/Active

Zu einem HA Deployment können auch mehr als zwei NetScaler verbunden werden, wir sprechen dann von NetScaler Pools. Zwar ist auch ein Deployment mit mehr als einem Standby System möglich (Active/Standby/Standby/…), aber in der Praxis sind NetScaler Pools vor allem sinnvoll in Situationen, wo mehr aktive Leistung benötigt wird, als eine einzelne Appliance liefern kann. In Anbetracht der Leistungsmerkmale der MPX Hardware Appliances sind diese Situationen zwar äußerst selten, aber auch dieser Ansatz zur Skalierung kann wünschenswert sein (z.B. sehr hohe Durchsatzanforderung für FIPS-zertifiziertes Deployment). Ein NetScaler Pool mit mehreren aktiven Knoten ist eine Erweiterung eines einfachen Active/Active Paares, um zusätzliche Failover Kapazität (N+1 oder auch N+X) und Leistung.

Bei Active/Active Deployments besteht kein HA Paar im Sinne von gemeinsamer Konfiguration oder gemeinsamen IP Adressen, alle NetScaler laufen standalone. Die Zuordnung von VIPs zu Systemen erfolgt mit Hilfe des Virtual Router Redundancy Protocols (VRRP), indem jedem NetScaler für jede VIP eine Priorität zugewiesen wird. Die Systeme regeln dann untereinander, welche VIP zu einem Zeitpunkt auf welchem NetScaler aktiv ist. Dabei wandert gemäß VRRP auch eine Virtual MAC (VMAC), die zu jeder VIP gehört und aus der Virtual Router ID (VRID) gebildet wird, beim Failover mit auf den nächsten NetScaler.

Als weitere Konsequenz aus der Tatsache, dass die Systeme in einem NetScaler Pool keine Synchronisationsmöglichkeit haben, müssen zur Sicherstellung von Session Persistence verbindungslose („stateless“) Methoden eingesetzt werden. Beispiele dafür sind Hash-basierte Persistenz und vor allem Cookie Insert, bei dem der Client seine Persistenz-Informationen praktisch selbst besitzt und mitliefert.

VMACs und Firewall Load Balancing

Bei einem IP Failover wird die neue Heimat einer IP-Adresse durch GARP Pakete bekanntgegeben. Sicherheitskritische Systeme beachten diese Pakete unter Umständen nicht weiter, da ihnen damit auch gefälschte ARP Einträge untergeschoben werden könnten, so dass es zu längeren Unterbrechungen im Falle eines Failovers kommen kann. Hier, wie auch speziell im Sonderfall des Firewall Load Balancing, das in der Regel sowieso auf Layer 2 stattfindet, sind virtuelle MAC Adressen (VMACs) hilfreich. Diese können ebenso zwischen NetScalern wandern wie IP-Adressen, so dass keine Neuzuordnung von IP zu MAC mehr erforderlich ist.

Auslöser für ein Failover

Neben der völligen Unerreichbarkeit des bislang aktiven Partners gibt es weitere Auslöser – oder auch Hinderungsgründe – für ein Failover der Ressourcen auf einen Standby NetScaler. So kann die Erreichbarkeit eines HA Partners abhängig sein von der Verfügbarkeit von Routern, so dass diese ein Entscheidungskriterium dafür sind, ob ein System überhaupt beurteilen kann, ob der Partner oder nur die Verbindung offline ist. Zu diesem Zweck können Route Monitors der HA Konfiguration hinzugefügt werden, die kritische (statische) Routen oder die bloße Existenz bestimmter dynamischer Routen überwachen und bei negativer Verfügbarkeit verhindern, dass dieser Knoten aktiv werden kann.

Weiterhin überwachte Ressourcen sind die Netzwerkschnittstellen eines NetScalers. Standardmäßig werden alle verbundenen Interfaces überwacht und der Verlust des Links an einem Interface führt zum Failover auf den Standby Node. Die schon beschriebene Link Aggregation zur Erhöhung der verfügbaren Bandbreite, durch die auch die Abhängigkeit von einem einzelnen Interface aufgehoben wird, muss für die HA Konfiguration in Form eines Failover Interface Set (FIS) abgebildet werden. Beim Ausfall eines Interfaces in einem FIS findet daher kein Failover statt, solange noch ein Interface des FIS verfügbar und verbunden ist. Alle Schnittstellen, die nicht Teil eines Failover Interface Set sind und auf denen der HA Monitor nicht deaktiviert ist, sind sogenannte Critical Interfaces.

Lastverteilung und Desaster Recovery über verteilte Rechenzentren

Featuring: Global Server Load Balancing (GSLB)

Ein Unternehmen mit hohen Anforderungen an die Verfügbarkeit seiner Services möchte die Anfragen seiner Benutzer über  zwei geografisch getrennte Rechenzentren verteilen. Wie beim Load Balancing innerhalb einer lokalen Serverfarm wird durch den einheitlichen Eingangspunkt – hier in Form eines Hostnamens statt einer IP-Adresse – und die Verteilung auf verfügbare Server neben einer höheren Leistungsfähigkeit gleichzeitig eine höhere Verfügbarkeit erreicht.

Um die Verfügbarkeit auch innerhalb jedes einzelnen Rechenzentrums zu gewährleisten, erfordert dieses Szenario ein HA Paar aus zwei NetScalern je RZ (z.B. in unterschiedlichen Brandschutzzonen).

Die Funktionsweise des GSLB  ist dann wie folgt: Ein Client möchte auf den Service unter „ica.customer.org“ zugreifen und sendet daher eine DNS Anfrage nach diesem Namen. Der autoritative Nameserver für die Zone “customer.org” hat für diesen Namen einen CNAME Eintrag, der auf „ica.gslb.customer.org“ verweist, sowie eine Subzone „gslb.customer.org“, die an zwei Nameserver delegiert ist. Diese Nameserver sind die ADNS Service VIPs der beiden NetScaler-Paare. Um die Anfrage zu beantworten, stellt der Resolver also wiederum eine DNS Anfrage nach „ica.gslb.customer.org“ an einen der NetScaler. Dieser bestimmt anhand der konfigurierten GSLB Parameter und des Servicestatus die zurück zu liefernde IP-Adresse und nennt diese als Antwort. Der Client bekommt diese IP-Adresse als Antwort auf seine DNS Anfrage und baut seine Verbindung dann zu der durch die NetScaler bestimmten IP auf.

Die Entscheidung, welche IP auf eine bestimmte Anfrage zurückgeliefert wird, basiert auf den eingestellten GSLB Parametern und Methoden (u.a. Round Robin, Least Connection oder Round Trip Time). Zum Austausch der Statusinformationen, die zur Entscheidung erforderlich sind, sowie von Persistenzinformationen nutzen die NetScaler zwischen den verschiedenen Rechenzentren dabei das Metric Exchange Protocol (MEP). Je Site kommt für diese Kommunikation noch eine weitere IP-Adresse ins Spiel, nämlich die GSLB Site IP, die aber ebenso eine bestehende SNIP oder MIP sein kann wie die ADNS Service IP.

Erweiterte Netzwerkfunktionen des Citrix NetScalers

Um die verfügbare Bandbreite zwischen dem NetScaler und anderen Komponenten über die Kapazität eines einzelnen Interfaces hinaus zu erhöhen, können Interfaces zu sogenannten Channels zusammengefasst werden. Diese Link Aggregation genannte Konfiguration kann manuell oder durch das Link Aggregation Control Protocol (LACP) gesteuert erfolgen. Neben der Bandbreite wird damit zugleich auch die Ausfallsicherheit verbessert, da die Verbindung auch bei Ausfall eines Interfaces noch verfügbar ist.

Interfaces, die Teil eines Link Aggregate Channels werden, übernehmen die Parameter des Channels, insbesondere dessen VLAN Konfiguration. VLANs können sowohl Port-basiert (ein Interface in einem VLAN) als auch mit Tagging nach 802.1q (ein Interface in mehreren VLANs) konfiguriert werden.

Routing oder Bridging von VLANs

Unterschiedliche VLANs sind üblicherweise nur durch Layer 3 Router verbunden, d.h. ein System agiert als IP-Router zwischen ihnen. Diese Funktion kann auch der Citrix NetScaler wahrnehmen, indem je ein VLAN mit einem IP-Subnetz assoziiert und der Layer 3 Mode aktiviert wird.

Bei aktiviertem Layer 3 Mode führt der NetScaler standardmäßig IP-Forwarding zwischen allen ihm bekannten Netzen aus. Um dieses Routing einzuschränken und nur zwischen definierten Netzen durchzuführen, werden IP-Subnetze an sogenannte Bridge Groups gebunden. Dann werden Pakete nur noch in VLANs (Subnetze) weitergeleitet, die zur selben Bridge Group gehören.

Mit Hilfe des NetScalers können mehrere VLANs jedoch auch auf Layer 2 zu einer gemeinsamen Broadcast Domain verbunden werden. Sollen zwei oder mehr VLANs zusammengelegt werden, müsste normalerweise auf allen beteiligten Geräten in allen Domains die VLAN Konfiguration geändert werden. Stattdessen können auf dem NetScaler eine Bridge Group angelegt und die zu verbindenden VLANs dieser Bridge Group zugeordnet werden. Wird dann der Layer 2 Mode aktiviert, leitet der NetScaler Broadcast Pakete aus einem VLAN an alle VLANs in der selben Bridge Group weiter und vermittelt auch Unicast Pakete durch das Nachschlagen aller von ihm in der entsprechenden Bridge Table verzeichneten MAC Adressen.

Erweitertes Routing

Neben dem statischen Routing zwischen Netzen, an die der NetScaler direkt angebunden ist (durch SNIPs) oder die er über statische Routingeinträge kennt, unterstützt er auch dynamische Routingprotokolle wie RIP (v2 und ng), OSPF (v2 und v3) und BGP. Die Teilnahme an diesen Prozessen dient hauptsächlich dazu, an umliegende Router Informationen über identische Virtual Server weiterzugeben (Route Advertising), die zum Beispiel auf mehrere alleinstehende NetScaler verteilt sind. Auf diese Art können Router dann dynamisch Traffic zwischen diesen Virtual Servern verteilen (Equal Cost Multipath, ECMP).

In einem HA Paar wird die Routingtabelle des primären Knotens auf den sekundären gespiegelt, so dass beim Failover keine Unterbrechung des Routings auftritt. Damit auch keine Verbindungsverluste auftreten, weil der vorgelagerte Router noch Traffic an den soeben ausgefallenen Knoten sendet, meldet der verbleibende NetScaler dem Router neue Routingeinträge mit leicht niedrigerer Metrik als die des ausgefallenen Systems (Route Health Injection).

Auch der NetScaler selbst erkennt ECMP, sobald er für ein Ziel mehrere gleichwertige Routen konfiguriert oder gelernt hat, und verteilt Verbindungen mittels eines Hashes über Quell- und Ziel-IP auf die verfügbaren Verbindungen.

Eine weitere Möglichkeit, das Routingverhalten zu bestimmen, sind Policy Based Routes (PBRs). Mit PBRs kann der NetScaler den Next Hop für ein Paket abhängig von verschiedenen Merkmalen wie Quell-/Ziel-IP, Quell-MAC, Ports, Protokoll oder auch VLAN bestimmen. Das Ziel einer PBR kann auch ein Link Load Balancing (LLB) Virtual Server sein, der wiederum auf mehrere Next Hops zurückgreifen kann, so dass beim Ausfall des bevorzugten Routers als Next Hop auf weitere umgeleitet werden kann.

MAC Based Forwarding

Vor der Konfiguration der Netzwerkparameter des NetScalers sollte geklärt werden, ob die Installation den MAC Based Forwarding Modus (MBF) nutzen kann oder muss. In dieser Betriebsart merkt sich der NetScaler für jedes eingehende Paket, von welcher Absender-MAC dieses angekommen ist. Dazugehörige Antwortpakete sendet er wiederum an diese MAC adressiert zurück – unabhängig von etwaigen Routingentscheidungen auf höheren Schichten.

Auf diese Art erspart sich der NetScaler nicht nur das Nachschlagen in seinen Routing- und ARP-Tabellen, sondern er verhindert auch das Entstehen von asymmetrischen Routen. Das ist besonders wichtig, wenn umliegende Systeme statusabhängig agieren, das heißt Pakete nur verarbeiten, die zu einer bekannten, etablierten Verbindung gehören. Typischerweise trifft das für Firewalls zu. Aber auch die Anbindung eines Admin-Netzes per VPN, in dem Adressen auf ein Zwischennetz umgesetzt werden, kann den MBF Modus erfordern, da dem NetScaler dieses Zwischennetz nicht bekannt ist und kein Gateway darin zur Verfügung steht, das Detault Gateway aber ins Internet führt und daher kein Rückweg in das Admin-Netz existiert.

Domain Controller mit gespaltener Persönlichkeit

Das ist wohl schon einigen Admins passiert, die ein FreeNAS installiert und in ihre Domäne aufgenommen haben: Im Dialog zum Domänenbeitritt wird ein “Hostname” abgefragt – hier ist der Hostname für das FreeNAS gefragt, also der Name des Maschinenkontos im AD. Wer hier den Namen eines seiner DCs einträgt, überschreibt damit dessen Maschinenkonto.

Was ist die Folge? Es kann leicht unterschiedliche Varianten geben, je nachdem bei welchem DC der Vorgang ausgeführt wird und wie die Replikation läuft. Das Ergebnis dürfte fast immer sein, dass der betroffene Domain Controller plötzlich nicht mehr mit seinem eigenen AD sprechen kann. Seine Dienste, allen voran der Anmeldedienst, haben damit ernsthafte Probleme – und alles und jeder, der sich bei ihm authentifizieren möchte, ebenfalls. Da er als gleichberechtigter DC im DNS gefunden wird, ist binnen kürzester Zeit die gesamte Domäne betroffen und zu einem großen Teil handlungsunfähig. Das System sollte daher umgehend vom Netz getrennt (heruntergefahren) werden.

Ist die Zeit bis zum Erkennen der Situation kurz genug, kann man vielleicht noch einen anderen DC finden, der die Änderungen noch nicht repliziert hat. Dort muss umgehend die Inbound Replication unterbunden werden, um diesen Stand auch zu erhalten. Dann kann das betroffene Objekt authoritativ geschaltet und ausgehend repliziert werden. Ist aber die Änderung bereits durch alle Replikationsverbindungen gelaufen (was selbst bei weitverzweigten ADs innerhalb weniger Minuten bis Stunden der Fall sein dürfte), greift das Standardverfahren für einen Authoritative Restore gemäß Microsoft.

Der grobe Ablauf ist: Starten des betroffenen DCs im Verzeichnisdienstwiederherstellungsmodus (VWM), Wiederherstellen des AD Objektes aus der letzten Datensicherung – falls kein Object Restore verfügbar ist, Wiederherstellen z.B. des Objektes “Systemstate” (Symantec Backup Exec mit Server 2003 R2). Am Ende NICHT neustarten. Aufruf von ntdsutil auf dem betroffenen DC im VWM:

ntdsutil:
> authoritative restore
> restore object “Distinguished Name des überschriebenen Maschinenkontos”
> quit
> quit

Damit ist nur genau das betroffenen Objekt als authoritativ markiert und wird nach dem jetzt durchzuführenden Reboot bei der wieder anlaufenden Replikation nicht durch die neuere Version der anderen DCs überschrieben, sondern umgekehrt. Die üblichen Anlaufschwierigkeiten bei der Replikation sind im Eventlog zu erwarten, nach wenigen Minuten sollten aber Positivmeldungen folgen, dass die Heraufstufung zum Domain Controller durchgeführt werden konnte.