Secure ML Collaboration: Sharing a Local Nvidia GPU Workstation with Zero Trust

The obvious solution: remote access

The basic requirement was straightforward:

Friend's computer → Internet → my Linux workstation → GPU

We wanted him to be able to work remotely with the Linux environment and run ML workloads while keeping the workstation inside my private network.

The traditional approach would be something such as a VPN combined with SSH.

That works, but I did not particularly like the idea of creating broad network access simply because somebody needed access to one machine.

I also did not want to expose SSH directly to the public Internet, configure router port forwarding, maintain IP allowlists or turn my local network into something resembling a small publicly accessible server environment.

Instead, I used Twingate.

Enter Zero Trust Network Access

Twingate implements an approach commonly called Zero Trust Network Access — ZTNA.

The underlying idea is more important than the product itself.

Traditional network security often treats location as part of the trust model:

You connected to the private network, therefore you can probably access things inside that network.

Zero Trust changes that assumption.

NIST describes Zero Trust Architecture as an approach where no implicit trust is granted simply because a user or device is located inside a particular network. Access decisions instead focus on identities, devices and individual resources.

In practical terms, the question changes from:

“Can this person enter my network?”

to:

“Can this authenticated person access this specific resource?”

That distinction was exactly what I wanted for this project.

What the architecture looked like

The resulting setup was relatively small:

Collaborator's device
↓
Twingate Client
↓
Authenticated + authorized encrypted connection
↓
Twingate Connector inside my private network
↓
Linux ML workstation
↓
RTX 5070 Ti

I registered the Linux workstation as a private resource and granted my collaborator access through Twingate.

The important part is what I didn't have to do.

I did not need to expose the workstation directly to the public Internet.

I did not need an inbound firewall rule pointing toward the machine.

I did not need router-level SSH port forwarding.

Twingate Connectors initiate outbound connections rather than requiring publicly accessible inbound ports. Twingate then authenticates the user and checks whether that user is authorized to access the requested resource.

This gives the architecture a useful property:

the machine can remain private while still being remotely accessible to an explicitly authorized collaborator.

What happens to the traffic?

There is another interesting detail underneath the setup.

Twingate attempts to establish a direct peer-to-peer connection between the Client and Connector using NAT traversal. When that succeeds, traffic can travel through a direct encrypted connection rather than being routed through a traditional centralized VPN gateway.

If a direct connection cannot be established because of NAT or firewall restrictions, Twingate can fall back to its relay infrastructure.

The Client-to-Connector connection is encrypted, and Twingate documents the use of certificate-pinned TLS connections for these sessions.

From my perspective as the person running the ML workstation, however, most of this complexity disappears.

My friend connects to an authorized resource.

The workstation remains inside the private network.

The access policy determines who can reach it.

That is exactly the abstraction I wanted.

Why this is better than simply sharing a VPN

The biggest lesson from this small experiment was not really about Twingate.

It was about access granularity.

A traditional VPN is commonly designed around extending a network boundary. Once connected, the user's machine effectively becomes part of a remote network to some degree.

ZTNA approaches the problem from the opposite direction.

You start with no assumed access and explicitly expose only what someone needs.

For our ML collaboration, my friend did not need access to my home network.

He did not need to discover other devices.

He did not need access to unrelated services.

He needed access to a computational resource.

So that is what I wanted the architecture to represent.

This also reduces the opportunities for lateral movement. If one endpoint becomes compromised, an attacker should not automatically inherit broad visibility of everything sitting behind the same network boundary.

Instead, access can remain constrained around explicitly authorized resources.

Turning personal hardware into shared infrastructure

The setup also changed how I think about local AI hardware.

A powerful workstation does not necessarily need to behave like a purely personal computer.

With the right access layer, it can become a small private compute node.

For machine-learning collaboration this creates several interesting possibilities:

• remote model training and experimentation,
• shared CUDA environments,
• centralized datasets,
• reproducible development environments,
• remote inference,
• collaborative notebooks and development servers,
• access to specialized hardware without duplicating it.

It sits somewhere between a local workstation and a cloud GPU server.

You retain physical control over the hardware and data while still making the compute remotely usable.

Of course, Zero Trust networking does not replace normal Linux security. SSH keys, user isolation, file permissions, containerization, secrets management and sensible privilege boundaries still matter.

ZTNA solves the network access problem. It should be one layer of the overall security model rather than the entire security model.

References

1. NIST SP 800-207 — Zero Trust Architecture, National Institute of Standards and Technology, 2020.
2. Twingate — Architecture & How Twingate Works, Twingate Documentation.
3. Twingate — Peer-to-Peer Communication, Twingate Documentation.
4. Twingate — Connector Best Practices, Twingate Documentation.
5. NVIDIA GeForce RTX 5070 Family — Specifications, NVIDIA.