search

heiher / natmap

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

natmap v20240813 每次pppoe重拨后都不能正常打洞 #85

Open niclau opened 1 week ago

niclau commented 1 week ago

设备：R5C ImmortalWrt 23.05.0-rc1 r26503-a5699b283d 安装：opkg install natmap luci-app-natmap luci-i18n-natmap-zh-cn

# opkg list-installed|grep natmap
luci-app-natmap - git-24.272.29284-d386ad6
luci-i18n-natmap-zh-cn - git-24.272.29284-d386ad6
natmap - 20240813-2

现象：自从更新到v20240813后（v20240303没出现过这个问题），每次pppoe重拨，luci上的natmap外部IP、外部端口均变为无，txt记录没有更新（仍是上次的记录），natmap进程存在，手动/etc/init.d/natmap reload，就恢复正常。所以我可以怎样退回到v20240303？或者是v20240813哪里出了问题？

# ps |grep natmap
19711 root      1316 S    grep natmap
26888 root      1296 S    /usr/bin/natmap -s stun.nextcloud.com -h baidu.com -b 8022 -4 -i wanb -e /usr/lib/natmap/update.sh
26905 root      1296 S    /usr/bin/natmap -s stun.miwifi.com -h qq.com -b 8023 -4 -u -i wanb -e /usr/lib/natmap/update.sh

Snipaste_2024-11-14_09-58-45

heiher commented 1 week ago

贴下这些信息：

ip addr
ip rule
ip route

出问题时的

logread | grep natmap
niclau commented 1 week ago

ip addr是需要所有的还是只需要打洞的接口？

ip addr show dev pppoe-wanb
26958: pppoe-wanb: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet 172.16.43.228 peer 172.16.0.1/32 scope global pppoe-wanb
       valid_lft forever preferred_lft forever
    inet6 2409:8a55:209:147d:xxx/64 scope global dynamic noprefixroute 
       valid_lft 258149sec preferred_lft 171749sec
    inet6 fe80::xxx peer fe80::xxx/128 scope link 
       valid_lft forever preferred_lft forever
ip rule
0:      from all lookup local
1001:   from all fwmark 0x1 lookup 100
1002:   from all fwmark 0x1 lookup 100
1003:   from all iif pppoe-wanb lookup 3
1005:   from all iif eth0.300 lookup 5
1006:   from all iif eth0.52 lookup 6
1008:   from all iif wg0 lookup 8
2003:   from all fwmark 0x300/0x3f00 lookup 3
2005:   from all fwmark 0x500/0x3f00 lookup 5
2006:   from all fwmark 0x600/0x3f00 lookup 6
2008:   from all fwmark 0x800/0x3f00 lookup 8
2061:   from all fwmark 0x3d00/0x3f00 blackhole
2062:   from all fwmark 0x3e00/0x3f00 unreachable
3003:   from all fwmark 0x300/0x3f00 unreachable
3005:   from all fwmark 0x500/0x3f00 unreachable
3006:   from all fwmark 0x600/0x3f00 unreachable
3008:   from all fwmark 0x800/0x3f00 unreachable
32766:  from all lookup main
32767:  from all lookup default
# ip route
default via 120.x.x.x dev eth0.52 proto static metric 10 
default via 172.16.0.1 dev pppoe-wanb proto static metric 20 
default via 10.253.1.253 dev eth0.300 proto static metric 30 
default dev wg0 proto static scope link metric 50 
10.0.10.0/24 dev br-lan.10 proto kernel scope link src 10.0.10.5 
10.0.20.0/24 dev br-lan.20 proto kernel scope link src 10.0.20.5 
10.253.1.0/24 dev eth0.300 proto static scope link metric 30 
120.x.x.x/29 dev eth0.52 proto static scope link metric 10 
141.x.x.x via 10.253.1.253 dev eth0.300 proto static metric 2 
141.x.x.x via 120.x.x.x dev eth0.52 proto static metric 10 
172.16.0.1 dev pppoe-wanb proto kernel scope link src 172.16.43.228 
172.16.1.5 dev wg0 proto static scope link metric 50 
192.168.2.0/24 dev br-lan.1 proto kernel scope link src 192.168.2.5

logread | grep natmap 是空的，没结果

heiher commented 1 week ago

绑定网口名称不匹配吧，应该是 natmap ... -i pppoe-wanb

niclau commented 1 week ago

配置文件是通过luci的natmap webui生成的，webui上也是没显示pppoe-，我没人为去修改过，唯一的变化是natmap从20240303更新到20240813。另外，我上面也写了，手动执行/etc/init.d/natmap reload，ip和端口就回来了。 是否能提供一下20240303的ipk包？我退回去测试一下。

# cat /etc/config/natmap

config natmap
        option udp_mode '1'
        option stun_server 'stunserver.stunprotocol.org'
        option http_server 'example.com'
        option port '8080'

config natmap
        option udp_mode '0'
        option interface 'wanb'
        option stun_server 'stun.nextcloud.com'
        option http_server 'baidu.com'
        option port '8022'
        option notify_script '/root/bin/ip4p.sh'
        option enable '1'
        option family 'ipv4'

