surge tun-excluded-routes是否有效？

thefoftt

看surge手册这个选项是对路由表增加额外的规则，使特定路由绕过VIF，但目前看貌似不起作用。
比如：tun-excluded-routes = 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12
并开启增强模式
比如访问这个ip 10.19.35.56

netstat -nr

Internet:
Destination Gateway Flags Netif Expire
default 192.168.137.1 UGSc en10
1 198.18.0.1 UGSc utun2
2/7 198.18.0.1 UGSc utun2
4/6 198.18.0.1 UGSc utun2
8/5 198.18.0.1 UGSc utun2
16/4 198.18.0.1 UGSc utun2
32/3 198.18.0.1 UGSc utun2
64/2 198.18.0.1 UGSc utun2
127 127.0.0.1 UCS lo0
127.0.0.1 127.0.0.1 UH lo0
128.0/1 198.18.0.1 UGSc utun2
169.254 link#22 UCS en10 !
192.168.137 link#22 UCS en10 !
192.168.137.1/32 link#22 UCS en10 !
192.168.137.1 0:e:c6:fb:68:16 UHLWIir en10 1145
192.168.137.2 link#22 UHLWIi en10 !
192.168.137.3/32 link#22 UCS en10 !
192.168.137.3 64:4b:f0:2b:2f:ba UHLWI lo0
198.18.0/15 198.18.0.1 UGSc utun2
198.18.0.1 198.18.0.1 UH utun2
224.0.0/4 link#22 UmCS en10 !
224.0.0.251 1:0:5e:0:0:fb UHmLWI en10
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI en10
255.255.255.255/32 link#22 UCS en10 !

❯ route get 10.19.35.56

route to: 10.19.35.56
destination: 8.0.0.0
mask: 248.0.0.0
gateway: 198.18.0.1
interface: utun2
flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 9000 0

ping 10.19.35.56
sudo tcpdump -i utun2 -nn host 10.19.35.56
listening on utun2, link-type NULL (BSD loopback), snapshot length 262144 bytes
18:19:09.603617 IP 198.18.0.1 > 10.19.35.56: ICMP echo request, id 62798, seq 0, length 64
18:19:09.606116 IP 10.19.35.56 > 198.18.0.1: ICMP echo reply, id 62798, seq 0, length 64

还是走VIF，不知道我理解的对不对？是配置问题还是BUG？请告知。
surge: 4.0.2(1211)
osx: big sur

谢谢.

SurgeTeam

请升级至最新版本。

fgprodigal

截屏2021-05-17 上午11.46.01.png
截屏2021-05-17 上午11.45.41.png

今天又遇到神奇的情况
4.1.1(1305)

SurgeTeam

thefoftt

👌🏻，4.1.0版本该选项功能正常。

Garlichead

thefoftt 我怎么查看到的是4.0.5是最新的没有4.1的版本

SurgeTeam

fgprodigal 该配置仅对增强模式的 VIF 有效，这个请求是 SOCKS5 代理服务访问的。

fgprodigal

SurgeTeam 那这个DataGrip这个app有点奇妙，是本机运行的也没配socks5代理

newrevolution

SurgeTeam I just started using Surge, is it appropriate to add the default TUN included and excluded route as below:

[General]
udp-policy-not-supported-behaviour = reject
skip-proxy = 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 127.0.0.1, localhost, *.local
tun-excluded-routes = 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12
tun-included-routes = 192.168.1.12/32
read-etc-hosts = true
use-local-host-item-for-proxy = true
ipv6 = true
test-timeout = 5
loglevel = notify
http-api-web-dashboard = true
http-api-tls = true
tls-provider = default
disable-geoip-db-auto-update = false
doh-server = https://1.1.1.1/dns-query
exclude-simple-hostnames = true
dns-server = 1.1.1.1, 2606:4700:4700::1111, 1.0.0.1, 2606:4700:4700::1001, system
http-listen = 0.0.0.0, 127.0.0.1
socks5-listen = 0.0.0.0, 127.0.0.1
sni = on
tfo = true
hijack-dns = 1.1.1.1:53

[Replica]
hide-udp = 0
keyword-filter-type = none

newrevolution

SurgeTeam fgprodigal Please, I figured out a way to use my SSH software connected on the same PC with Surge by setting the listening port on the SSH tunnel App to

ssh -N -D 127.0.0.1:1080 -o ServerAliveInterval=15 -o ExitOnForwardFailure=yes -o ServerAliveCountMax=3 -o HostKeyAlgorithms=+ssh-rsa -p 22 comcast@17.81.xxx.xxxx

and then setting Proxy in Surge to
[Proxy]
ProxyB = socks5, 127.0.0.1, 1080

It connects and works very fine and very secured. It means I'm using double encryption: one on the SSH app(diffie-hellman-group-exchange-sha256) and the other on Surge (with the tls cipher TLS Protocol TLS 1.3 [HTTP/2.0] Cipher Suite 0x1302 TLS_AES_256_GCM_SHA384).

But here is the problem, I have to launch and connect the SSH App before launching Surge because surge won't let it connect if I launch surge first. If there's a drop in the connection on the SSH App, I have to quite surge first and then SSH tunnel app reconnects automatically and then launch Surge. Please, how do I tell Surge that the SSH tunnel App is the source so that it does not prevent the SSH app from connecting?
Thanks

