Close the temporary preview before it becomes permanent

A reviewer who cannot join the VPN needs a link for one afternoon, and by evening the production service has a public hostname nobody remembers approving. The request was small; the change was not. A temporary preview is a new access path with an audience, a data scope, and an end time. Treat it like any other entry, because the word temporary does not close anything.

Temporary is a duration, not a control

The word temporary describes how long something should exist, not what limits it while it exists. A public hostname with no expiry is permanent the moment the person who created it changes teams.

Before anything is exposed, the service owner and the security owner should approve three things: the audience, the data, and the duration.

An existing guest-VPN or review environment is often simpler than publishing the production service. It already has an owner, an approval path, and a removal process. Building a new exception for one afternoon is how a small request becomes a standing asset. Start by asking whether the review can happen inside something that already exists.

Publish one operation, never a subnet

Pick the least entry that still supports the review. Prefer a staging copy with suitable data over production, and an authenticated frontend that reaches one private origin over any kind of subnet route.

A relay with VPN reachability does not have to publish an entire private subnet, and it certainly should not publish the gateway's admin interface.

Name the accounts allowed through and the actions they may take. Restricting by source IP does narrow who can connect. It does not identify a person, because public addresses are shared and they change.

Keep the application's own authorization or an explicitly trusted identity-aware entry. Protect downloads, APIs, and administrative paths, not only the landing page. A frontend that terminates TLS becomes a trusted endpoint, and a private route behind it does not turn a public visitor into a VPN member. Test the excluded paths as carefully as the landing page.

Identity at the frontend, not the source address

Source-IP rules are useful for narrowing exposure and useless for proving who a reviewer is. Home connections change, mobile networks share addresses, and a colleague can be behind the same NAT.

An identity-aware proxy or the application's own login gives you a per-person decision. That is what makes revocation possible later, because you can remove one identity without changing the network.

Keep certificate validation on and block direct access to the origin. If the origin is still reachable from the internet, the frontend is decoration.

Revoke the entitlement and the route

Record an owner and an exact expiry in the operational system that already tracks access. Use time-limited access or scheduled removal where the platform supports it, and add a check in case the automation fails.

At the agreed end, retire the temporary frontend, the route allowance, and the reviewer entitlement through their owners. Existing sessions and long-lived connections need their own treatment, because a removed route does not end them.

A short DNS TTL is not access expiry. It changes how long a resolver keeps the answer. It does not disable an account, cut a live session, or close a port that is still listening.

Cached copies are part of the same problem. Taking the origin path down does not pull back a file someone already saved, and a shared cache may serve copies after the relay is gone. Choose response and storage policy before the review begins.

Check that the old path is really gone

Acceptance is a fresh request that fails, plus the normal VPN workflow still working. Test both, because a removal that breaks the ordinary path is not a clean removal.

From outside the network, confirm the name and the origin are both closed:

dig +short review.example
curl -sSI --max-time 5 https://review.example/
ss -ltnp | grep ':443'

Keep a narrow audit record of what was approved, who could reach it, and when it was removed. That record is the difference between a controlled exception and an unexplained hostname. A temporary preview succeeds when it provides the requested review and then stops providing it. The URL disappearing from a chat message is not that test.