After the setup script runs, someone has to own the VPN server
A bootstrap script can build the server; it cannot own the access policy, the update path or the rollback. Define the handoff before you run it.
Two different jobs get sold as one: turning a machine into a VPN server, and adding a VPN client to a laptop that should join someone else's gateway. A setup script answers the first and cannot answer the second, whatever its README implies. Take the setup-ipsec-vpn project as a concrete example: it builds an IPsec/L2TP, Cisco IPsec or IKEv2 server on a supported Linux host using Libreswan and xl2tpd. That is a deployment contract for a server, not a general recipe for any machine. Decide which job you have before the script runs, because everything afterwards is about the server.
Be honest about the host
A machine that also terminates something else, or whose firewall is managed by a cloud control plane rather than by the OS, is a different installation from a clean virtual machine. Write down the protocol you are enabling and the release you are using, then check both against the project's supported list rather than against a blog post from a previous year.
Enabling the service does not open the path to it. For IPsec the network in front of the host has to admit UDP 500 and 4500 and, depending on the deployment, the ESP protocol itself. A script that finishes successfully behind a security group that drops protocol 50 has produced a server nobody can reach, and nothing in the installer's output will say so.
What the installer actually takes over
Expect an IPsec configuration and secrets file, an L2TP daemon configuration, PPP options and systemd units that now own those ports. The project's README states that existing configuration files are backed up before changes, which is useful and is not the same thing as a host backup. Decide which components will be updated by the distribution's packages and which by re-running or rewriting the script, because those are two maintenance paths with different failure modes.
Pin the revision you approved. A download URL that serves a current default branch can return different content next month, so record the commit or release you ran and keep a copy of it. That single habit turns an unattributable state into something a second person can reason about at two in the morning.
What the script cannot hand you
Automation produces a working installation and stops there. It does not decide which private resources the tunnel should reach, which is an access-policy question the host firewall and the upstream network both have opinions about. It does not decide who receives credentials, how they are delivered, or how a person's access is removed when they leave. And it does not decide how the machine is recovered after a bad update, which is the part usually discovered at the worst possible moment.
Client profiles and displayed secrets are access material rather than installation logs. A generated profile pasted into a shared channel is an account, and the same standard applies to screenshots of the setup summary. Keep a protected inventory of the identity state needed to restore service, and note which of those credentials have since been revoked.
The first client is the acceptance test
Accept the deployment from one authorized client, using the protocol you actually enabled. Check that the private name resolves, that the return path works, that a reconnect behaves, and that a destination outside the permitted set is refused. A successful login from a different client application is not evidence about the one you shipped.
If the combination you want is no longer supported, choose a maintained path before installation. Reviving an old release, weakening authentication or re-running an unexplained script are postponements rather than maintenance plans, and each of them makes the handoff harder.
Write the handoff page
Keep it short: the server, the revision that built it, the ports it needs, the components and their update owners, the permitted resources, the credential path and the recovery procedure. Add the console or out-of-band route you will use when a change to the tunnel is what broke access. Then the next person inherits a service rather than a command they are afraid to run twice.
Review that page when the host changes, and not only when something breaks. A handoff document that is never read is a document that quietly stopped being true.