WireGuard Update über VPN-Tunnel

[wickert]

Hallo,
wir haben bei uns in der Firma WireGuard als VPN im Einsatz.
Die installation des Pakets funktioniert problemlos, so lange die Clients im Firmennetz sind.
Wir Installieren WireGuard, kopieren die entsprechende Config, setzen den "LimitedOperatorUI" Eintrag in der Registry und nehmen den User in die Gruppe der "Netzwerkkonfigurations-Operatoren" auf.
Nach einem Reboot kann der User dann manuell den Tunnel aktivieren und deaktvieren.
Es besteht also keine always on Verbindung.

Da manche User im Homeoffice oder bei Kunden unterwegs sind, suchen wir eine Möglichkeit, ein Update über die VPN Verbindung zu machen.
Das war leider erfolglos.
Mein bisheriger Ansatz war:
Alle benötigten Daten lokal kopieren, solange WireGard noch läuft, und dann von da aus installieren, bzw die Config kopieren.
Bei den Tests bricht das Script aber immer ab, nachdem Wireguard deinstalliert wurde.
Nach dem Reboot läuft der OPSI-Client ins Timeout, da keine Verbindung zum Server besteht.
Wenn sich der User wieder anmeldet, passiert nichts mehr.
Wireguard ist deinstalliert und der User ist abgeschnitten vom Firmennetz.
Ein Log gibt es nicht, da die Verbindung zum OPSI-Server unterbrochen wurde.

Wenn wieder eine Verbindung zum Firmennetz und zum OPSI Server besteht, startet das Script erneut und läuft sauber durch.
Da zeigt das Log keine Auffälligkeiten.
Das WAN/VPN Paket ist installiert und lizensiert.
Die Funktion war gegeben, als wir noch SOPHOS als VPN genutzt haben. Das mussten wir allerdings nie aktualisieren.

Hat jemand einen Denkanstoß für mich?
Im Voraus schon mal vielen Dank.

[erzwodezwo]

Was sagt denn das Logfile was nach der Deinstallation passiert, beendet ihr alle Dienste von Wireguard vor der Installation/Deinstallation?
Es kann sein dass Wireguard unbedingt einen Reboot benötigt nach der Deinstallation, dann müsstet ihr euch eine Lösung überlegen wie ihr nach dem Reboot die Installation ohne Verbindung zum OPSI wieder starten könnt, eventuell wäre über einen Runonce key in der Registry eine Möglichkeit.

Gruß
Torsten

[ThomasT]

Hallo,

ohne die WAN/VPN Erweiterung braucht der OPSI-Client-Agent praktisch dauerhaft eine Verbindung zum OPSI-Server.
Im Detail heißt das, bei Start des OPSI-Client-Agents um zu wissen, welche Pakete auf Setup sind. Darauf folgend um das Depot zu verbinden und anschließend um Log-Files und Installationsstatus zurückzuschreiben.
Dies geschieht über die Messagebus-Verbindung welche eine kontinuierliche Kommunikation zwischen Server und Client ermöglicht.
Wenn die Verbindung abbricht, weil z.B. der VPN gekappt wird, dann sieht das für den Server so aus, als wäre der Prozess zwar gestartet, aber nie fertig geworden. Dementsprechend bleibt der Setup-Action-Request bestehen bis der Client sich wieder meldet.

[Andi_089]

Morgen,

wäre es nicht eine Möglichkeit im Skript eine Abfrage einzubauen, ob der VPN Client installiert ist.

Ist installiert:
- Skript deinstalliert den VPN Client
- das Paket wird mit "isSuspended" sozusagen auf Wiederholen gesetzt
- reboot

Dann startet das Paket erneut im WAN Modus

Die Prüfung ergibt diesmal "ist nicht installiert"
- Skript installiert den VPN Client
- das Paket wird mit "isSuccess" als erfolgreich markiert
- reboot

Danach sollte doch alles gut sein oder?

[wickert]

Danke für den Input.
Ich teste aktuell das Setzen eines Registryeintrags und "ExitWindows /ImmediateReboot" um das Script im Anschluss weiterzuführen.

[erzwodezwo]

Hallo,

ohne die WAN/VPN Erweiterung braucht der OPSI-Client-Agent praktisch dauerhaft eine Verbindung zum OPSI-Server.
Im Detail heißt das, bei Start des OPSI-Client-Agents um zu wissen, welche Pakete auf Setup sind. Darauf folgend um das Depot zu verbinden und anschließend um Log-Files und Installationsstatus zurückzuschreiben.
Dies geschieht über die Messagebus-Verbindung welche eine kontinuierliche Kommunikation zwischen Server und Client ermöglicht.
Wenn die Verbindung abbricht, weil z.B. der VPN gekappt wird, dann sieht das für den Server so aus, als wäre der Prozess zwar gestartet, aber nie fertig geworden. Dementsprechend bleibt der Setup-Action-Request bestehen bis der Client sich wieder meldet.

