My goal is to set up shadowsocks on my router so that it would reroute all network traffic to the remote server. To achieve this, I followed this tutorial as suggested by previous users on this forum:
Everything was going fine up till I reach the last step where domain name resolution seems to just fail completely after applying changes to dnsmasq.
user@iMac ~ % unset {http,https,ftp}_proxy
user@iMac ~ % nslookup google.com
;; connection timed out; no servers could be reached
user@iMac ~ % nslookup baidu.com
;; connection timed out; no servers could be reached
Any suggestions?
EDIT: Solved, for detailed solution see post #8. In fact this isn't actually a solution but more like a workaround. Check it out here if you couldn't be bothered with the reading.
config ss_rules 'ss_rules'
option dst_default 'forward'
option local_default 'forward'
option dst_forward_recentrst '0'
option src_default 'checkdst'
option redir_tcp 'redir'
option redir_udp 'redir'
config server 'vultr_jp_v4'
option server '[REDACTED]'
option server_port '[REDACTED]'
option method 'chacha20-ietf-poly1305'
option password '[REDACTED]'
config ss_redir 'redir'
option mode 'tcp_and_udp'
option reuse_port '1'
option local_port '1100'
option local_address '0.0.0.0'
option server 'vultr_jp_v4'
option disabled 'false'
config ss_tunnel 'tunnel'
option mode 'tcp_and_udp'
option local_port '8053'
option server 'vultr_jp_v4'
option tunnel_address '108.61.10.10:53' //tried "8.8.8.8:53" and "1.1.1.1:53" before but neither worked
option local_address '127.0.0.1'
option disabled 'false'
config ss_local 'local' //this was used to validate the configuration for the server and it turned out shadowsocks would work just fine using this mode whilst enabling socks proxy on one of my client computers
option mode 'tcp_and_udp'
option local_address '192.168.1.1'
option local_port '1080'
option server 'vultr_jp_v4'
option disabled 'true'
Some update:
Looks like ss_redir is working considering the international page for Bing would load up if I try to go to bing.com using its previously resolved IP and my browser does seem to have the external IP of the remote server.
It seems to me that somewhere between ss_tunnel and dnsmasq is broken that's causing DNS resolution to fail. I am completely lost now
Any help would be greatly appreciated!!!! <3
EDIT: Looked around the forum a bit and I suspect this might be a duplicate of this issue. Not sure tho.
Yet another update:
ss-tunnel seems to be the culprit here although I can't see how it wouldn't work.
In theory, this command should give me a tunnel to translates 8.8.8.8:53 to 127.0.0.1:5300 (or at least that's the command actually being used by the openwrt shadowsocks service anyway):
After forwarding the port, if I do nslookup google.com 127.0.0.1:5300, it would still report ;; connection timed out; no servers could be reached, which seems to me that the tunnel is somehow broken although other shadowsocks services work. Using netcat I can see that the udp port 5300 on my router should be open:
user@iMac ~ % nc -uzvw3 192.168.1.1 5300
Connection to 192.168.1.1 port 5300 [udp/hacl-hb] succeeded!
If I run the command nslookup google.com 8.8.8.8#53 on the remote server everything just works and it gives me:
Turns out for some reason ss-tunnel keeps failing to redirect UDP traffic but DNS over TLS works. I suspect this is because DNS pollution happens to all UDP packets towards outside of the nationwide firewall so encapsulating UDP traffic within TLS TCP would "just work". On OpenWrt this can be solved by using Unbound which if I'm understanding everything correctly here will give you DNS resolution over TLS, hence TCP traffic.
Basically you just have to ditch ss-tunnel for tunneling through DNS resolution and instead use Unbound, setting it to whichever clean DNS server you'd like to use (personally I'm using 1.1.1.1). I guess this implies performance wise there will be a reduction if ss-redir isn't enabled for localhost but honestly this is the next best alternative so I'm accepting this with as my final solution.
Personally I would recommend using Stubby.Unbound kind of has some issue with CNAME(which is what I'm experiencing right now.)Here is a post regard this CNAME thing but it's Chinese:https://www.v2ex.com/t/561495
Ah I see, so currently Unbound has problems filtering subdomains while interfering with DNS resolution. I guess I’ll wait until they merge the patch into its master branch thereby into the OpenWrt build bot and see what happens next. As of now I’m quite satisfied with my setup since global mode was all I needed. But then again, I can see how it’d be a nice addition to Unbound itself.
Unbound automatically will not appear to follow CNAME that cross SOA or CNAME inserted into its configuration files. The client will be given the CNAME and the client will need to ask the next question. dnsmasq automatically completes CNAME because it just wants an A/AAAA record and simply forwards all requests to the one or two upstream servers anyway. Github issues on CNAME filtering.
Unbound 1.10.0 package has ipset support with Unbound-daemon-heavy