search

heiher / natmap

TCP/UDP port mapping for full cone NAT
MIT License
1.38k stars 103 forks source link

成功获取端口，但是连接Timeout #32

Closed dsus4wang closed 1 year ago

dsus4wang commented 1 year ago

Hi， 我目前的环境是江苏移动大内网，Nat类型是Full Cone 目前是路由器(192.168.10.1)拨号上网，开启dmz到我的一个小服务器上（192.168.10.129） 当我运行 root@dsus4serv:/home/dsus4# ./natmap -s stunserver.stunprotocol.org -h qq.com -b 22 -t localhost -p 22 183.xx.xx.11 16835 2001::xxx:xxx:070b 22 tcp 用远端电脑连接时，提示timeout 服务器端无任何报错 机器防火墙已完全关闭 请问有什么可以排查的办法吗，谢谢 Wang

dsus4wang commented 1 year ago

另外 当我试图映射路由器管理页面到公网，也碰到了同样的问题 ./natmap -i ens33 -s stunserver.stunprotocol.org -h qq.com -b 8021 -t 192.168.10.1 -p 80 Chrome提示，无法建立连接（timeout）

ysc3839 commented 1 year ago

测过NAT等级了吗？换UDP呢？

dsus4wang commented 1 year ago

测过的 是fullcone udp没有 我来测试一下

heiher commented 1 year ago

如果路由器不能抓包，最简单的用电脑拨号抓包看看。

另外，绑定端口和转发目标一致的用法不对，可以直接用绑定模式：

./natmap -s stunserver.stunprotocol.org -h qq.com -b 22
dsus4wang commented 1 year ago

@heiher nmap跑了下我这边的ip image 很多port都是filtered的，剩下的是close的，这个正常吗？ 谢谢 Wang

dsus4wang commented 1 year ago

@heiher Hi, 刚又用natter试了下，显示udp是fullcone，tcp是symmertic，您之前又碰到这种情况吗 感觉蛮奇怪的

heiher commented 1 year ago

电脑拨号，排除中间环节导致问题的可能性，如果仍是TCP为对称型，那就说明是当地运营商级NAT的行为，也属正常现象。

ysc3839 commented 1 year ago

@dsus4wang 正常，filtered是没回应，closed是有明确回应端口关闭。