@mrzx
详细地说，原理是这样的。

假设本机获得了运营商分配的局域网 IP (100.64.32.10)：
当本地 100.64.32.10 向 www.qq.com (109.244.211.100) 发起 HTTP 请求时，NAT 会做转换。

1. 本地发起请求，来源端口为 100.64.32.10:3456 ，想建立 (100.64.32.10:3456 至 109.244.211.100:80) 的连接。
2. ISP NAT Server 察觉到本地想要请求，在公网 IP 空闲端口中挑一个，在映射表中新增 (100.64.32.10:3456 ~ 203.0.113.10:14500) 映射关系。
3. 100.64.32.10:3456 转发 203.0.113.10:14500 至 109.244.211.100:80 ，本机和 www.qq.com 成功建立连接。
4. 本机断开与 www.qq.com 的连接，NAT Server 释放端口，清除 (100.64.32.10:3456 ~ 203.0.113.10:14500) 映射关系

因此，在第 4 步之前，第 3 步的时候 (100.64.32.10:3456 ~ 203.0.113.10:14500) 已经成立了映射关系，NAT1 下，两者是等同关系。此时，端口被“临时地”暴露至公网。
当该端口还提供服务时，相当于开了一个“洞”，外部的连接就能“趁虚而入”。
一旦到达第 4 步，NAT Server 回收 14500 端口，就无法继续“趁虚而入”了。

然而，这是上帝视角看整个连接的过程。实际操作中，我们不知道出口的 IP 和端口号，www.qq.com 也不会告诉我。
因此，我们需要问一个路人：“打扰一下，您看看我外面 IP 和端口号是多少”。这个路人就是 STUN 服务器。
STUN 服务器没那么多闲工夫，告诉你 IP 端口之后就立即关闭连接了。而 www.qq.com 比较客气，只要你提出我想要保持连接不关闭，它就不会关闭，外部端口也就不会被回收。
Natter 会每 10 秒说一次：“求求你别关连接”。

如果没有 STUN 服务器，但您知道自己的出口 IP ，就可以做全端口扫描，不过这就很费事了。

原理图：
https://raw.githubusercontent.com/MikeWang000000/Natter/master/.img/img03.png

@matzoh tailscale/zerotier 打洞时一般都是 UDP ，Natter 使用 TCP 。

另外，Natter 的“打洞”其实只做了一半：只有服务端打洞，向外暴露端口；客户端则是没有感知的，不借助任何软件，手输外部 IP:端口号即可访问。

江苏移动 App 的流量大富翁每个月白送 6 GB ，再加上签到之类的活动一个月 0 元攒到 20 GB 都有可能。
我这 8 元卡这么做很久了 hhh

@shikkoku 这两个已经内置在 Natter 里了，作为 UDP 的探测。可惜两个都不支持 TCP 模式。

@1423 有意为之的，这样才能打洞。原理十分简单，重点在于维持 TCP 连接的思路，以及外部地址的获取（ Natter 相当于把 STUN 协议的客户端重新实现了一次）

@jasonliu769 我不在用 Windows ，不过印象中 netsh 的端口转发会独占端口。

@Zy143L 对的，因为 TCP STUN 公共服务器都是境外的，我没有找到国内可用的服务器 : (
而且如果运营商对某些境外地址，改变了出口 IP ，那么也会影响判断结果 emmm
可能暂时不太好解决

@Caan07 目前还没有，不过操作应该很简单：
1. 上传 natter.py 脚本
2. opkg install python3-light
3. python natter.py -t 3456

如果没有 python3 ，使用 python-light 也是兼容的。

@wym0823 频繁打洞会出现这种情况。换个端口号试试。各个操作系统对于端口释放时间的限制不太一样。

#49 @tediorelee 对的，看到这个就是成功，恭喜你。

#51 @star7th 这个穿透是服务器中转的么？ Natter 注重于直连打洞，无限制访问

#52 @shikkoku 哈哈 有点尴尬，这个转发事情应该是由 Natter 做的，我画了个饼，还没写，等我更新吧。

@shikkoku 实际上，NAT 1 对于 BT 应该已经足够了，毕竟用的 UDP ，不需要对 TCP 打洞。

@Zy143L UDP 网络环境不稳定的时候可能会影响类型判断，不过仅作参考，不影响 Natter 运行。

@mikeluckybiy 可以简单理解为一个时间段内，锥形的端口映射关系是固定的，因此有打洞的可能性。而对称型的映射关系不固定，因此只能做“被动”的一方，不能对外提供服务。

@shikkoku 理论上，打洞端口 A ，得到了公网端口 B 。可以设置 BT 软件端口号也设为 B ，然后端口 A 数据转发至 B ，从而得到一致端口。

#29 @xixiv5 一般情况下运营商是不会随意断开 TCP 的，否则这个网就几乎没法用了。
Natter 对 TCP 的保活做得算是比较激进的，默认间隔 10 秒就向外发一次数据。

@qingmuhy0 任意一个能保持很长很长 TCP 连接的地址都行。目前 Natter 是向 www.qq.com:80 发起 HTTP Keep-Alive

@1041412569 Windows 下可能比较尴尬，后续考虑直接在 Natter 上集成转发功能。

@wym0823 Windows 下直接安装 Python 3 就行
@shikkoku 设置 DMZ ，用局域网机打洞亦可
@Peven 显示成功就代表有戏，有可能我测试服务写的有 bug…比较仓促，欢迎提 issue

#15 @gyorou 是的 :doge: 我猜是没有这个必要
运营商那边只要搞好 NAT 转换就 OK 了，加一道防火墙反而有可能引入新的问题。
有防火墙一般检测也是 NAT 2/NAT 3 ，而不是 NAT 1 。

@swiftg
使用 -v 选项再再试一次？然后将日志告诉我（可以提 issue ）

@Zy143L 简单的说：可能会出现端口号冲突问题（如果您的系统不报错，那就一切 OK ）

因为端口监听默认是“独占”模式。程序没有设置 SO_REUSEADDR 、SO_REUSEPORT 的时候，这个端口只能被先监听占用的程序使用，因此就无法在上面继续打洞了。（会出现经典的 [Errno 48] Address already in use ）

因此一般情况下，是 Natter 打洞+防火墙的转发规则，将打洞端口转发到局域网的 NAS 服务器上（或者本机的其他端口）。

防火墙转发规则不会导致端口号冲突，因此先设好转发再在此端口打洞，这种“监听”是 OK 的。