QUOTE(ericeric91 @ Oct 4 2022, 21:09)
關於 NAT-1 打洞的東西，一些技術面觀點
掛 H@H 我是覺得有點不切實際
我相信 ISP 方面很快就會發現有異常 input ，同時維持時間異常久的 session 應該會被幹掉
透過 STUN 定位的連線又很好抓， STUN 是協定，且屬於公有基礎建設(印象中)，都是很好鎖定的東西
另外就是通常 ISP 管理上，會有 IP Range 做客群區分，一般家用戶八成也會有 group 方便管理
且 H@H 計分還有特性上，必須做好各種指定，但是 NAT-1 打洞拿到的 wan 端 port 是隨機的，等於是每次重新打洞都要做
1.modem or AP port forward setting
2.H@H host FW setting
3.H@H port setting
累積流量不小會有危險，然後斷線懲罰又重，又很麻煩
其实我在想，NAT1 打洞跑 H@H 最大的问题在于重新拨号更换IP+端口后 H@H 无法工作受到惩罚的问题
但我猜想应该可以用自动化脚本解决，至少在 Linux 上是可以实现的。
当然因为我宽带有公网 IP，所以也没有去尝试过，但理论上是可行的
脚本执行的大致步骤如下，具体步骤大概率还需要修改：
0、（准备工作）把EH网站保存登录信息的 cookies 保存到本地文件
1、curl 一次能返回公网 IP 的网站，比如 ip.sb，获取到当前在用的 IP，然后记录到环境变量里
2、H@H 在线时每隔1分钟 curl 一次上面的网站，把获取到的 IP 跟环境变量中的 IP 比对，如果相同就继续运行等待下次探测
3、如果获取到的 IP 与环境变量中的 IP 不符，那就执行下面的步骤：
（1）把 H@H 的进程 kill -15，使其正常关闭
（2）重新执行一次公网打洞程序 natter.py 重新获取新端口
（3）通过 curl 测试新打洞出来的公网 IP+端口 的连通性，不通就重新再打一次，通的话继续执行下面的步骤
（4）把返回的端口写入环境变量
（5）调用 EH 网站的 cookies 进行 curl，把环境变量的新端口写入请求体中，发送一个 POST 请求到 EH 更新端口
（6）启动 H@H，检测是否启动成功并且有流量输入
4、如果 H@H 启动正常，那就重新从步骤1开始执行，启动不正常这里还需要考虑下怎么操作，因为 H@H 一天内断线次数不能到2次，可能要考虑在步骤（5）这里就确定配置无误才行
如果哪一天我的公网 IP 被回收了，估计我也需要去写一个脚本去做这种事情了
至于 ISP 监管，这种流量特征太明显，况且端口还有绑定 Hath.network 的通配符证书，要是政府想我们死的话不管是公网IP还是内网IP+NAT1打洞都得死，所以也无解
This post has been edited by VVFGV: Oct 6 2022, 07:47
中文討論區: 變態道的原罪 [禁無意義的水跟簽到], The Chinese discussion thread of declining quality.
Oct 5 2022, 13:48
