As an aside, I do still think it's worth open sourcing the tunnel server, but I decided not to try to use it for testing the client because it depends on DNS for proxying.

Ok, I've chased down the immediate problem, but I'm not clear how to fix it.

When you close a Device, this nils out the netstack.netTun.dispatcher that peer.RoutineSequentialReceiver() goroutine uses to communicate. There appears to be some sort of race condition where the goroutine then attempts to access this memory and segfaults.

Ok, some more information: we can avoid this segfault by calling device.RemoveAllPeers() before closing. This waits on the peers being stopped, and avoids the race that leads to segfault.

This should fixup the devtunnel, but the bug is still lurking in wireguard-go which is a tailscale dependency. Depending on their usage we could still be subject to these segfaults. I'll chase the wireguard maintainers about accepting a fix, or fixing it themselves. It's all via email, so no GitHub issue to track.