Closed linfan closed 2 years ago
This is a full log tun2socks.log
Have you tried to add those ip as exceptional routes?
Honestly, I haven't well tested this project in Windows, so I may not have better solutions yet.
Many of the packages are request sent by tun2sock itself, route rule may not work.
After some digging, I found there are also lot of request or response to some certain ports besides 5353. Currently I add below lines at the beginning of handleUDP(packet core.UDPPacket)
method as a workaround, drop all flooding packages.
if strings.HasSuffix(packet.RemoteAddr().String(), ":137") ||
strings.HasSuffix(packet.RemoteAddr().String(), ":5353") ||
strings.HasSuffix(packet.LocalAddr().String(), ":1900") ||
strings.HasSuffix(packet.LocalAddr().String(), ":5355") {
return
}
So far so good, as I don't use any of above ports. However the truth is not yet clear.
I suddenly realized that Windows doesn't even have things like iptables to do packet dropping for you...
Windows has netsh firewall
command which can handle the package dropping things, though I don't familiar with that either.
Today I find these UDP flooding also happened under MacOS. After setup tun2socks, I add 172.20.0.0/16
route to the tun, and 172.20.0.10
is an internal DNS server within that IP range. When I do nslookup <some-domain> 172.20.0.10
, in the tun2socks log I will see in total of 57 UDP requests are send to the 53 port of target address:
INFO[0930] [UDP] 172.20.0.0:64947 --> 172.20.0.10:53
INFO[0930] [UDP] 172.20.0.0:51459 --> 172.20.0.10:53
INFO[0930] [UDP] 172.20.0.0:59504 --> 172.20.0.10:53
INFO[0930] [UDP] 172.20.0.0:62967 --> 172.20.0.10:53
INFO[0930] [UDP] 172.20.0.0:62975 --> 172.20.0.10:53
INFO[0930] [UDP] 172.20.0.0:60109 --> 172.20.0.10:53
INFO[0930] [UDP] 172.20.0.0:59172 --> 172.20.0.10:53
INFO[0930] [UDP] 172.20.0.0:63948 --> 172.20.0.10:53
INFO[0930] [UDP] 172.20.0.0:52707 --> 172.20.0.10:53
INFO[0930] [UDP] 172.20.0.0:57995 --> 172.20.0.10:53
... ... in total 57 times ... ...
However there is no response (and no log found in DNS server, I believe the package was lost somehow).
It seems the flooding only happen with UDP, All TCP connection working well so far.
Hmm, you need tun2socks handle your internal DNS query? but it would be sent to your socks server though.
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days
Environment
Log
Above are log without any IP or route set to tun device. If an IP v4 address is assigned to this tun device, there will be even more packages, sending to both
[ff02::fb]:5353
and224.0.0.251:5353
.Describe the bug
By searching "5353" in the issue list, I'm sure those requests are innocent but should in a much lower frequency (about ~10 per second), wondering what happens...
Any suggestion or clues ?
To Reproduce
Just run
tun2socks
executable.