NetWorker 8.x in einer DMZ-Umgebung.

Erster Update-eines FSC/FTS OEM-NetWorker FWX-Tunnels auf die neue NetWorker 8.0 Funktionalität.

Nachdem ich die erste Migration eines NetWorker FWX-Tunnels bei einem unserer Kunden durchführen konnte, will ich das sehr erfolgreiche Ergebnis an dieser Stelle weitergeben.

Zunächst aber eine kleine Einführung für alle die NetWorker Kunden, die das NSR-FWX Modul noch nicht kennen.

Eine NetWorker-Umgebung benötigt zur Kommunikation zwischen dem NetWorker-Server und seinen Clients standardmäßig eine größere Anzahl von TCP/IP-Ports.

Der Grund für dieses, von Firewall Administratoren nur schwer akzeptierbare Verhalten liegt in der Basis der NetWorker-Kommunikationstechnik. NetWorker verwendet für alle Verbindungen zwischen seinen Client-Programmen und den Server-Programmen das Remote-Procedure-Call(RPC)-Verfahren. Dieses definiert zwar eine eindeutige RPC-Nummer für jeden Dienst, ein TCP-Port hierzu wird aber erst zur Laufzeit allokiert. Der Vorteil des Verfahrens liegt in seiner hohen Flexibilität, denn der Weg und auch das Ziel der Datensicherung wird erst beim tatsächlichen Start des Backups ermittelt. Fällt ein Laufwerk oder gar eine StorageNode für das Backup aus, so wird die Sicherung dynamisch auf ein anderes Laufwerk umgeleitet. Durch eine einmal definierte Konfiguration ist sichergestellt, dass das Backup auch in einem Fehlerfall durchgeführt werden kann.
Diese Eigenschaft ist für den normalen Betrieb also sehr vorteilhaft. In einer Rechnerlandschaft aber, in der eine durch Firewall getrennte Datenzone gesichert werden soll, ist das Verhalten eher kontraproduktiv, weil nicht nur viele TCP-Ports benötigt werden, sondern auch noch Ports in beiden Richtungen geöffnet werden müssen. Beim Start der Sicherung kontaktiert der NetWorker-Server den zu sichernden Client, der im Anschluß daran für jeden Sicherungsjob gleich 5 Verbindungen zu den diversen NetWorker-Diensten am NetWorker-Server benötigt.

Die Fujitsu-Siemens OEM-NetWorker Version hatte für dieses Problem schon seit einigen Jahren eine Tunnel-Lösung erhalten. Die Lösung basiert auf dem freien "vtun" Daemonen und implemetiert einen Filter- und einen Proxy-Server. Nach der erfolgreichen Konfiguration beider Dienste wird dann in der Firewall lediglich noch ein TCP-Port benötigt und dieser kann gerichtet in lediglich einer Richtung definiert werden.

Die beschriebene Implementation hat sich in der NetWorker OEM-Version, vor allem bei Banken und Behörden, über Jahre bewährt, ist bei vielen Kunden im Einsatz und kann auch innerhalb einer NetWorker-Datazone mehrmals Verwendung finden. Zum Beispiel ist mir ein Kunde bekannt der mit einem NetWorker-Server mehr als 10 DMZ-Umgebungen mit einem NetWorker-Server sichert.
Mit der NetWorker Version 8.0 hat EMC die Funktionalität des Tunnel-Konzepts in seine NetWorker-Version integriert. Hierzu müssen jedoch die bestehenden Konfigurationen von Hand migriert werden.

Folgende wesentliche Änderungen lassen sich bei der EMC-Integration festhalten:

1. Die ursprüngliche Implementation benötigte für die Funktionalität zusätzliche Installations-Pakete. Die EMC-Implementation hat die Tunnel-Funktionalität im NetWorker Client Paket integriert.
2. Bei der ursprünglichen Version mussten auf dem FWX-Filter und dem FWX-Proxy für jeden Tunnel mehrere Konfigurationsdateien angelegt werden. Der Name dieser Dateien war Teil der Funktionalität und der Sicherheitsüberprüfung. Die EMC-Implementation hat für diesen Zweck im NetWorker-Client Daemon (nsrexecd) einen neuen Ressource-Typ (nsr tunnel) intergriert. Hierdurch wird die Konfiguration transparenter, leichter implementierbar und auch weniger fehleranfällig.
3. Bei der FSC/FTS Version musste der Start der Tunnel Dämonen vor dem Start der NetWorker Dienste erfolgen. Es war folglich nicht möglich Änderungen oder gar einen Neustart des Tunnels durchzuführen, ohne den NetWorker-Client oder gar den NetWorker-Server neu zu starten. Diese unschöne Abhängigkeit ist durch die Integration des Tunnels in den NetWorker-Client entfallen. Jetzt wird sowohl der Proxy als auch der FWX-Filter direkt vom NetWorker-Client Daemon gestartet. Hierduch ist das Ändern und der Neustart eines Tunnels auch während laufender NetWorker-Sicherungen möglich.
4. Für die ursprüngliche Tunnel-Lösung wurde von FSC/FTS für jeden laufenden Tunnel eine Lizenz verlangt. Diese Lizenz entfällt bei EMC!

Gleich geblieben ist jedoch die Einschränkung der Betriebssytem-Plattformen auf der die Tunnel-Dienste laufen können. Dies sind LINUX und Solaris. D.h.: Der NetWorker-Server und der NetWorker-Firewall-Proxy in der DMZ müssen auf LINUX und/oder Solaris laufen. Die in der DMZ zu sichernden Clients können jedoch jedes beliebige von NetWorker unterstützte Betriebssystem verwenden. Diese Clients erkennen gar nicht, dass ihr NetWorker-Server über eine Firewall-Konfiguration gesichert wird. Für die erfolgreiche Sicherung dieser Clients über den FWX-Tunnel wird lediglich das setzen des Client-Attributes "server network interface" benötigt.

Wichtiger Hinweis.
Vor einer Sicherung von Massendaten durch eine Firwall möchte ich an dieser Stelle aber unbedingt abraten. Sollen größere Datenmengen aus einer DMZ gesichert werden, so benötigt man in der DMZ eine eigene StorageNode. Hierdurch kann man die Sicherung der Massendaten innerhalb des DMZ-Netzes belassen und den Firewall-Tunnel benötigt man nur noch für die NetWorker-Metadaten (Index-, Medien-, Job-DB).

Weitere Informationen über das NetWorker-Firewall-Tunnel-Modul können Sie entweder im Workshop NetWorker Admin-3, oder direkt vom Author dieses Blocks erhalten.