tailscale 为什么经常打洞失败？

[FaiChou]

同一个小区内（一个在 A 楼，一个在 B 楼），同一个运营商（联通）。

两个地方都是用 OpenWrt ，开了 fullcon nat （测试发现其实是 Port-Restricted Cone NAT ）。

使用 tailscale 连接组网，测试发现经常会直连失败，而去走 derp ，尤其是晚高峰时候。

不清楚是 tailscale 自己程序的问题还是运营商的限制。

tailscale 是暴力遍历端口（它们官网有教程），实践下来还是能够打洞成功的。

但真正使用的时候就打洞失败，可用性差。

所以想问下，tailscale 是否支持手动配置端口转发（已有公网 ip ）？

不想一直在 op 后台开一个端口，这样风险太大了（吃过这样的亏）。

我的想法是，打洞失败，既然能连接 derp 服务器，那就能控制另一端，搞个脚本，让另一台设备主动请求 OpenWrt （ upnp/nat-pmp)开放一个临时端口。然后 tailscale 是否支持这样搞？

[worker201]

你的头像很吊

[Tink]

可以考虑把 ts 所在设备的 41641/udp 映射出去试一下

[ixixi]

用一下蒲公英试试 可以提单子问问他们技术支持

[litpel]

你的头像很吊 和我衣服的 logo 很像

[FaiChou]

@Tink 一个局域网下有很多设备。

[seenthewind]

没用过 tailscale ，对打洞只有一点浅薄的理解。

理论上稳定的网络打洞不可行，因为临时的打洞实际上是由于各层网络设备的“后门策略”使得可以出现打洞的现象。

至于网络设备有多少后门策略，哪些可用，就要看各种实际情况了（有兴趣可以看看 root 后的小米路由器配的 iptables ），比如，万一后门的正主正在用咋办？



开放临时端口的办法可能可以，但是还是太麻烦了。

我目前的方法就非常简单，首先是普通的主流网络设备做前端拨号，获得公网 ip 后，后端配置 wireguard ，在拨号的网络设备里，映射一个非常高的 udp 端口（用高段位来尽量减少 sb 扫描，用 udp 来进一步规避 sb 中的 sb ）。

由于 wireguard 是 udp ，无论是处理性能还是对抗扫描等都还可以，另外做一个靠谱长度的 key ，可以保证在量子计算前不被攻破。

其他就没了，别整那些花里胡哨的，用得越多你留的面包屑就越多，框架的漏洞就越多。

[huangsen365]

如果都支持公网 ipv6 将会很容易打洞成功，或者在国内挑个当地云服务器自建 derp

[totoro625]

Port-Restricted Cone NAT 是 NAT3
以下方式任选或组合使用：
1. 路由器拨号
2. 打电话要公网 IP
3. 尝试走 IPV6
4. 闲鱼买一个路由器管理员账户，把 tailscale 所在机器的 IP 设置为 DMZ

[lhsakudsgdsik]

是的，今年打洞成功率挺低的，就算 ipv6 打洞通了，ping 测试也会每五六个包延迟就高到一百多，还不如完全走搭建的中转服务器

[Tink]

@FaiChou #5 你所有设备都装了 ts ？一个局域网装一台就可以了啊

[FaiChou]

@Tink #10 设备很多，两端的网段都一样，都是 192.168.3.x ，不想改了，所以没办法用 subnet 那功能。

[lnbiuc]

不支持
怀疑是联通对 udp 包的限制

[Tink]

@FaiChou #11 建议改了，长痛不如短痛，最有用的功能浪费了

[HandSonic]

我这同一个城市，同一个运营商中国电信，Tailscale IPv6 直通，丢包率都能到 20%，运营商限制 UDP 还是限制的太狠了，我用 OpenVPN 走 TCP 隧道就不丢包

[kekylin]

我联通公网 IPv6 ，基本上和三大运营商连接都是直连，平时不怎么关注连接质量，刚刚测试了一下，还可以。
100.10.0.1 的 Ping 统计信息:
数据包: 已发送 = 100 ，已接收 = 100 ，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 12ms ，最长 = 87ms ，平均 = 18ms

[sunfly]

@worker201 活捉佬友

[gogogo2000]

tailscale 会自动创建 upnp 端口映射的，所以
> 我的想法是，打洞失败，既然能连接 derp 服务器，那就能控制另一端，搞个脚本，让另一台设备主动请求 OpenWrt （ upnp/nat-pmp)开放一个临时端口。然后 tailscale 是否支持这样搞？
人家本来是这样的。

> tailscale 是暴力遍历端口（它们官网有教程），实践下来还是能够打洞成功的。
tailscale 是生日算法，并不是暴力遍历 https://tailscale.com/blog/how-nat-traversal-works
"But we can get rid of STUN, the birthday paradox trick, port mapping protocols, and all the hairpinning bumf. That’s much nicer!"

[gogogo2000]

Here’s a parting “TL;DR” recap: For robust NAT traversal, you need the following ingredients:

A UDP-based protocol to augment

Direct access to a socket in your program

A communication side channel with your peers

A couple of STUN servers

A network of fallback relays (optional, but highly recommended)

Then, you need to:

Enumerate all the ip:ports for your socket on your directly connected interfaces

Query STUN servers to discover WAN ip:ports and the “difficulty” of your NAT, if any

Try using the port mapping protocols to find more WAN ip:ports

Check for NAT64 and discover a WAN ip:port through that as well, if applicable

Exchange all those ip:ports with your peer through your side channel, along with some cryptographic keys to secure everything.

Begin communicating with your peer through fallback relays (optional, for quick connection establishment)

Probe all of your peer’s ip:ports for connectivity and if necessary/desired, also execute birthday attacks to get through harder NATs

As you discover connectivity paths that are better than the one you’re currently using, transparently upgrade away from the previous paths.

If the active path stops working, downgrade as needed to maintain connectivity.

Make sure everything is encrypted and authenticated end-to-end.

[guanzhangzhang]

主路由开 upnp 试试，自建 derp 试试

[lovelylain]

你到底是有公网 ip 不想常开端口，还是没有公网 ip