Kinnikuman 最近的时间轴更新
Kinnikuman

Kinnikuman

V2EX 第 645335 号会员,加入于 2023-08-25 09:41:39 +08:00
今日活跃度排名 29652
Kinnikuman 最近回复了
21 天前
回复了 Kinnikuman 创建的主题 程序员 关于 tailscale NAT 打洞问题的理解
@Chalice 只是证明一下是防火墙 NAT 的规则导致它不能完全表现为 Endpoint-Independent Filtering ,是一个假的 Fullcone NAT ,经过测试,我的 NAT 是 Port-Restricted Cone NAT 。

电脑上连接着服务器 A, 然后服务器 A 再用不同端口访问电脑的 PublicIP:Port 也是被 denied. 所以是 Port-Restricted Cone NAT 。
21 天前
回复了 Kinnikuman 创建的主题 程序员 关于 tailscale NAT 打洞问题的理解
@Kinnikuman 补充一下这个测试。

~ ./socket_program 8081 45.xx.xx.13 8081
Server listening on port 8081
Received from server B: Your IP: 123.xx.xx.138, Your Port: 61288

Received connection from 45.xx.xx.13:51662
Received connection from 103.xx.xx.120:39458


只有当我在 OpenWrt 防火墙指定端口转发才可以正常收到任意 ip 发到 61288 端口的请求

uci add firewall redirect # =cfg133837
uci set firewall.@redirect[-1].dest='lan'
uci set firewall.@redirect[-1].target='DNAT'
uci set firewall.@redirect[-1].name='test'
uci set firewall.@redirect[-1].src='wan'
uci set firewall.@redirect[-1].src_dport='61288'
uci set firewall.@redirect[-1].dest_ip='192.168.11.112'
uci set firewall.@redirect[-1].dest_port='8081'
21 天前
回复了 Kinnikuman 创建的主题 程序员 关于 tailscale NAT 打洞问题的理解
@swananan 我做了一下试验,我的电脑处于 Fullcone NAT 后面 (STUN client version 0.97 Primary: Independent Mapping, Independent Filter, preserves ports, no hairpin),运行了下面代码中的脚本,然后用两个服务器做测试,服务器 A 监听 8081 端口,然后电脑执行这个这个程序向服务器 A 发送一条请求,拿到了电脑的 IP 和端口: Received from: Your IP: 123.xx.xx.138, Your Port: 57851 ,然后用服务器 C 向电脑的公共 ip 123.xx.xx.138:57851 尝试连接,但是 connection refused 了。这也许能证明,我的 stun 检测的结果 (Independent Mapping, Independent Filter)是错误的。


试验代码:

https://gist.github.com/FaiChou/7291580826d83d9340f9fe6c8cd8a79b



我的问题应该没有了。
21 天前
回复了 Kinnikuman 创建的主题 程序员 关于 tailscale NAT 打洞问题的理解
@swananan 我做了个图比较形象,感觉你说的例子有一点问题。我一会写一个 example 来测试下。

22 天前
回复了 Kinnikuman 创建的主题 程序员 关于 tailscale NAT 打洞问题的理解
@swananan 我在附言中 append 了一条我的疑惑,原来写的可能表达不是很清楚。请再帮看下。
不知道为啥不能 edit 了,那就用回复做一下 append 吧。

当你体验过 AI commit message 后,真就回不去了。它能准确给你做一下统计,比自己写的 commit message 清楚多了。
90 天前
回复了 Kinnikuman 创建的主题 程序员 follow 签到为什么这么慢?
@cowcomic 应该是实时的,签到时候合约会给地址打过去 20Power ,使用 100Power 生成邀请码会给 `0xf496**D355` 这个合约地址转账。D355 这个地址也在不停的 mint, 可以用自己的地址看下:

@iOCZS "CPU 闲着也是闲着",不这么认为,能让 cpu 少工作,也算是性能优化的一部分吧。当然这个话题中是舍弃掉内存来换取 cpu 的部分工作。而且这个讨论不考虑分页获取数据,就是一个几万几十万条的数据一次性加载到 list 中。
@LuckyLauncher

@RightHand

绘制是另一个问题了,有专门的硬件处理。

所以,我的问题有问题是吗?相对于绘制来讲,那些 cpu 计算复杂的列表如何更换数据,都是很 easy 的计算?
@MrDream @PTLin @expy @kuanat 大佬们请看我的附言,有了比较详细的描述,帮我指正下。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1035 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 19ms · UTC 19:46 · PVG 03:46 · LAX 11:46 · JFK 14:46
Developed with CodeLauncher
♥ Do have faith in what you're doing.