Shadowsocks-libev: redir 能否增加篡改DNS目标地址功能

[qiuzi]

ss-tunnel -u -s xxx -p xxx -l 5353 -L 8.8.8.8:53 -m xxxxx -k xxxx -v
iptables -t mangle -I PREROUTING -p udp --dport 53 -j TPROXY --on-port 5353 --tproxy-mark 100 --on-ip 127.0.0.1
pc端 nslookup baidu.com 提示超时

ss-tunnel 也没有任何日志输出

[oakaigh]

@qiuzi TPROXY works for transparent proxies ONLY. The difference between these two (tunneling and proxying) is that the former one wraps traffic inside shadowsocks protocol (original addr:port unaltered) while the latter alters the addr:port to make it appear "(coming) directly from the original server, leaving the client with no knowledge of the origin servers." (definition of reverse transparent proxy)

The iptables rule that redirects (PREROUTING local and inbound) all UDP traffic with destination port (--dport 53) to a specific IP address (<listening_addr>) on a specific port (5353 in this example) looks like this

        iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to <listening_addr>:5353

<listening_addr> is the address that ss-tunnel listens on.
You can apply this setting on your router to hijack DNS queries originated from all clients connected to your local network.

[qiuzi]

@PantherJohn
I want to completely transparent proxy, nat can't handle 2 layer data stream

[oakaigh]

@qiuzi You didn't get the point. Since you are using ss-tunnel instead of ss-redir the iptables rule specified would not work unless you get rid of TPROXY option (I've explained why in my previous post); I'm not sure how this really works. But if you need complete transparent proxying It's simple enough for you to follow instructions in README.md and try ss-redir instead of sticking around for solutions related to ss-tunnel.

To sum it up, the things you should do right now:

• switch from ss-tunnel to ss-redir
• set up proper iptables rules
• configure your router to assign DNS address 8.8.8.8 via DHCP on client machines

[qiuzi]

@PantherJohn
How to force TPROXY to 8.8.8.8 without changing the terminal configuration? Because the intranet DNS has other services, you cannot change the DNS configuration.

[oakaigh]

@qiuzi That's barely possible; but another solution is to add iptables rules on your server hijacking DNS queries. This comes a little bit different but works pretty much the same:

        #iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 8.8.8.8:53

You can also specify destination address here if you want; in this case it should be -d <nsserver_to_hijack>

What do you mean by "Because the intranet DNS has other services, you cannot change the DNS configuration"? Since you are forcing "TPROXY to 8.8.8.8" there's no way for you not to change the DNS configuration. If you still need intranet DNS-based service you can specify the primary DNS and secondary DNS in DHCP settings which would be straightforward if you don't need query filtering/monitoring. Assume your intranet DNS (that "has other services") address is 172.16.0.254. The configuration should be

Primary DNS  8.8.8.8
Secondary DNS 172.16.0.254

or in a resolv.conf file on your router (if you enabled DNS proxying)

nameserver 8.8.8.8
nameserver 172.16.0.254

This would work if your local DNS doesn't NEED to handle queries on non-local internet domains (I mean google.com, facebook.com, etc.).

[qiuzi]

@PantherJohn
Use the iptables string module to intercept domain names. LAN DNS service is not affected.

[oakaigh]

Use the iptables string module to intercept domain names.

@qiuzi I don’t think iptables has such kind of feature (although it’s possible).

[hhding]

@qiuzi 你的问题说你有内网的 DNS，其中有些私有的域名，所以不希望所有的 DNS 解析都被重定向到外部 DNS 去解析对么？

[madeye]

Nope, you cannot do that.

[qiuzi]

@hhding 是的，最主要是作为中间人。类似于某某某污染的反运用

[oakaigh]

@qiuzi It should not necessarily be a middleman; being nice, you can separate the upstream and downstream part -- this case you need to reconfigure the intranet DNS; what DNS server software are you using, named, dnsmasq, or pdnsd? This appears to be off-topic though.

[qiuzi]

@PantherJohn
The situation of the Chinese network is probably not clear to you, which is beyond the conventional network structure.

[oakaigh]

@qiuzi It’s fairly easy to circumvent this problem — the spoofed addresses are typically within these CIDR ranges:

243.185.187.39, 46.82.174.68, 37.61.54.158, 93.46.8.89, 59.24.3.173, 203.98.7.65, 8.7.198.45, 78.16.49.15, 31.13.78.65, 159.106.121.75,
# Additional Rejection
# UPDATED Jan 4th, 2018
# Facebook
31.13.0.0/16,66.220.0.0/16,69.63.0.0/16,69.171.0.0/16,74.119.76.0/22,173.252.0.0/16,204.15.20.0/22,
# Twitter & Softlayer
64.13.0.0/16,67.15.0.0/16, 67.228.0.0/16,74.86.0.0/16, 75.126.0.0/16, 88.191.0.0/16,173.252.0.0/16, 174.36.0.0/16,174.37.0.0/16,199.59.0.0/16,205.186.0.0/16,208.43.0.0/16

