Live data from Hacker News

Tailscale Peer Relays

tailscale.com

21–30 of 118 posts

Re: Tailscale Peer Relays

#21
post #4

How to do site-to-site traffic over Tailscale / WG encryption? From preliminary testing, it seems have difficulty to saturate a 10Gbps connection while plain HTTP (nginx) traffic does that fine. Of course it should vary from CPU to CPU, but any tips how to improve that? Ideally I would love to go over with encrypted traffic, although everything is public, just one less thing need to be careful (in case future need to…

You'd need to analyze what's bottlenecking when you're doing that.

Even a cursory look at htop on both ends while you're trying to saturate that link would be informative.

Re: Tailscale Peer Relays

#22
post #9

Hard to parse the networking jargon, but does this enable offline connections? If I have two devices on my local LAN (both connected to a Tailnet) and my home internet goes, currently the devices disconnect from each other. I have been looking for a way to prevent that, so that the all devices connected to the same WiFi network on a tailnet can find each other even if the internet connection to the wider world is bro…

> my home internet goes, currently the devices disconnect from each other. You might be able to solve this by hosting your own control plane such as Headscale. Instead of having Tailscale manage/coordinate all the nodes on tailnet. https://github.com/juanfont/headscale

I ran headscale for a while and can confirm local devices could still chat when the internet went down.

Re: Tailscale Peer Relays

#23
What's the use case for this? It seems to be for situations where you might have a SaaS product, but there is some data required from a customer system. You'd expose the customer data using this relay and integrate into the SaaS. Is that the gist of it? Integration would still likely involve you giving the customer some software to expose a limited API and handle auth, logging, etc.

Re: Tailscale Peer Relays

#25

Hard to parse the networking jargon, but does this enable offline connections? If I have two devices on my local LAN (both connected to a Tailnet) and my home internet goes, currently the devices disconnect from each other. I have been looking for a way to prevent that, so that the all devices connected to the same WiFi network on a tailnet can find each other even if the internet connection to the wider world is bro…

That'd be easy if only wireguard supported multiple endpoints per peer, then one could add the ULA address of the local devices in addition to the external one.

Re: Tailscale Peer Relays

#27
> All customers can use two peer relays, for free, forever. As your needs scale, so will the number of available peer relays. To add even more peer relays to your tailnet, come have a chat with us.

I have to pay to be able to donate my own infra to make tailscale's service better?

Re: Tailscale Peer Relays

#28
post #16

Earlier quoted context omitted.

Wireguard can do what you're describing.

Wireguard can't punch through NATs or firewalls without third party software like Tailscale. Also I'm pretty sure each peer to peer connection needs to be individually set up in a config file ahead of time

Nebula[0] addresses this and is IMO an improvement over WireGuard. Came out of Slack originally, and it supports peer discovery, NAT hole punching, and some other cool features. Also still uses the Noise Protocol.

In practice, the extra networking features + better first class peer config management baked in is very nice (Nebula’s “lighthouses” are configured with a tool similar to DSNet for Wireguard[1])

[0] https://github.com/slackhq/nebula [1] https://github.com/naggie/dsnet

Re: Tailscale Peer Relays

#29
post #23

What's the use case for this? It seems to be for situations where you might have a SaaS product, but there is some data required from a customer system. You'd expose the customer data using this relay and integrate into the SaaS. Is that the gist of it? Integration would still likely involve you giving the customer some software to expose a limited API and handle auth, logging, etc.

They are an alternative to the tailscale operated DERP servers, which are cloud relays.

Even with the much touted NAT punching capabilities of tailscale, there are numerous instances where tailscale cannot establish a true p2p connection. The last fallback is the quite slow DERP relay and from experience it gets used very often.

If you have a peer in your tailscale network that has a good connection and that maybe you can even expose to the internet with a port forward on your router, you now have this relay setting that you can enable to avoid using the congested/shared DERP servers. So there is not really a new use-case for this. It's the same, just faster.

Post reply on HN