daeuniverse
[Bug Report] 在发起请求的设备上如果设置了 hosts，dae 会嗅探失败
Checks
- [X] I have searched the existing issues
- [X] I have read the documentation
- [ ] Is it your first time sumbitting an issue
Current Behavior
发现在发起请求的设备上如果设置了 hosts，dae 会嗅探失败
Expected Behavior
正常嗅探到域名，且在 domain++ 模式下重新路由流量
Steps to Reproduce
- 在主路由上运行 daed, 在发起请求的设备上配置 hosts，并用这个域名发起请求
Environment
-
Dae version (use
dae --version): 0.6.0rc2 -
OS (e.g
cat /etc/os-release): ImmortalWrt 23.05.1 -
Kernel (e.g.
uname -a): Linux ImmortalWrt 5.15.137 #0 SMP Sun Nov 19 17:02:49 2023 x86_64 GNU/Linux - Others:
Anything else?
在主路由上抓了一下包显示请求的 SNI 是正常的，日志显示没有嗅探到域名，看了一下没有什么针对嗅探的配置，所以应该是一个 bug？ 还是说因为设置的 hosts 导致 DNS 不经过 dae 所以嗅探失败了，粗略看了一下代码是有从 TLS 握手包中获取 SNI 的逻辑的，但是没有深入看，所以不知道是不是这个原因导致的
日志如下
root@ImmortalWrt:~# tail -f /var/log//daed/daed.log | grep 45.32.113.xxx
time="Aug 22 12:01:07" level=info msg="192.168.33.120:51518 <-> 45.32.113.xxx:443" dialer="1.新加坡 IEPL [03] [Std]" dscp=0 ip="45.32.113.xxx:443" mac="00:11:32:88:b0:01" network=tcp4 outbound=proxy pid=0 pname= policy=min_moving_avg sniffed=
time="Aug 22 12:01:18" level=info msg="192.168.33.120:51575 <-> 45.32.113.xxx:443" dialer="1.新加坡 IEPL [03] [Std]" dscp=0 ip="45.32.113.xxx:443" mac="00:11:32:88:b0:01" network=tcp4 outbound=proxy pid=0 pname= policy=min_moving_avg sniffed=
路由器上抓包数据见压缩包
![dae-prow[bot] avatar](https://avatars.githubusercontent.com/in/345419?v=4 "Published by a pub.dev verified publisher"){kind=small}
修改 嗅探超时 (ms) 为 200 后比较稳定的能成功了
root@ImmortalWrt:~# ping 192.168.33.120 PING 192.168.33.120 (192.168.33.120): 56 data bytes 64 bytes from 192.168.33.120: seq=0 ttl=64 time=0.967 ms 64 bytes from 192.168.33.120: seq=1 ttl=64 time=1.273 ms 64 bytes from 192.168.33.120: seq=2 ttl=64 time=1.006 ms 64 bytes from 192.168.33.120: seq=3 ttl=64 time=1.127 ms 64 bytes from 192.168.33.120: seq=4 ttl=64 time=1.132 ms 64 bytes from 192.168.33.120: seq=5 ttl=64 time=0.955 ms 64 bytes from 192.168.33.120: seq=6 ttl=64 time=0.783 ms ^C --- 192.168.33.120 ping statistics --- 7 packets transmitted, 7 packets received, 0% packet loss round-trip min/avg/max = 0.783/1.034/1.273 ms
这个延时应该不算高吧？需要调整到 200 这么大才可以吗
@EkkoG 什么情况下要调高嗅探超时还不明确，之前查明是tcp握手之后的首包接收较慢导致，但未能找到根因。当时的案例重启无法解决，重装 linux 系统解决
