Move a Machine From the VPN to the Workshop Without Losing It

A machine leaves a customer site, arrives in a workshop, and keeps the same asset identity while its network location changes completely. Three conditions decide how much planning that move needs. Whether the customer reuses addresses you also use internally, whether the workshop segment is isolated from staff networks, and whether the old path can be suppressed rather than merely outranked. Get the first one wrong and you debug a machine that is fine.

Identity is not an address

Inventory and naming should carry the asset, the customer and the job. The address carries where the machine is attached right now, which is a fact that changes when it moves. Conflating the two produces the classic mistake of reading meaning into digits.

A serial number encoded in the last octet feels tidy and proves nothing to a router. Prefix lengths decide what a host considers local, and no amount of memorable numbering changes that arithmetic.

If you want the address to hint at the customer, that is a convention, and conventions are fine as long as nobody builds policy on them. Search the inventory for the asset, not the address, and the workshop move stops being a scavenger hunt. It also survives the renumbering that eventually arrives at every site.

A serial is not a prefix length

Devices that use a broad mask such as 10.0.0.0/8 will treat every address in that range as on-link, so traffic to a customer's machine two networks away never reaches a router at all. The machine simply broadcasts for a neighbour that cannot answer.

RFC 4632 defines prefixes by length rather than by what the dotted digits suggest. Your plan needs explicit lengths for each attachment group: a service segment, a customer context, a workshop bench. Naming those groups first makes the lengths obvious.

The practical rule is to design the smallest prefix that covers one attachment group and use it everywhere in that group. Address text is for humans; the mask is what the kernel acts on.

When two customers reuse the same addresses

Customer A and Customer B can both run 192.168.10.0/24, and they will both be right in their own buildings. That is not a problem to solve by renumbering someone else's plant.

Keep the contexts separate, or provide deliberate aliases through a design that documents which address belongs to which customer at which moment. A global inventory is the right tool for telling the machines apart; it is not evidence that the addresses are globally unique. The alias path needs a written expiry rule, or it outlives the job that created it.

What you must avoid is having both contexts reachable at once with no marker. Two identical addresses on two live paths is the failure mode that sends a firmware update to the wrong machine. The symptom rarely looks like an error; it looks like a device someone else reconfigured. Marker first, then reachability.

Give the workshop its own boundary

Customer equipment arriving for service belongs in a service segment with explicit permitted access, not plugged into a staff network because a bench port was free.

Treat an unfamiliar industrial device as another trust domain. Record which engineering host may reach it, which services that host needs, and which credentials belong to the job. Keep the customer's files with the customer's job rather than on a shared drive everyone can read.

The isolation has to survive the boring middle of the job as well: while it is being updated, while it sits overnight, and while it waits for a courier.

Hand the route over as a job step

Normally the central router reaches the machine through the customer's tunnel. When the machine is on the bench, the workshop path becomes the owner for that prefix, or for a narrower destination if you only need one service.

Write down three things before the move: the old path, the new path, and how the change gets reversed. A handoff that only exists in someone's memory is not a handoff.

Be careful with metrics. A lower metric only matters among routes that the selection process actually compares, and a more specific prefix or a policy rule can decide the outcome before metrics are consulted at all.

Include stale sessions in the plan. A connection that was established over the old path can keep delivering commands after the route changes, which is exactly the situation where two copies of one address do real damage. Close the old path explicitly instead of waiting for it to time out.

Close the loop when the machine ships

Restore the intended remote route, remove the temporary grants, and confirm the asset at the endpoint you believe is selected. Then verify from the customer side rather than only from the workshop.

Name resolution and inventory do the operator-facing work here: a stable name and a searchable asset record make the task predictable while the network plan stays honest about where the machine is today.

The test of a good handoff is that a colleague who has never seen the job can read your notes and answer one question: if this machine answers now, which path did the answer come from? If the notes cannot answer that, the handoff is documented but not finished.