Mann könnte ja im ersten Durchgang einen Regkey setzen "isinstalled" denn man im Script abfrägt, findet das Setp Script diesen setzt es das Paket auf installiert.
So liese sich die WAN Erweiterung umgehen, wobei ich sagen muss mit WAN wäre es natürlich am einfachsten und saubersten

[erzwodezwo]

Ich denke euer Poblem ist ein reines Paketierungsproblem, der Reboot kommt wahrscheinlich daher weil noch Dateien offen sind, d.h er will diesen durchführen um die gesperrten Dateien zu entsperren, ich habe mal kurz quick und dirty getestet und konnte indem ich alle Prozesse vorher beendet habe die Software ohne Reboot deinstallieren und gleich wieder installieren.
Zudem ist der Hinweis von Thomas zu beachten, da er während der Installation die Verbindung zum OPSI verliert müsstet ihr in der Registry einen Key setzen nach erfolgreicher Installation den Ihr bei einer erneuten Installation durch den OPSI Abfragt, wobei es doch so ist dass wenn das Paket erfolgreich durchgelaufen ist er den Erfolg beim nächsten Verbinden mit dem Server melden müsste, das müsstet ihr mal ausprobieren.

[wickert]

Was sagt denn das Logfile was nach der Deinstallation passiert, beendet ihr alle Dienste von Wireguard vor der Installation/Deinstallation?
Es kann sein dass Wireguard unbedingt einen Reboot benötigt nach der Deinstallation, dann müsstet ihr euch eine Lösung überlegen wie ihr nach dem Reboot die Installation ohne Verbindung zum OPSI wieder starten könnt, eventuell wäre über einen Runonce key in der Registry eine Möglichkeit.

Gruß
Torsten

Ich seh vielleicht grad den Wald vor lauter Bäumen nicht ...
Ich habe "ExitWindows /ImmediateReboot" eingebaut nach der Doku hier
https://docs.opsi.org/opsi-docs-de/4.3/ ... nds-reboot

Aber wo finde ich das mit dem Runonce Registry Key in der Doku?
Ich muss ja den irgendwie den Opsi dazu bringen, lokal/im Cache zu suchen und nicht auf den Server zu verbinden

Außerdem habe ich an dem Testrechner immer den VPN-Tunnel gestartet und dann das gebaute Paket "on_demand" installiert.
Wie ich jetzt gelesen habe, greift OPSI hier aber wohl nur auf den Server zu und nutzt keine gecacheten Daten.

[erzwodezwo]

Den runonce key findest Du nicht in OPSI, das ist ein Windows key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

Hier kannst Du einen Installationsbefehl eintragen, der dann beim Start des Computer einmal ausgeführt wird, OPSI nimmt schon lokale Dateien, was aber auf dem Depot direkt läuft ist das Setup Script das Du angelegt hast, ich würde mal folgendes probieren:

- Im Setup Script die Installationsdateien sowie ein Installationspowershell Script auf die lokale Festplatte kopieren
- Die eigentliche Deinstallation / Installation im Powershell ausführen
- Im Powershell alle Wireguard Prozesse vor der Deinstallation beenden
- Powershell: die Deinstallation durchführen
- Powershell: die Installation durchführen
- Powershell: Bei Erfolg irgendwo in der Registry einen Key setzen mit IsInstalled oder so ähnlich
- Läuft das OPSI Script nochmal diesen Key auswerten: IsInstalled vorhanden Paket ist installiert

Du müsstet mal testen wenn Du die Installation komplett über das OPSI Setup file machst was passiert wenn während die das Script läuft die Verbindung zum Server unterbrochen wird, läuft es dann weiter bis zum ende durch oder bricht es ab?

Läuft es weiter dann wäre der Aufbau so:
- Im Script vor der Deinstallation alle Wireguard Prozesse beenden
- Deinstallation durchführen
- Installation durchführen

In meinen Tests war nach der Deinstallation kein Reboot notwendig, ich konnte die neue Version direkt danach installieren. Auch nach der Installation hat es keinen Reboot angefordert.
Läuft das OPSI Script also weiter sollte es auch durchlaufen, ist es erfolgreich sollten die logfiles beim nächsten Kontakt an den Server übergeben werden und der Status ist installed.

Wir hatten in Paketen schon den Fall dass dort Netzwerktreiber installiert wurden, diese unterbrachen auch die Netzwerkverbindung, das Script ist bei uns aber trotzdem durchgelaufen.