Der Betreiber hat es dreimal hintereinander erlebt: Update gefahren, VPN weg.
Die Ursache dafuer, dass es JEDES Mal passierte, stand hier:
docker compose restart queue queue-provisioning scheduler reverb
In dessen Netz-Namensraum lebt wg0. `restart` baut den Namensraum neu auf, also
riss jede WireGuard-Sitzung ab — die des Betreibers am Telefon wie die jedes
Hosts. Fuer ein Update, das nur PHP-Code aendert, ist das ein absurder Preis.
Seit der Arbeiter dort in einer Schleife laeuft (v1.4.4), geht es billiger:
`queue:restart` setzt ein Signal, der Arbeiter beendet sich nach dem laufenden
Auftrag, die Schleife startet ihn mit dem neuen Code neu. Der Container bleibt
stehen, wg0 bleibt oben, niemand merkt etwas.
Und fuer den Fall, dass `up -d` ihn doch neu baut (neues Abbild, geaenderte
Konfiguration): das Skript merkt sich die Container-ID vorher und nachher. Hat
sie sich geaendert, raeumt es die gemerkten UDP-Stroeme selbst weg —
`sudo -n conntrack -D -p udp --dport <port>`, und wenn es das nicht darf, steht
der Befehl als Warnung im Protokoll statt gar nichts.
Dieser Handgriff war bisher muendliche Ueberlieferung. Ohne ihn zeigen die
gemerkten Stroeme weiter auf den alten Container, und sie verfallen nicht:
WireGuard schickt alle 25 Sekunden ein Lebenszeichen und haelt den kaputten
Eintrag am Leben. Genau deshalb kam ein Telefon nach Aus- und Einschalten sofort
zurueck (neuer Quellport) und ein Host mit festem Port ueberhaupt nicht.
Ein Test haelt beides fest: queue-provisioning darf nicht in der Neustart-Liste
stehen, und der conntrack-Griff muss im Skript bleiben.
2509 Tests gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4b3f1bb4ff