You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A client config is a static artefact, and culvert has no way to tell an operator that the configs people are holding no longer match what the server would issue today.
Three settings have moved under already-issued clients at various points, each silently:
Endpoint. v2.1.15 separated the dialled address from the certificate identity (fix(client): separate the address clients dial from the certificate identity #37). A config issued before that names the server CN, and on a split-horizon zone that config cannot recover. Configs issued after carry the literal. Nothing tells the operator which of their users hold which.
MTU.wg_mtu comes from the profile. Moving a deployment onto the mobile profile takes the server's wg0 to 1280 and leaves every already-issued .conf at 1420. The MSS clamp reads the SERVER's value, so it cannot correct a client that is advertising more.
DNS.build_dns_line deduping and the dns2 handling changed in the same release. Older configs carry the old line.
In each case the server is correct, every newly issued config is correct, and the person still running last month's zip is quietly broken. The operator's only signal is a user complaining, and the complaint does not say "my config is stale" -- it says the tunnel drops.
This is not hypothetical. It is the live hypothesis on #41.
What would fix it: the server knows every peer, and it knows what it would generate for that peer right now. Comparing the two is a report an operator can act on -- which clients need a re-issue, and why. A generate-client warning when the stored peer's config would differ from a fresh one would catch it at the point someone is already thinking about that client.
Adjacent, and cheaper: say it in docs/vpn-client-setup.md. Right now nothing tells a user that a config has a shelf life or that they should re-pull after a server change.
Done when an operator can ask culvert which issued clients are stale and get a list, rather than finding out from a user four days later.
A client config is a static artefact, and culvert has no way to tell an operator that the configs people are holding no longer match what the server would issue today.
Three settings have moved under already-issued clients at various points, each silently:
wg_mtucomes from the profile. Moving a deployment onto the mobile profile takes the server's wg0 to 1280 and leaves every already-issued.confat 1420. The MSS clamp reads the SERVER's value, so it cannot correct a client that is advertising more.build_dns_linededuping and the dns2 handling changed in the same release. Older configs carry the old line.In each case the server is correct, every newly issued config is correct, and the person still running last month's zip is quietly broken. The operator's only signal is a user complaining, and the complaint does not say "my config is stale" -- it says the tunnel drops.
This is not hypothetical. It is the live hypothesis on #41.
What would fix it: the server knows every peer, and it knows what it would generate for that peer right now. Comparing the two is a report an operator can act on -- which clients need a re-issue, and why. A
generate-clientwarning when the stored peer's config would differ from a fresh one would catch it at the point someone is already thinking about that client.Adjacent, and cheaper: say it in
docs/vpn-client-setup.md. Right now nothing tells a user that a config has a shelf life or that they should re-pull after a server change.Done when an operator can ask culvert which issued clients are stale and get a list, rather than finding out from a user four days later.