@嚻，哦对了，我的 svn 服务好像是 https 提供的，形如 https://10.2.15.3:4333/code ，是不是应该配置 http 或者是 tcp 相关的？
小米MIX2s(白)

@20263，所以2 楼的配置可以用吗？
我应该配置 tcp 而不是 svn 吧
小米MIX2s(白)

@老虎会游泳，我记得以前你有个回复，两个内网设备，可以通过一个公网设备进行打洞，即使后续不再需要公网设备，俩内网设备也能互通？
是我记错了吗？怎么做到的？

@无名啊，UDP是无连接的协议，网关采取以下放行规则：如果内网机器的端口A给服务器的端口B发送过数据，就允许服务器的端口B给内网机器的端口A发送数据。

所以，如果你给对方发送数据的时候对方也给你发送数据，并且端口互相匹配（你发送的目的端口是对方发送的源端口，反之亦然），就恰好可以穿越双方的网关，顺利到达接收者处。此时在你的网关看来，对方发来的数据包是服务器对你的响应。在对方的网关看来，你发去的数据包是服务器对他的响应。在首个数据包交换完成后，你和对方间的双向UDP通道就已经打开，你们就可以自由的发送更多数据了，而且这些数据完全不会经过第三方服务器。这就是UDP内网穿透的原理。

而UDP内网穿透之所以要一个协商服务器，就是为了让双方发现对方的IP和源端口。在得到对方的IP和源端口之后，只要双方同时开始发送，就可以顺利建立UDP隧道。

目前已经有规范的步骤来实现隧道建立，比如STUN协议：

https://baike.baidu.com/item/stun/3131387

@无名啊，UDP隧道建立最难的步骤是预测对方的源端口。为什么要“预测”，不是可以通过中间服务器直接观测吗，或者让对方机器通过中间服务器直接告诉你不行吗？不一定行，因为公网IP是由很多内网机器共享的，有时候它们会用相同的源端口发起通信，此时网关在把内网数据包转换为公网数据包的时候，就必须为每个机器选择不同的端口。如果网关在主机和不同的服务器通信时使用不同的端口，那源端口就不可观测了，必须“预测”。如果预测不准，对方网关转换后的端口和你猜的不同，对方网关就会拒收数据包。

现实中的应用程序会有一系列的解决方法，包括：

1. 有的网关，端口转换有规则，就直接用这个规则预测。
2. 有的网关，虽然没有规则，但是端口分布在特定范围内，那就广撒网，发一系列数据包覆盖每个端口，总有一个能到达。哪个能到达就用哪个。

@20263，刚刚测试了一下是可以了，但是服务器 C 仍然没有成功，不知道为什么。

已知服务器 C 开启了 http 的 Basic Authentication，

然后是 https 协议，是不是还需要配置 http 认证
小米MIX2s(白)

最后，互发数据包并且互能收到，还利用了网络延迟导致的“同时性的相对性”。

虽然你们可能同时发送数据，但是因为你的网关离你更近，离对方更远，所以在你的网关看来，你先发送数据，对方后发送数据。在对方网关看来，对方先发送数据，你后发送数据。

虽然双方同时发送，但是因为数据包到达各自网关的时间不同，在双方网关看来，都是内网先发送请求，服务器（对方）后发送响应。

于是双方都成了对方的服务器，顺利实现了点对点（P2P）连接。

UDP隧道是视频会议软件、远程控制软件、共斗游戏（有联机功能的单机游戏）等应用的网络基础。这些应用通常都不会建设数据中转服务器，只建设了UDP隧道协商服务器，帮助通信各方建立隧道。

当然了，某些应用确实会在隧道创建失败的时候使用服务器中转。有些网络确实无法顺利创建UDP隧道，比如经过了多次随机NAT，导致端口不可预测，或者是网络封锁UDP或者干脆不支持UDP（比如通过仅限TCP的代理服务器连接等）。

@20263，我直接说场景吧：

b 和 c 是在同一局域网的。b 是我的 windows 电脑，c 是一个台式机，在做服务器。

他们俩都在公司，可以接同一个局域网。

放假了，我可能在家，用电脑 A 想通过 B 为跳板，转发请求来达到 A-C的通信。
小米MIX2s(白)

@水木易安，我说一下我自己用的方案吧：

我用slake的nebula创建了p2p vpn。
https://github.com/slackhq/nebula

• hu60.cn是我的udp隧道协商服务器（lighthouse服务器）。
• 在小米路由器上运行nebula arm版，创建了覆盖网络10.98.76.*/24，并在它上面设置unsafe_route，路由至真正的局域网网段192.168.31.*/24。
• 外部设备只需要加入这个nebula覆盖网络，就可以经由小米路由器访问到192.168.31.*中的局域网设备。
• 在10.98.76.*和192.168.31.*网段间进行转发时，小米路由器负责进行NAT。非Server的Windows系统不能担此重任，需要WSL2。
• 不过，客户端可以是Windows的。nebula支持Tap-Windows驱动，可以在Windows里连上覆盖网络。
• 外部设备和小米路由器通信时，数据不会经过hu60.cn中转，而是直接P2P传输。hu60.cn只负责为UDP通道的建立提供辅助信息。

教程：

• 快速开始：https://www.defined.net/nebula/quick-start/
• 共享局域网设备：https://www.defined.net/nebula/unsafe_routes/

我的配置文件：

https://hu60.cn/q.php/bbs.topic.102844.html

@水木易安，类似的产品还有Zerotier，它提供官方udp隧道协商服务器，不像nebula一样得自己搭建。

@水木易安，这个图和你的架构很像啊：

• 快速开始：https://www.defined.net/nebula/quick-start/
• 共享局域网设备：https://www.defined.net/nebula/unsafe_routes/

果然，Windows不能担此重任。但可以使用WSL2或者Linux虚拟机。在虚拟机内运行nebula应该不会影响UDP隧道创建。

@老虎会游泳，UDP打洞应该不需要端口预测吧，我感觉流程只要这样就行了： 需要打洞的时候需要A和B同时向服务器发起连接。

A连接服务器，服务器得到A的ip和端口(端口为网关随机生成)，B同时连接服务器，服务器得到B的ip和端口，然后服务器把A的ip端口发送给B，把B的ip端口发送给A。

此时因为A向服务器发送过消息，网关已经为它随机分配了一个ip和端口，下次A向其它公网服务发送数据包时网关会接着用刚刚分配的ip和端口进行通信，B同理。

等到A收到服务器告诉自己B的ip和端口时，B也获得了A的ip和端口，此时A和B向对方大量的发包就建立起通信。

应该是这样吧，流程
红米K30 Pro(变焦版)

额，好像不对，向其它服务发送数据包时端口要变，不然数据回来时网关不知道把目标端口设置成什么。。
红米K30 Pro(变焦版)

刚刚又去复习了一下NAT，发现老虎说的是Symmetrict NAT，我说的在Full Cone NAT，Restricted Cone NAT和Port Restricted Cone NAT的情况下可以建立起通信。我记对了，但是没有完全记对，记混了
红米K30 Pro(变焦版)