实在搞不懂了，谁来科普下， Frp xtcp 双侧 Nat4 为什么能成功打洞

[Jestom]

/t/995564
原本打算用现成的远程桌面软件的，但是帖子下一位老哥的分享，开了 Frp xtcp 来尝试打洞，双侧 Nat4 居然能通，这是为啥
我原本尝试了 zerotier 、wireguard 之类的，都打洞失败，甚至向日葵和 todesk 之类的远程软件，都没办法实现 p2p 连接
没想到近在我眼前的 Frp 是可以的，我还想着 zerotier 都打不成功的话 Frp 也就当个中转了。。。

所以 Frp xtcp 是要靠运气还是原理上就能成功打通的。
目前尝试了移动 NAT4-联通 NAT4 成功

我甚至尝试把 dmz 和 upnp 都关了，依旧可行
ipv6 本来就只有单侧有，我也试过把另一侧的 ipv6 关了，依旧可行
虽然挺惊喜的，但是还是想学习一下这是什么原理

[xqzr]

```sh
frpc nathole discover --nat_hole_stun_server stun.easyvoip.com:3478
```

[heiher]

难道不是 xtcp 的 fallback 机制退回到 stcp(服务器中转)模式嘛

[Jestom]

@heiher 满速了，而且我没开 stcp ，我拖文件跑满带宽了，frp 服务器只有 5m 小水管

[Jestom]

@xqzr 可以用命令指定 stun 服务器？

[Jestom]

@heiher ps：是跑满了本地带宽

[lazywen]

xtcp 看起来是 tcp ，实际上是它代理了 tcp ，而传输使用的 kcp ，即 udp ，而 udp 打洞在大部分 nat4 下还是有很大几率成功的，参照普通家庭宽带使用 bt 下载

[xqzr]

@lazywen 默认 QUIC
https://gofrp.org/zh-cn/docs/reference/visitor/#xtcpvisitorconfig

[xqzr]

@Jestom 通常不需要指定
这是 https://github.com/fatedier/frp/issues/3812 的临时解决办法

[Jestom]

@lazywen 原来如此

[amyw495062]

@lazywen 所以也是看运气，并不是所有 nat4 都能打洞？

[skies457]

Tailscale 有篇关于 NAT traversal 的科普： https://tailscale.com/blog/how-nat-traversal-works/

[maybeonly]

nat4 和 nat4 也是不一样的
linux 内核实现的 nat 的话，默认情况下会尽量保持 nat 后的源端口和之前的源端口一致
这样的话，就有很多文章可以做，甚至 tcp 都有机会连得上

就算端口有变化，只要端口是可预测的，都可能被成功打洞

[8E9aYW8oj31rnbOK]

frp 的 xtcp 只是对端口打洞吗，楼主可以分享一下两端的配置文件怎么写的吗

[lazywen]

@amyw495062 一般宽带 nat4 udp 打洞成功的概率还是远高于不成功的概率，不成功的情况很复杂，也说不清，可能由于复杂的网络拓扑、防火墙，或者其他什么阻碍限制

[amyw495062]

@lazywen 原来，我也一直以为双侧 nat4 不存在打洞的可能性

[YGBlvcAK]

如果设备发送数据包的源端口和路由器 NAT 后的源端口一致，打洞成功率就很高，双方互发就可以了(stun 服务器告知双方端口)

[flynaj]

光猫桥接电脑拨号后用 https://github.com/HMBSbige/NatTypeTester/releases/ 测试，你的网络不是 nat4.