tailscale / tailscale/tailscale
testing: do VM-based interop/connectivity testing in simulated virtual internet (natlab v2)
- Dominant language
- Go
- Stars
- 36.5k
- Forks
- 3.2k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 123
Description
Back in Jan 2020, @danderson and I were lamenting that testing Tailscale (once we got [NAT traversal](https://tailscale.com/blog/how-nat-traversal-works) and DERP working) was going to be a pain due to all the moving parts and network dependencies.
We'd figured we were probably going to have to do some Linux-specific root-requiring mess of TAP bridges and iptables and stuff.
By around July 2020 we got Tailscale [actually working](https://tailscale.com/blog/tailscale-v0.100). The testing we added for that 0.100 release was called "NAT Lab" (`tstest/natlab`) and is a pure Go, in-memory `net.PacketConn` fake that simulates various NAT and firewall setups, and then we plugged it into magicsock (6c740650532a78ca8).
But in the four years since, Tailscale has gotten more complicated (e.g. port mapping, endpoints over disco, endpoints via cloud provider API, ...) and our testing hasn't kept up.
This is a tracking bug to add VM-based connectivity interop tests to run two+ VMs hooked up to the same virtual network (various hypervisors including qemu have protocols to fake out the whole network).
This can be done all in userspace, without root, on macOS or Linux. And with qemu microvm machines, they can boot super quickly. And with our [Gokrazy](https://gokrazy.org/) appliance, we don't need to wait for a userspace to boot either.
The goal's to have a little Go-based DSL to represent arbitrary nodes and network configurations and see if two of them can talk to each other over Tailscale, and how.
Contributor guide
Assessment
This issue has not been assessed yet.