From 0d880fc21e1a12716c1c94e9d16c4b95f416fa8a Mon Sep 17 00:00:00 2001 From: SimpleTest Date: Thu, 23 Jul 2026 22:35:34 +0300 Subject: [PATCH] Document secured development VPN recovery --- docs/verification.md | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/docs/verification.md b/docs/verification.md index 61f853c..3d43e27 100644 --- a/docs/verification.md +++ b/docs/verification.md @@ -800,14 +800,26 @@ after this section. on 2 healthy web and 2 running worker replicas. The deployment diff was empty; the final read-only observation remains 2 users, 1 request, 7 messages, 4 ended tracking sessions, and 10 migrations. -- After the workstation restart, the public route initially timed out because - its existing OpenVPN connection was down. Inspection confirmed Nginx still - targeted the assigned client address `10.8.0.14`; reactivating the existing - `client1` NetworkManager profile restored that address and the public path. - The final observation returned HTTPS 200, HTTP 301 to HTTPS, and the correct - `77.110.101.144` endpoint. Headed Chrome then rendered the homepage with zero - console errors or warnings; its document, CSS, JS, and logo requests returned - 200. The visible browser was left open. +- After the workstation restart, the development route initially timed out + because its existing OpenVPN connection was down. Read-only inspection + confirmed the gateway Nginx site still targeted the assigned client address + `10.8.0.14:4010`, while the workstation had no tunnel interface. The exact + NetworkManager profile was `openvpn__toha_nobara_pc`; its observed historical + lease was the same `10.8.0.14`. +- The profile emitted OpenVPN's warning that no server-certificate verification + method was enabled. After checking the installed NetworkManager, + NetworkManager-openvpn, and OpenVPN versions and the OpenVPN 2.7 manual, the + local profile was changed to require `remote-cert-tls=server`. Reactivation + restored `tun0` at `10.8.0.14`; the subsequent journal showed the expected + server peer and completed initialization without the certificate-verification + warning. The remaining `persist-key` and legacy cipher notices were recorded + but not changed without a separate compatibility review. +- The gateway could then reach `http://10.8.0.14:4010/healthz/ready`, and both + the public development readiness endpoint and homepage returned HTTPS 200. + The online Android App Links verifier also passed for the staging package, + staging signing certificate, and `https://whoneedhelp.imalto.site` statement. + No Nginx, test, production, Devpost, remote Git, or deployed application + configuration was changed by this recovery. - Scoped cleanup left zero containers, volumes, and networks for the `who_need_help_load` project and removed its ignored observability/backup-S3 runtime directories. The reusable ordinary public Compose project and the