Eigentlich gar nichts, aber um zwei Ecken dann doch und das sogar mit spürbaren Auswirkungen. Zugegeben, sehr skurril, denn immerhin sprechen wir hier vom angestaubten RFC1413 Protokoll zur Nutzeridentifizierung, das in heutigen Zeiten sein Nischendasein wohl hauptsächlich in IRC-Kreisen fristet. Das dann in Kombi mit VMware vSphere und Veeam Backup and Replication? Ich wollte es erst selbst nicht glauben, aber nach fehlgeschlagenen Veeam Backups und Durchforsten der Logfiles erklärte sich bald ein Zusammenhang … wenn auch um besagte zwei Ecken.

Veeam Backup und vStorage API

Veeams Sicherungslösung unterstützt (wie seine Mitbewerber) einige Daten-Transport-Wege, um VMs Image-basiert und in bester Road-Runner-Manier zu sichern. Einer läuft über die vStorage API und dessen Network Block Device (NBD) Protokoll – ähnlich aber intelligenter als von VCB im Netzwerk-Modus bekannt.

Die Sicherungs-Engine verbindet sich dabei direkt mit dem ESX Host, der die zu sichernde VM beherbergt und saugt sich die relevanten Daten übers Netzwerk.

Access denied?…

Nun kann dies aber fehlschlagen und im konkreten Fall tat es das beim Sichern von VM-Daten mit folgenden Meldungen im B&R Log.

[14.07.2010 10:47:03] < 4204> dsk| >> |VDDK error: 13.You do not have access rights to this file
[14.07.2010 10:47:03] < 4204> dsk| >> |Failed to open VMDK.

Die “no access rights” Meldung sah verdächtig nach Privilegien-Problemen aus, jedoch weder die benötigten Mindest-vCenter-Privilegien für Veeams B&R noch das temporäre Umstellen der verwendeten Credentials auf den Administrator-Account brachten Abhilfe.

… oder doch was anderes?

Schaut man nun ein paar Zeilen weiter oberhalb im Log, sieht man dort Timeout-Meldungen bei Verbindungen zum ESX Host Port 902.

[14.07.2010 10:47:03] < 5844> dsk| WARN|[NFC ERROR] NfcNewAuthdConnectionEx: Failed to connect to peer. Error: Timeout while attempting read
[14.07.2010 10:47:03] < 5844> dsk| NBD_ClientOpen: Couldn't connect to esxtest.roc.consol.de:902 Timeout while attempting read

Hinter diesem Port lauscht der vmware-authd, der Verbindungen vorm Weiterreichen an die ESX Services authentifiziert. Die “no access rights”-Meldungen sind also nur eine Nachwehe des eigentlichen Problems, den Timeouts bei der Authentifizierung. Eine testweise aufgebaute manuelle Verbindung zeigt, dass eine Verbindung zwar zustande kommt, der authd aber erst nach 10 Sekunden mit einer Antwort aufwartet …

telnet esxhost.domain.tld 902
(Pause)
220 VMware Authentication Daemon Version 1.10: ...

Genau das ist der Timeout, den B&R bei Verbindungsversuchen verwendet, somit die Antwort vom authd wohl ganz knapp nicht mehr mitbekommt und ergo keine Authentifizierung zustande kommt.

Der Bösewicht: xinetd/libwrap, Ident und eine Windows Firewall

Warum nun braucht der authd die Denkpause, bis er antwortet? Mit etwas tcpdump und strace in der Service Console (ich vermiss die jetzt schon) war der Übeltäter schnell identifiziert: Eingehende Verbindungen auf Port 902 werden zuerst von xinetd entgegen genommen, der mit libwrap arbeitet, was wiederum einen (nicht Authentifizierungs-kritischen) Ident Lookup in Gegenrichtung, also zum Veeam Backup Server, TCP Port 113, auslöst.

Auf dem lauscht bei Windows-Systemen von Haus aus nichts. Verbindungsversuche sollten also umgehend abgelehnt werden. Nur nicht so bei vorliegendem Veeam Server. Dort war die Windows Firewall aktiv, welche eingehende Verbindungen auf TCP Port 113 ohne Antwort an die Gegenstelle einfach verwarf. xinetd/libwrap warteten also 10 Sekunden auf eine Antwort die nicht kam und erst dann wurde authd gestartet.

Die Definition einer Firewall-Ausnahme-Regel für TCP Port 113 löste folglich das Problem. Eigentlich unsinnig, da dort nichts lauscht, aber nichtsdestotrotz effektiv. Eine Anpassung der /etc/hosts.allow zur Unterdrückung der Ident Lookups wäre eine andere Alternative, diese wiederum müsste man aber auf allen ESX Hosts ausrollen.

Lange Rede, kurzer Sinn

Die auf ESX Servern beheimatete xinetd/libwrap/authd-Kombination führt also bei eingehenden Verbindungen auf Port 902 zu Ident Lookups, die bei aktiver Windows Firewall auf der Gegenstelle erstmal in einen 10 Sekunden-Timeout laufen und Veeam Backup and Replication in der Zwischenzeit aufgibt. So zumindest beobachtet mit ESX 4.0U1. Warum der Fehler bei so einer gängigen Konfiguration nicht bei Tante Google zu finden ist, ist mir unklar. Aber das sollte sich hiermit ändern.