[hhding]

@PantherJohn
The situation of the Chinese network is probably not clear to you, which is beyond the conventional network structure.

@qiuzi 你的问题不是 shadowsocks 要解决的问题。不适合在这里讨论。抽象的讲你的问题实际上是 DNS 查询根据域名向不同的上游查询的问题。你可以看下 dnsmasq，ChinaDNS 等。

@PantherJohn The IP addresses returned for poisoned DNS records are not fixed (I verified facebook with the IP address block you provided). The better way is to query the poisoned DNS record over encrypted tunnel to a GOOD DNS server.

[qiuzi]

@hhding
现在shadowsocks还是处理路由层数据，使用Nat完成转发机制。2018年末全面IPV6，IPV6默认不再需要Nat。如果还是以现有内网DNS服务器形式可能已经不能满足当下要求

[oakaigh]

@hhding Take a look at pdnsd you’ll find out. Not all queries should go through the encypted tunnel. Here’s a nice sample pdnsd conf file:

global {
        run_ipv4        = on;
        server_port     = 5353;
        perm_cache      = 1024;
        cache_dir       = "/var/cache/pdnsd";
        debug           = off;
        server_ip       = 127.0.0.1;
        status_ctl      = on;
        tcp_server      = off;
        query_method    = udp_only;

        daemon          = on;
        verbosity       = 1;

        min_ttl         = 15m;            # Retain cached entries at least 15 minutes.
        max_ttl         = 1w;             # One week.
        neg_ttl         = 0;
        timeout         = 10;             # Global timeout option (10 seconds).
        neg_rrs_pol     = off;
        neg_domain_pol  = on;
        udpbufsize      = 2048;  # Upper limit on the size of UDP messages.
        par_queries     = 2;
        randomize_recs  = on;

        proc_limit      = 10000;
        procq_limit     = 10000;
}

server {
        label= "Locality Compliance";

        ip="114.114.115.115";
        reject = 243.185.187.39,
                 46.82.174.68,
                 37.61.54.158,
                 93.46.8.89,
                 59.24.3.173,
                 203.98.7.65,
                 8.7.198.45,
                 78.16.49.15,
                 31.13.78.65,
                 159.106.121.75,
# SECTION Additional Rejection
# UPDATED Jan 4th, 2018

# Facebook
31.13.0.0/16,66.220.0.0/16,69.63.0.0/16,69.171.0.0/16,74.119.76.0/22,173.252.0.0/16,204.15.20.0/22,
# Twitter & Softlayer
64.13.0.0/16,67.15.0.0/16, 67.228.0.0/16,74.86.0.0/16, 75.126.0.0/16, 88.191.0.0/16,173.252.0.0/16, 174.36.0.0/16,174.37.0.0/16,199.59.0.0/16,205.186.0.0/16,208.43.0.0/16# SECTION END
;


        reject_policy = fail;

        proxy_only=on;
        timeout=1;
        uptest=none;
        purge_cache=off;
        preset=on;
}

server {
        label = "Downstream encrypted";
        ip="127.0.0.2";
        port=5353;
        proxy_only=on;
        timeout=1;
        uptest=none;
        purge_cache=off;
        preset=on;
}

[qiuzi]

@PantherJohn
This is a passive situation. Pollution will change the strategy at any time.国土之大 无奇不有

[studentmain]

把内网DNS翻出去就行了。客户端的DNS服务器设置成你的内网DNS，你的DNS服务器上游设成国外服务器就是。

[qiuzi]

@studentmain
PC----to -----dnsmasq(dhcp) 两端都不能改变任何配置，只允许在中间加入设备

• [ ] |
• [ ] |
  tproxy：8.8.8.8 #

[studentmain]

那你这问题有点大，既没有网管该有的权限，又要办网管该办的事情。直接去要权限或者直接把旧DNS服务下架换新可能来得快一些。

[qiuzi]

使用redir的TPROXY功能

device:iptables -t mangle -I PREROUTING -p udp --dport 53 -m string --hex-string "|66 66 66 66 66 66 66 66|" --to 255 --algo bm -j TPROXY --on-port 5353 --tproxy-mark 100

pc:nslookup xxxxx.com 8.8.4.4
能得到正确回应
由此可以猜想 如果把pc默认dns地址强制篡改为8.8.8.8

[hhding]

我看了一下TProxy的文档和示例代码，从设计上tunnel肯定是不包括处理TProxy的代码的。redir在UDP模式下用TProxy也没问题。但是在TCP模式下用TProxy需要额外处理非常多的事情（主要是回包）。另外，楼主的提问应该是redir怎么配合TProxy才比较适合。

此外，这个更像是个智力题。现实中不应该加这么多限制去解决这种问题。