config natmap
        option udp_mode '1'
        option family 'ipv4'
        option interface 'wanb'
        option stun_server 'stun.miwifi.com'
        option port '8023'
        option http_server 'qq.com'
        option notify_script '/root/bin/ip4p2.sh'
        option enable '1'

Snipaste_2024-11-14_12-29-01 Snipaste_2024-11-14_12-34-26

heiher commented 1 week ago

我看源代码，应该没有与此相关的变更。我这边也是luci生成的命令，但命令行里网口名称是pppoe-wan。我看你的路由表pppoe并不是首选默认路由，如果绑定网口没生效，那么路由路径就有问题了。另外，除了natmap版本升级以外也要排查一下是不是还有透明代理等方面的变更。

heiher commented 1 week ago

还有确认一下，reload恢复正常之后，ps看到的natmap命令行参数是什么网口名称。

niclau commented 1 week ago

是的，pppoe不是首选默认路由，还有vpn等，我使用了mwan3来做策略路由。 透明代理是存在的，但没作出过变更。

我看源代码，应该没有与此相关的变更。我这边也是luci生成的命令，但命令行里网口名称是pppoe-wan。我看你的路由表pppoe并不是首选默认路由，如果绑定网口没生效，那么路由路径就有问题了。另外，除了natmap版本升级以外也要排查一下是不是还有透明代理等方面的变更。

reload后的接口是pppoe-wanb，看来问题出在接口名称不一致？是mwan3的影响？

还有确认一下，reload恢复正常之后，ps看到的natmap命令行参数是什么网口名称。

# ps |grep natmap
 5377 root      1316 S    grep natmap
20148 root      1296 S    /usr/bin/natmap -s stun.nextcloud.com -h baidu.com -b 8022 -4 -i pppoe-wanb -e /usr/lib/natmap/update.sh
20149 root      1364 S    /usr/bin/natmap -s stun.miwifi.com -h qq.com -b 8023 -4 -u -i pppoe-wanb -e /usr/lib/natmap/update.sh
heiher commented 1 week ago

有可能，但不确定是不是mwan3。把/etc/config/natmap里的网口名称转换为命令行参数是要/etc/init.d/natmap里做的，调了系统的一个函数完成的，是不是你正好在pppoe拨号开始前启用的服务，就获得非pppoe的名称？

niclau commented 1 week ago

有可能，但不确定是不是mwan3。把/etc/config/natmap里的网口名称转换为命令行参数是要/etc/init.d/natmap里做的，调了系统的一个函数完成的，是不是你正好在pppoe拨号开始前启用的服务，就获得非pppoe的名称？

我natmap服务是一直运行着的，故障的出现是当pppoe被移动踢下线后，openwrt再次发起拨号，之后natmap就打不上洞（此时命令行的接口变为wanb？）

heiher commented 1 week ago

有可能，但不确定是不是mwan3。把/etc/config/natmap里的网口名称转换为命令行参数是要/etc/init.d/natmap里做的，调了系统的一个函数完成的，是不是你正好在pppoe拨号开始前启用的服务，就获得非pppoe的名称？

我natmap服务是一直运行着的，故障的出现是当pppoe被移动踢下线后，openwrt再次发起拨号，之后natmap就打不上洞（此时命令行的接口变为wanb？）

如果服务一开始就运行着的，pppoe重拨应该不会自动重启服务，natmap的pid都保持不变，命令行参数也不应变。除非一开始就获取的是wanb。

niclau commented 1 week ago

有可能，但不确定是不是mwan3。把/etc/config/natmap里的网口名称转换为命令行参数是要/etc/init.d/natmap里做的，调了系统的一个函数完成的，是不是你正好在pppoe拨号开始前启用的服务，就获得非pppoe的名称？

我natmap服务是一直运行着的，故障的出现是当pppoe被移动踢下线后，openwrt再次发起拨号，之后natmap就打不上洞（此时命令行的接口变为wanb？）

如果服务一开始就运行着的，pppoe重拨应该不会自动重启服务，natmap的pid都保持不变，命令行参数也不应变。除非一开始就获取的是wanb。

等下次重拨时再观察下。 是否有办法避免命令行获取到wanb这个情况？

heiher commented 1 week ago

有可能，但不确定是不是mwan3。把/etc/config/natmap里的网口名称转换为命令行参数是要/etc/init.d/natmap里做的，调了系统的一个函数完成的，是不是你正好在pppoe拨号开始前启用的服务，就获得非pppoe的名称？

我natmap服务是一直运行着的，故障的出现是当pppoe被移动踢下线后，openwrt再次发起拨号，之后natmap就打不上洞（此时命令行的接口变为wanb？）

如果服务一开始就运行着的，pppoe重拨应该不会自动重启服务，natmap的pid都保持不变，命令行参数也不应变。除非一开始就获取的是wanb。

等下次重拨时再观察下。 是否有办法避免命令行获取到wanb这个情况？

cc @ysc3839

ysc3839 commented 3 days ago

怀疑是因为PPPoE接口还没启动，natmap就先启动了？

niclau commented 3 days ago

昨天重拨了一次pppoe，natmap正常打洞。

heiher commented 3 days ago

怀疑是因为PPPoE接口还没启动，natmap就先启动了？

我估计是这样，有没有办法适配这种情况？