newrevolution

sshplease
SurgeTeam fgprodigal Please, I figured out a way to use my SSH software connected on the same PC with Surge by setting the listening port on the SSH tunnel App to

ssh -N -D 127.0.0.1:1080 -o ServerAliveInterval=15 -o ExitOnForwardFailure=yes -o ServerAliveCountMax=3 -o HostKeyAlgorithms=+ssh-rsa -p 22 comcast@17.81.xxx.xxxx

and then setting Proxy in Surge to
[Proxy]
ProxyB = socks5, 127.0.0.1, 1080

newrevolution

I just started using Surge, is it appropriate to add the default TUN included and excluded route as below:

[Replica]
hide-udp = 0
keyword-filter-type = none

mieqq

newrevolution You don't have to add it unless you clearly need it.

newrevolution

Thank you, but I'm using the enhanced mode. I thought it was necessary to allow some traffic so that the traffic from the tun excluded route can be taken care of by the surge VIF. Is that correct?

mieqq

newrevolution https://manual.nssurge.com/book/understanding-surge/en/#virtual-nic-takeover-method-2

newrevolution

mieqq Okay I read the manual you provided via https://manual.nssurge.com/book/understanding-surge/en/#virtual-nic-takeover-method-2 and the other official manual via https://manual.nssurge.com/others/misc-options.html

tun-included-routes = 192.168.1.100/32 OR tun-included-routes = 192.168.1.12/32

I found the first IP range 100/32 in the link you provided while the second one 12/32 in the Miscellaneous option page in the official guide.
Which one is best?

newrevolution

mieqq It's quite confusing how Surge do not have an official set up or a unanimous configuration. Here is the General section shown in the guide which shows the TUN IP ranges. : https://manual.nssurge.com/others/misc-options.html

[General]
ipv6 = false
loglevel = notify
skip-proxy = 127.0.0.1, 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 100.64.0.0/10, localhost, *.local
tun-excluded-routes = 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12
tun-included-routes = 192.168.1.12/32

mieqq

newrevolution You don't have to add it, Those are just examples.

newrevolution

mieqq I need it because I'm using the enhanced mode which uses VIF. So, I need it so that the traffic not captured by Surge Proxy can be captured by VIF via TUN routes. And I'm asking again: Which IP range is correct for the TUN included route = 192.168.1.100/32 OR 192.168.1.12/32

SurgeTeam

newrevolution If you don't understand the meaning of this parameter. You definitely don't need it and should not set.

newrevolution

SurgeTeam
Hello Admin, I totally understand that the Surge VIF is a VPN-app simulation which captures all traffics skipped by Surge proxy and the excluded-simple host names by setting up the TUN excluded and included routes.

Please, this is necessary because I'm using the enhanced Mode. I need to know what IP range is appropriate for the TUN Included route. In the two manuals, there are two different ranges which I pasted in my earlier post.

Lastly and most importantly, I figured out a bug in the enhanced Mode and I found the workaround. There's a Webrtc leakage in the Apps that makes use of the enhanced Mode despite the fact that the new quic module and udp-policy-not-supported-behaviour = reject are added. E.g. open mozilla firefox, go to preferences>General>Network settings> select No proxy so that it can use Enhanced Mode, then run a webrtc leak test using browserleaks.com

The work around:
In Mozilla, go to about:config and search for network.http.http3.enabled and set to false.
Download webrtc control and set to disable non proxied UDP.

Now, similar steps can be done in Chromium based browsers but the problems is that there is no work around for other applications that binds using the Enhanced mode except browsers. Please Fix

newrevolution

SurgeTeam Please Admin, this bug has to be fixed because every user would expect to be secured by putting on global proxy combined with enhanced Mode but unfortunately, the enhanced Mode can only force the other apps not supported by proxies to be proxied but the webrtc leaks on those apps.

Also, I have another complaint. client name: timed(101) with the Hostname/URL: time.apple.com takes care of the time stamps on MacOS just like time.android.com on Android devices.
This client uses UDP connections on port 123 which are rejected by the UDP traffic reject-drop policy.
It'd be great if that can also be blocked to TCP like the new QUIC module added to block UDP connections on port 443.

Also, Firefox runs a client called FirefoxCPWebextension with the Hostname: stun.I.google.com on port 19302 also uses UDP connections. If this is done, Webrtc leakage can be taken care of in Mozilla.

newrevolution

"Administrator"#p1802

Hello to you guys, it is very absurd you don't want to explain things in details but you rely on users, both advanced and beginners, for feedbacks and corrections of bugs. If, as a developer, you could not produce surge without bugs then no one is perfect and everyone is a learner in the longrun. No one is an island and it is needless to not give in-depth support to users. I figured out a work around and I'm enjoying the connections. There's no need to share that with you guys since you didn't understand my predicament and what using surge with SSH means to my anonymity and security. It makes me sad whenever I get such messages from surge support. A paid-support would be more reasonable than no support at all. Good bye

SurgeTeam

newrevolution

newrevolution I hope a module can be developed to block the port 123 and 19302 for stun queries to TCP