ugg.li Schnelle Hilfe für schnelle Admins
Nicht immer schön, aber effektiv. Schnelle Hilfe für schnelle Admins.
Ich habe grade das erste Mal einen Administrator gesehen, der unter Windows die „Erweiterungen bei bekannten Dateitypen“ ausblendete.
Das passierte während einer remote-session und er murmelte etwas von ’sowasbrauchtdochniemand‘.
Nach einer kurzen und nicht repräsentativen Umfrage im Büro sind wir sicher, das die Telefonseelsorge ihn bald anruft und fragt, ob es ihm gutgeht 😅
Wie viel Lack …
Auch nach vielfacher Kontrolle der IKE Proposals (IKEv2 in diesem Fall), lässt sich ein VPN-Tunnel manchmal partout nicht aufbauen. Das ist uns ein paar mal bei Gegenstellen von Palo Alto begegnet – was aber Zufall sein mag. IPSEC Implementierungen gibt es viele. Auf der Lokalen Seite waren es verschiedene Setups, darunter Lancom, SonicWall, Sophos und ein nativer strongSwan.
Der Tunnelaufbau scheitert direkt in Phase 1, nachdem die Encryption Proposals akzeptiert wurden:
Message: IKEv2 Initiator: Proposed IKE ID mismatch
Notes:VPN Policy: POLICYNAME; id <IP>, does not match peer IKE id in policy
Die lokale und remote IKE ID müssen vom Typ IP(v4) sein und eine IP(v4) Adresse enthalten.
RFC 7296 definiert für IKEv2 sieben verschiedene ID Typen (Peer ID / Local ID). DArunter FQDN, ASN Identifier, IPv6 und weitere. Aber es gibt einen spannenden „should“ Passus, der die Kompatibilität der Verhandlung potenziell einschränkt:
To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
MUST be configurable to accept all of these four types.
Implementations SHOULD be capable of generating and accepting all of these types.
Genau das macht Palo Alto nicht: Die (heute) aktuellen Geräte unterstützen nur einen einzigen Typ: IPv4 (einzelne IP-Adresse). Ob das ein RFC-Verstoß ist, ist eine Frage der Rhetorik, denn die Typen „sollen“ ja auch nur unterstützt werden. MÜSSEN konfigurierbar sein (unserer Ansicht nach auch eher zweifelhaft), SOLLEN aber gesendet und empfangen werden können.
Alle anderen Typenkombination (die wir ausprobiert haben) scheiterten. Auch wenn das ID-Feld in Panorama wie ein „String“ Feld aussieht und sich (eingabetechnisch) auch so verhält – der Typ der im IKE-Paket ausgegeben wird, ist immer „IP“. Stell man beide Seiten auf IP, geht der Tunnel (mit diesem Fehler) sofort auf.
Nach dem Update auf Version 13 startet die Veeam Backup & Replication Konsole in der Regel nicht mehr.
Das Verbindungs-Fenster meckert stattdessen:
Failed to connect to the backup server: Access to the
registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\Veeam
\Veeam Backup and Replication\Plugins' is denied.Auf den genannten Registry-Schlüssel braucht man nur die Berechtigung „Lesen“ für „Authentifizierte Benutzer“ zu vererben und schon geht die Konsole (für jeden Benutzer des Computers) wieder fehlerfrei auf.
HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication\Plugins
Nach dem Upgrade der VMware Tools auf Version 13 (0.1.0+) startet der „VMware Tools“ Dienst auf virtuellen Maschinen (VMs) unter Windows Server 2019 nicht mehr. Versucht man das manuell, sieht man im Anwendungs-Ereignisprotokoll die Meldung:
Name der fehlerhaften Anwendung: vmtoolsd.exe, Version: 13.0.5.0,
Name des fehlerhaften Moduls: MSVCP140.dll, Version: 14.36.32532.0,
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0000000000012f58
ID des fehlerhaften Prozesses: 0x2b8
Pfad der fehlerhaften Anwendung: C:\Program Files\VMware\VMware Tools\vmtoolsd.exe
Pfad des fehlerhaften Moduls: C:\Windows\SYSTEM32\MSVCP140.dll
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist: 
Die jeweils aktuelle Microsoft Visual C++ Redistributable (14) installieren und neu starten.
Link zum „latest“ C++ Redist download: https://aka.ms/vc14/vc_redist.x64.exe
Danach starten die Tools wieder fehlerfrei.