Debugger Chen

引入了一个[igd-next](https://docs.rs/igd-next/latest/igd_next/)依赖用于处理upnp。其仓库位于[rust-igd](https://github.com/dariusc93/rust-igd)。目前其官方最新版本尚不支持ipv6环境，因而此处使用了我修改后的支持ipv6的branch。目前已经向igd-next提交了PR，合并后可以换到官方源。

cli和core两边都要从bind_request做stun测试。cli加上upnp能确保得到core一样的探测结果，或许这样更好一些不容易出现误解？现在只加了一个60s的upnp端口映射，大概影响不大？

> 另外这个 upnp 库是同步库吧，在 tokio 里用会阻塞线程吧 Done > 我感觉 upnp 应该映射 -l 的那个监听器吧，这样还可以复用 mapped-listener 功能 现在为了实现快一点，正好着急用。确实用mapped-listener更好一些

> 我感觉 upnp 应该映射 -l 的那个监听器吧，这样还可以复用 mapped-listener 功能 我感觉用mapped listener的问题在于，如果ISP不是NAT1而是NAT2/NAT3，那么不光要对listener做端口映射，还要用listener socket/port向对方发包，感觉就有点奇怪了 另外，如果是开了mapped-listener，对于ISP NAT1场景来说，路由器后的用户就直接暴露在公网下，可能安全性上有些微影响。如果只是打洞的短暂时间内使用端口转发可能更安全一些

换到异步upnp实现

> > 另外这个 upnp 库是同步库吧，在 tokio 里用会阻塞线程吧 > > Done > > > 我感觉 upnp 应该映射 -l 的那个监听器吧，这样还可以复用 mapped-listener 功能 > > 现在为了实现快一点，正好着急用。确实用mapped-listener更好一些 如果WAN直接是公网IP这样应该蛮好。如果WAN还走NAT，那还是有打洞需要，还要维持NAT Mapping状态，放在listener可能需要蛮大改动。我感觉可以考虑如果检测是公网IP就复用Mapped Listener来，如果是NAT就还是在打洞时处理。说的不对请赐教🙂

> 这里我没有很理解，假设网络拓扑是 A（EasyTier） -> B (Router) --- NAT1 --> C，A 在 B 上建立 upnp 映射，那么打洞实际是由 B 完成的吧。 NAT1的话这样可以，但是也需要复用Listener的端口/socket定时发送一些包保活NAT。我不确定现在是否已经有类似机制 另外UPnP应该也能解决WAN是NAT2/3的问题，但打洞时也要复用Listener的端口/socket去发送。 可能会涉及对现在stun/udplistener的修改？

> UDP 端口是多路复用的，假设还是刚才的例子，C 在连接到 A 后，更上层会发心跳包保活的。保活包 src port 就是 10010，dst 是 C 的地址。 如果是中途一段时间内暂时没有udp peer，是否会有问题呢？ > NAT2/3 的话 UPnP 应该是无能为力的吧，UPnP 应该是只映射了入站，不会映射出站的。也就是说 A 节点发出的打洞包，不一定会走 B 上的对应端口。 确实UPnP主要入站。不过我这边的路由器上，看起来在SNAT时会更倾向尽量local port == external port，这样upnp内部端口跟外部端口设为一样的话，还是能测出来endpointindependent

> 现在 udp listener 有个 v6 hole punch 的特殊功能，作用是主动从这个 listener 发送一个 v6 数据包到指定的外部地址。这个功能如果扩展到 v4，是否可以解决你提到的两个问题呢 我看一下，谢大佬指路🌹

最近有点忙手头也没合适的设备和网络环境，有点耽搁 个人还是感觉就目前的架构来看，放在打洞时upnp可能更优雅一点，不需要添加过多的复杂功能和耦合，能解决的情形也多一点