simpletest/who_need_help
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Document secured development VPN recovery

Browse Source
This commit is contained in:
SimpleTest 2026-07-23 22:35:34 +03:00
parent 27bcb7188e
commit 0d880fc21e
1 changed files with 20 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
docs/verification.md
View File

@ -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