2 Commits (e031d4c20af9f67f77a5d3c00a6e81975c6755f8)

Author	SHA1	Message	Date
nexxo	e3c781f067	Der Tunnel bekommt einen eigenen Container ... Bisher wohnte wg0 im Container des Provisionierungs-Arbeiters, also im Abbild `clupilot-app`. Das wird bei fast jeder Freigabe neu gebaut — und ein neu gebauter Container bekommt eine neue Adresse im Compose-Netz, womit die Weiterleitung fuer UDP 51820 neu geschrieben wird und JEDE bestehende WireGuard-Sitzung abreisst. Der Tunnel hing damit am Veroeffentlichungstakt der Anwendung, und zusaetzlich daran, dass ein PHP-Prozess nicht abstuerzt. Jetzt gehoert der Netz-Namensraum einem eigenen Container `vpn-hub` mit eigenem, winzigem Abbild (Alpine plus wireguard-tools), das sich fast nie aendert. Provisionierungs-Arbeiter, Terminal-Bruecke, interner DNS und internes Gateway steigen dort ein, statt einer von ihnen den Namensraum zu besitzen. NACHGEMESSEN, nicht angenommen: App-Abbild neu gebaut, Arbeiter, Bruecke und Gateway per --force-recreate neu erzeugt — der Hub blieb Container 92e928cf53b0, wg0 und beide Zugaenge unangetastet, und nginx erreichte die Bruecke weiter (HTTP 426). Genau der Vorgang, der bisher jedes Mal alles abgerissen hat. Nachgezogen: - nginx spricht die Bruecke unter `vpn-hub:8082` an — dem Namen des Namensraum-Eigentuemers; ein Mitbewohner hat keinen eigenen DNS-Eintrag. - update.sh baut vpn-hub mit und haengt Nachbar-Neustarts und den conntrack-Griff an die Frage, ob der Hub WIRKLICH neu gebaut wurde. - update-agent.sh startet den Arbeiter nicht mehr neu, sondern signalisiert ihm. Diese Stelle laeuft unbeaufsichtigt hinter dem Knopf „Dienste neu starten" — wer den drueckt, rechnet nicht damit, sich selbst auszusperren. - Vier Meldungen in der Konsole rieten dem Betreiber, genau den Befehl von Hand auszufuehren, der ihm den Tunnel abreisst. Auch die sind korrigiert. - rescue-tunnel.sh und das Runbook zeigen auf den neuen Besitzer. Eine Kleinigkeit unterwegs, die ich falsch angekuendigt hatte: `[[ … ]] && x=true` bricht unter `set -e` NICHT ab — bash nimmt die linke Seite einer &&-Liste ausdruecklich aus. Nachgeprueft; die if-Form bleibt trotzdem, aus Lesbarkeit, und der Kommentar sagt jetzt den wahren Grund. 2509 Tests gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 07:49:29 +02:00
nexxo	2b79a6a2ba	Der Tunnel haengt nicht mehr an einem huebschen Namen und nicht an einem Arbeiter ... Zwei Ursachen, eine davon habe ich mit v1.4.2 selbst gelegt. 1. DER NETZ-ALIAS. Damit in docker/nginx/default.conf `terminal:8082` stehen konnte statt des Namens des Nachbarcontainers, bekam queue-provisioning einen Eintrag unter `networks: aliases:`. Das ist Teil seiner NETZKONFIGURATION — und Compose baut einen Container neu, sobald die sich aendert. Neu gebaut heisst neue Adresse im Compose-Netz, heisst neu geschriebene Weiterleitungsregeln fuer den veroeffentlichten UDP-Port 51820. Auf dem liegt jede bestehende WireGuard-Sitzung. Der Preis fuer einen sprechenderen Namen in einer Konfigurationszeile war also ein Abriss saemtlicher Tunnel beim Ausrollen — der des Betreibers am Telefon wie der jedes Hosts. Alias entfernt, nginx spricht die Bruecke unter `queue-provisioning:8082` an. Nachgemessen: danach laesst `docker compose up -d` den Tunnel-Container unangetastet, und nginx erreicht die Bruecke weiterhin (426 statt 502). 2. DER ARBEITER ALS PROZESS 1. wg0 stand im Namensraum von queue-provisioning, und dessen Prozess 1 war `exec php artisan queue:work provisioning`. Endete der Arbeiter, endete der Container — und mit ihm der Namensraum und jede Sitzung darin. Ein Arbeiter endet oefter, als man denkt: `--timeout=2100` beendet ihn bei einem langen Provisionierungs-Schritt, ein fataler Fehler beendet ihn, ein Speicherlimit beendet ihn, `queue:restart` beendet ihn absichtlich. Aus jedem dieser vier Faelle wurde bisher "das VPN ist unzuverlaessig". Der Rumpf liegt jetzt in docker/provisioning-worker.sh: wg0 einmal hochziehen, danach den Arbeiter in einer Schleife halten, SIGTERM sauber weiterreichen. Nachgemessen: Arbeiter getoetet -> Container hat NULL Neustarts, wg0 steht weiter, Arbeiter ist von allein wieder da. Beide Male bleibt der Netz-Namensraum stehen. Damit verschwindet nebenbei auch der Grund, aus dem update.sh die Bruecke hinterher neu starten musste — die Zeile bleibt trotzdem, sie kostet nichts und traegt den Fall, dass der Container doch einmal neu gebaut wird. NICHT GETAGGT, mit Absicht: diese Aenderung fasst genau das an, was den Zugang des Betreibers traegt. Sie gehoert ausgerollt, wenn jemand davorsitzt und die Konsole des Anbieters als Rueckfahrkarte hat — nicht unbeaufsichtigt vom Update-Agenten, waehrend der Betreiber unterwegs ist. 2508 Tests gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-02 22:58:28 +02:00