1 xqzr 2023-11-28 18:11:48 +08:00 |
![]() | 2 heiher 2023-11-28 18:22:50 +08:00 via Android 难道不是 xtcp 的 fallback 机制退回到 stcp(服务器中转)模式嘛 |
![]() | 3 YV4usGtvaOIAeXIa OP @heiher 满速了,而且我没开 stcp ,我拖文件跑满带宽了,frp 服务器只有 5m 小水管 |
![]() | 4 YV4usGtvaOIAeXIa OP @xqzr 可以用命令指定 stun 服务器? |
![]() | 5 YV4usGtvaOIAeXIa OP @heiher ps:是跑满了本地带宽 |
![]() | 6 lazywen 2023-11-28 21:25:25 +08:00 xtcp 看起来是 tcp ,实际上是它代理了 tcp ,而传输使用的 kcp ,即 udp ,而 udp 打洞在大部分 nat4 下还是有很大几率成功的,参照普通家庭宽带使用 bt 下载 |
7 xqzr 2023-11-28 21:27:11 +08:00 |
8 xqzr 2023-11-28 21:28:45 +08:00 |
![]() | 9 YV4usGtvaOIAeXIa OP @lazywen 原来如此 |
10 amyw495062 2023-11-29 00:40:23 +08:00 @lazywen 所以也是看运气,并不是所有 nat4 都能打洞? |
![]() | 11 skies457 2023-11-29 09:01:30 +08:00 Tailscale 有篇关于 NAT traversal 的科普: https://tailscale.com/blog/how-nat-traversal-works/ |
12 maybeonly 2023-11-29 09:38:42 +08:00 nat4 和 nat4 也是不一样的 linux 内核实现的 nat 的话,默认情况下会尽量保持 nat 后的源端口和之前的源端口一致 这样的话,就有很多文章可以做,甚至 tcp 都有机会连得上 就算端口有变化,只要端口是可预测的,都可能被成功打洞 |
13 8E9aYW8oj31rnbOK 2023-11-29 11:52:34 +08:00 frp 的 xtcp 只是对端口打洞吗,楼主可以分享一下两端的配置文件怎么写的吗 |
![]() | 14 lazywen 2023-11-29 12:35:47 +08:00 via Android @amyw495062 一般宽带 nat4 udp 打洞成功的概率还是远高于不成功的概率,不成功的情况很复杂,也说不清,可能由于复杂的网络拓扑、防火墙,或者其他什么阻碍限制 |
15 amyw495062 2023-11-29 13:26:15 +08:00 @lazywen 原来,我也一直以为双侧 nat4 不存在打洞的可能性 |
16 YGBlvcAK 2023-11-29 18:17:48 +08:00 via Android 如果设备发送数据包的源端口和路由器 NAT 后的源端口一致,打洞成功率就很高,双方互发就可以了(stun 服务器告知双方端口) |
![]() | 17 flynaj 2023-11-30 01:46:45 +08:00 via Android 光猫桥接电脑拨号后用 https://github.com/HMBSbige/NatTypeTester/releases/ 测试,你的网络不是 nat4. |
![]() | 18 xcsoft 331 天前 wk 我也不清楚为什么, 可能和 6 楼所说的有一定关系,走 UDP 可以打洞成功, 但是在我的网络环境下 Tailscale 始终打通不了,只能走中转。 但是 Tailscale 使用 wailgurad 协议,应该也是基于 UDP 的吧,所以有点奇怪 |
19 1265578519 289 天前 那肯定有一方是 nat3 ,而不是 4 |