True IT Stories

Das Plugin nimmt jede Adresse

TL;DR

  1. Das SAP-HANA-Plugin braucht in Veeam 13 zusätzlich Port 443. Es holt sich dort eine Anmeldekonfiguration, die es in Version 12 nicht gab.
  2. Es probiert jede Adresse des Backup-Servers durch, auch die auf Netzen, die es gar nicht erreichen kann. Jeder Versuch kostet rund 30 Sekunden.
  3. Preferred Networks gleich beim Upgrade setzen und 443 und 6162 in die Firewall-Matrix aufnehmen.

Ein Industrieunternehmen sichert seine SAP-HANA-Datenbank mit dem Veeam-Plugin direkt auf ein Linux-Repository. Das lief jahrelang. Dann kam das Upgrade von Version 12 auf 13, und das Plugin fand seinen Backup-Server nicht mehr.

Es sah nach dem Zertifikat aus

Die Meldungen im Log zeigten alle in dieselbe Richtung:

Failed to establish ssl connection with vbr server
HTTP downloader. 'Handshake' failed: stream truncated
Failed to download open-id configuration

Ein Handshake, der abbricht, klingt nach Zertifikat. Und tatsächlich war am Backup-Server noch ein Zertifikat von 2019 im Einsatz. Ein Test der Ports per Telnet lief dagegen durch. Von außen sah alles offen aus.

Was Veeam 13 anders macht

Im Supportfall bei Veeam kam nach und nach heraus, dass es nicht ein Problem war, sondern drei.

Das Zertifikat. Laut Veeam war die Prüfung interner Zertifikate vor Version 13 nachsichtiger. Das alte Zertifikat erfüllte die neuen Anforderungen nicht mehr. Es wurde am Backup-Server neu erzeugt.

Ein neuer Port. Das Plugin meldet sich in Version 13 zusätzlich über den Identity Service an. Dafür lädt es eine OpenID-Konfiguration vom Backup-Server, und zwar über Port 443. Diese Anforderung gab es in Version 12 nicht. Wer seine Firewall-Regeln aus der alten Version übernommen hat, hat sie nicht.

Jede Adresse. Das war die eigentliche Bruchstelle. Der Backup-Server hatte eine zweite Netzwerkkarte in einem Storage-Netz, das nicht geroutet ist. Das Plugin probierte die Anmeldung über alle Adressen des Servers durch, auch über diese. Jeder Versuch lief rund 30 Sekunden in den Timeout. Auf dem Repository stand ebenfalls eine zweite, nicht geroutete Adresse, und auch die versuchte das Plugin für den Datentransfer auf Port 6162.

In Version 12 hatte diese zweite Netzwerkkarte niemanden gestört.

Wie es wieder lief

In dieser Reihenfolge:

  1. Zertifikat am Backup-Server neu erzeugt.
  2. Das Plugin im Assistenten neu eingerichtet, mit der IP-Adresse des Backup-Servers statt seines Namens. Danach lief die Konfiguration durch.
  3. Auf der Seite des Plugins Preferred Networks gesetzt, mit dem Konfigurationswerkzeug des Plugins (SapBackintConfigTool). Veeam beschreibt das in Specifying Preferred Networks for Veeam Plug-Ins .
  4. Port 6162 zum Repository in der Firewall geöffnet.

Danach liefen die Sicherungen wieder.

Was nicht ganz aufgeht

Warum das Zertifikat am Anfang überhaupt eine Rolle gespielt hat und warum ausgerechnet der Wechsel vom Namen auf die IP-Adresse den Knoten gelöst hat, ist uns bis heute nicht klar. Firewall und Netz erklären den Rest. Diese beiden Punkte nicht. Wir haben es im Fall auch so gesagt. Es ging danach, und mehr wissen wir nicht.

Was wir daraus mitnehmen

  • Vor dem Upgrade auf Version 13 nicht nur die Ports prüfen, sondern auch die Netzwerkkarten. Das Plugin nimmt jede Adresse, die der Server meldet.
  • Preferred Networks gehören von Anfang an gesetzt, nicht erst, wenn etwas hängt.
  • Port 443 zum Backup-Server und Port 6162 zum Repository gehören in die Firewall-Matrix.
  • Alte, selbst ausgestellte Zertifikate vor dem Upgrade erneuern. Was Version 12 noch hingenommen hat, nimmt Version 13 nicht mehr hin.
  • Ein Telnet, das durchkommt, beweist nur, dass ein Port offen ist. Nicht, dass das Plugin ihn auch benutzt.

Warum jetzt auf 13.1?

Dieser Fall lief auf 13.0.1, nicht auf 13.1. Die neue Anforderung, Port 443 für die Anmeldung des Plugins, kam mit Version 13. Sie gilt also genauso für jeden, der von 12 direkt auf 13.1 geht.

Im Kern war es ein Firewall-Thema. Und an der Firewall ändert 13.1 etwas. Laut Veeam lief die Backup-Kommunikation bisher über einen breiten dynamischen Portbereich, 2500 bis 3300. In 13.1 läuft sie über einen einzigen Port. Die REST API braucht keinen eigenen Port mehr und antwortet auf 443.

Ob das auch die Plugins betrifft, sagt Veeam an dieser Stelle nicht. Dass 13.1 diesen Fall verhindert hätte, behaupten wir deshalb nicht. Aber weniger Ports in der Matrix heißt weniger Stellen, an denen so etwas hängen bleibt.

Warum also jetzt? Wer ohnehin auf Version 13 geht, plant die Firewall-Matrix einmal, und zwar gleich für 13.1. Mit 443 zum Backup-Server, mit Preferred Networks für die Plugins und mit einem Blick auf jede zweite Netzwerkkarte.