[GELÖST] Geräte seit Update 2.5 getrennt

[morvan-n]

Debian Server 12
wapt Version 2.5.2.15207

Guten Morgen,

Nach dem Update auf Version 2.5 werden alle meine Workstations in der Konsole als getrennt angezeigt.

Ich habe die im anderen Beitrag beschriebene Vorgehensweise ausprobiert, jedoch ohne Erfolg.

Code: Alle auswählen

net stop waptservice
suppression des fichiers C:\Program Files (x86)\wapt\log\waptservicestate et C:\Program Files (x86)\wapt\log\waptservicestate.html
net start waptservice

Die Befehle wapt-get update und wapt-get upgrade funktionieren vom Client aus.

Ich habe die Zertifikatsauthentifizierung beim Upgrade auf Version 2.5 aktiviert und einen neuen Agenten generiert, um meine Clients zu aktualisieren.

Hier ist die Fehlermeldung, die ich in der Datei waptserveur.log erhalte:

Code: Alle auswählen

connection refused for uuid xxx, sid xxx: SocketIO connection not authorized, invalid token: No authorization token, instance

Ich danke Ihnen für Ihre Hilfe
Nicolas

[Crous Straßburg]

Hallo,

ich hatte dasselbe Problem.

UMGEHUNG:
Während der PostConf auf dem Server können Sie die Zertifikatsprüfung deaktivieren und stattdessen „
HTTPS-Clientzertifikat nicht prüfen (Legacy)“ auswählen.

Dann werden die Client-Rechner in Ihrer Konsole angezeigt. Allerdings tritt dabei ein weiterer Fehler auf: Die Rechner bleiben trotz Aktualisierung verbunden.
Sie müssen die Verbindung dann zurücksetzen, indem Sie in der Konsole des betreffenden Hosts „Bestehende WebSocket-Verbindungen zurücksetzen“ ausführen.

LÖSUNG:
Diese Lösung wurde mir von Tranquil It vorgeschlagen. Ich habe jedoch eine Lösung für das ursprüngliche Problem gefunden: Ich nutzte Debian 11 und habe auf 12 aktualisiert. Dadurch wurde das Problem behoben.

Schönen Tag noch,
Matthieu

[morvan-n]

Hallo,

vielen Dank für Ihr Feedback. Tatsächlich werden meine verbundenen Geräte in der Konsole wieder angezeigt, wenn ich die Option „HTTPS-Clientzertifikat nicht prüfen (Legacy)“ aktiviere. Ein Zurücksetzen des WebSockets hat jedoch keine Wirkung, und alle meine Geräte sind weiterhin verbunden.

Letztendlich gibt es momentan keine perfekte Lösung.

Mit freundlichen Grüßen,
Nicolas

[bkolovljanovic]

Hallo Nicolas,

diese Probleme wurden in Version 2.5.3 behoben.

[morvan-n]

Hallo,

ja, mit Version 2.5.3 funktioniert wieder alles einwandfrei.

Nicolas

[kvnwsr]

Hallo,

wir haben dasselbe Problem.
Wir haben Version 2.5.3 installiert, aber das Problem besteht weiterhin.

Der Server läuft mit AlmaLinux Version 8.9 (Midnight Oncilla).

Bisher hat keine der vorgeschlagenen Lösungen funktioniert.

Vielen Dank für Ihre Hilfe,
Kevin.

[dcardon]

Hallo Kevin,

hast du einen Reverse-Proxy vor deinem WAPT-Server, eine Firewall/WAF oder Ähnliches?

Ist die Verbindung HTTPS? Ist die Zertifikatsvalidierung auf dem Client aktiviert?

In Version 2.5.3 haben wir die Option „HTTPS-Clientzertifikat nicht prüfen (Legacy)“ entfernt. Diese Option deaktiviert die SSL-Authentifizierung auf Nginx-Ebene (die dann an Python-Skripte delegiert wird). Sie verursacht tatsächlich mehr Probleme, als sie löst.

Viele Grüße,

Denis

[kvnwsr]

Hallo Denis,

vielen Dank für Ihre Antwort.

Wir verwenden keinen Reverse-Proxy.
Ich habe die Firewall deaktiviert, aber das hat nichts geändert.

Die Verbindung wird über HTTPS hergestellt, und die Zertifikatsvalidierung ist auf den Clients nicht aktiviert.
Unsere Konfiguration funktionierte in Version 2.4 einwandfrei.

Kann ich auf Version 2.4 zurückgehen, da einige Clients bereits auf 2.5.3 aktualisiert haben?

[Christophe]

Hallo,
ich habe nach dem Upgrade auf Version 2.5.3 genau dasselbe Problem wie Kevin.
Zur Info: Ich arbeite auf einem Windows-Server.
Wir haben auch keinen Reverse-Proxy, und die Firewall ist auf dem Client deaktiviert.

Ich bin vorerst auf Version 2.4 (Snapshot) zurückgegangen.
Ich habe eine vollständige Kopie unseres Servers und eines Clients erstellt, um Version 2.5.3 in einem isolierten Netzwerk zu testen. Ich kann die Ursache des Problems aber nicht finden.

[Christophe]

Mein Fehler, ich hatte nicht bedacht, dass meine Clients ebenfalls Version 2.5 benötigen, um wieder auf dem Server verfügbar zu sein.

Das Problem sollte sich daher für meine Domänen-PCs mithilfe der Gruppenrichtlinie zur Agenteninstallation beheben lassen. Wie installiere ich aber den Client 2.5 für meine Nicht-Domänen-PCs?