zfl9 / ss-tproxy Goto Github PK
View Code? Open in Web Editor NEW搭建 SS/SSR/V2Ray/Trojan/Socks5 透明代理的 Shell 脚本
License: GNU Affero General Public License v3.0
搭建 SS/SSR/V2Ray/Trojan/Socks5 透明代理的 Shell 脚本
License: GNU Affero General Public License v3.0
尝试用一台CentOS 7.5云服务器搭建ss-tproxy,但是无法解析域名
访问Google的IP地址http://172.217.161.36,可以成功返回,但是方位http://www.google.com则提示无法解析域名。
服务端是自建的,支持udp,如下是配置文件:
## mode
mode='global'
#mode='gfwlist'
#mode='chnroute'
## proxy
proxy_tproxy='false' # 纯TPROXY方式
proxy_server=(47.*.*.*) # 服务器的地址
proxy_dports='443' # 服务器的端口
proxy_tcport='60080' # TCP 监听端口
proxy_udport='60080' # UDP 监听端口
proxy_runcmd='(ss-redir -s 47.*.*.* -p 443 -m aes-256-cfb -k ******** -b 0.0.0.0 -l 60080 -u -v >>/var/log/ss-redir.log 2>&1 &)' # 启动的命令行
proxy_kilcmd='kill -9 $(pidof ss-redir)' # 停止的命令行
## dnsmasq
dnsmasq_cache_size='10240' # DNS 缓存条目
dnsmasq_cache_time='3600' # DNS 缓存时间
dnsmasq_log_enable='true' # 是否记录日志
dnsmasq_log_file='/var/log/dnsmasq.log' # 日志文件路径
## chinadns
chinadns_mutation='false' # DNS 压缩指针
chinadns_verbose='false' # 记录详细日志
chinadns_logfile='/var/log/chinadns.log' # 日志文件路径
## dns
dns_modify='false' # 直接修改 resolv.conf
dns_remote='8.8.8.8:53' # 国外 DNS,必须指定端口
dns_direct='114.114.114.114' # 国内 DNS,不能指定端口
## ipts
ipts_rt_tab='100' # iproute2 路由表名或 ID
ipts_rt_mark='0x2333' # iproute2 策略路由的标记
ipts_non_snat='false' # 不设置 SNAT iptables 规则
ipts_intranet=(10.10.5.0/24) # 内网网段,多个请用空格隔开
## opts
opts_ss_netstat="auto" # 'auto|ss|netstat',使用哪个端口检测命令
## file
file_gfwlist_txt='/etc/ss-tproxy/gfwlist.txt' # gfwlist 黑名单文件 (默认规则)
file_gfwlist_ext='/etc/ss-tproxy/gfwlist.ext' # gfwlist 黑名单文件 (扩展规则)
file_chnroute_txt='/etc/ss-tproxy/chnroute.txt' # chnroute 地址段文件 (chinadns)
file_chnroute_set='/etc/ss-tproxy/chnroute.set' # chnroute 地址段文件 (iptables)
下面是iptables的规则:
# Generated by iptables-save v1.4.21 on Mon Feb 11 00:20:20 2019
*nat
:PREROUTING ACCEPT [11:521]
:INPUT ACCEPT [115:6606]
:OUTPUT ACCEPT [245:17457]
:POSTROUTING ACCEPT [73:5111]
:SSTP_OUT - [0:0]
:SSTP_PRE - [0:0]
:TCPCHAIN - [0:0]
-A PREROUTING -j SSTP_PRE
-A OUTPUT -j SSTP_OUT
-A POSTROUTING -s 10.10.5.0/24 ! -d 10.10.5.0/24 -j MASQUERADE
-A SSTP_OUT -p tcp -j TCPCHAIN
-A SSTP_OUT -d 127.0.0.1/32 -p udp -m udp --dport 53 -j REDIRECT --to-ports 60053
-A SSTP_PRE -s 10.10.5.0/24 -p udp -m udp --dport 53 -m mark ! --mark 0x2333 -j REDIRECT --to-ports 60053
-A SSTP_PRE -s 10.10.5.0/24 -p tcp -j TCPCHAIN
-A TCPCHAIN -d 0.0.0.0/8 -j RETURN
-A TCPCHAIN -d 10.0.0.0/8 -j RETURN
-A TCPCHAIN -d 127.0.0.0/8 -j RETURN
-A TCPCHAIN -d 169.254.0.0/16 -j RETURN
-A TCPCHAIN -d 172.16.0.0/12 -j RETURN
-A TCPCHAIN -d 192.168.0.0/16 -j RETURN
-A TCPCHAIN -d 224.0.0.0/4 -j RETURN
-A TCPCHAIN -d 240.0.0.0/4 -j RETURN
-A TCPCHAIN -d 47.xx.xx.xx/32 -p tcp -m multiport --dports 443 -j RETURN
-A TCPCHAIN -p tcp -j REDIRECT --to-ports 60080
COMMIT
# Completed on Mon Feb 11 00:20:20 2019
# Generated by iptables-save v1.4.21 on Mon Feb 11 00:20:20 2019
*mangle
:PREROUTING ACCEPT [866:57973]
:INPUT ACCEPT [1102:72149]
:FORWARD ACCEPT [2:158]
:OUTPUT ACCEPT [896:1319860]
:POSTROUTING ACCEPT [898:1320018]
:SSTP_OUT - [0:0]
:SSTP_PRE - [0:0]
:UDPCHAIN - [0:0]
-A PREROUTING -j SSTP_PRE
-A OUTPUT -j SSTP_OUT
-A SSTP_OUT -p udp -j UDPCHAIN
-A SSTP_PRE -s 10.10.5.0/24 -p udp -m udp --dport 53 -m mark ! --mark 0x2333 -j ACCEPT
-A SSTP_PRE -s 10.10.5.0/24 -p udp -m mark ! --mark 0x2333 -j UDPCHAIN
-A SSTP_PRE -p udp -m mark --mark 0x2333 -j TPROXY --on-port 60080 --on-ip 127.0.0.1 --tproxy-mark 0x0/0x0
-A UDPCHAIN -d 0.0.0.0/8 -j RETURN
-A UDPCHAIN -d 10.0.0.0/8 -j RETURN
-A UDPCHAIN -d 127.0.0.0/8 -j RETURN
-A UDPCHAIN -d 169.254.0.0/16 -j RETURN
-A UDPCHAIN -d 172.16.0.0/12 -j RETURN
-A UDPCHAIN -d 192.168.0.0/16 -j RETURN
-A UDPCHAIN -d 224.0.0.0/4 -j RETURN
-A UDPCHAIN -d 240.0.0.0/4 -j RETURN
-A UDPCHAIN -d 47.xx.xx.xx/32 -p udp -m multiport --dports 443 -j RETURN
-A UDPCHAIN -j MARK --set-xmark 0x2333/0xffffffff
COMMIT
# Completed on Mon Feb 11 00:20:20 2019
在ss-redir的日志里能看到:
2019-02-11 00:24:30 INFO: [60080] [udp] cache miss: 8.8.8.8:53 <-> 10.10.5.167:55266
2019-02-11 00:24:35 INFO: [udp] server receive a packet
2019-02-11 00:24:35 INFO: [60080] [udp] cache hit: 8.8.8.8:53 <-> 10.10.5.167:55266
RT,目前解决方案是直接用chnroute然后替换了chnroute的表,感觉过于暴力,请问有什么更好地解决方案吗?比如让chnroute的ip才走ss-redir.
我按照教程安装好之后,发现tcp(http)是正常走透明代理的,但是udp还是走我自己的网络
这个如何设置规则呢?
ps:我的udp程序是aria2下载器
我使用
iptables -t mangle -I OUTPUT -p icmp -j MARK --set-mark 0x15
ip rule add fwmark 0x15 table 2
ip route add 0/0 dev wg0 table 2
来实现使ICMP走隧道出去,但是在使用了 ss-tproxy的机器上,这个指令是失效的,数据包并没有成功mark.
大大你好,我经常用 ss-tproxy 中的 chnroute 模式,用这个模式就意味着大部分境外 ip 都要走代理,如果进行 BT/PT 下载 vps 可能就会被封,但大部分 P2P 类下载软件,多使用高端口,所以我想是不是可以自定义需要代理的端口来避免这个问题。openwrt 上的 luci-app-shadowsocks(https://github.com/shadowsocks/luci-app-shadowsocks) 提供了此功能,恩山上 hiboy 的 Padavan 固件所内置的 ss 也支持了。我感觉这个功能还是挺重要的,期待大大的进一步开发!大大加油!
客户机如果使用了非路由器的DNS,会无法解析到正确地址。可添加以下规则强制使用重定向地址的DNS
iptables -t mangle -A SS-UDP -p udp --dport 53 -j RETURN
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to 192.168.1.1
目前我是在树莓派上使用ss-tproxy配合create_ap提供wifi全局FQ的。
当我使用ss-tproxy restart
的时候,ss-tproxy会将全部的dnsmasq进程都关闭,虽然可以通过更换DHCPD来提供dhcp服务,但是其实只需要ss-tproxy在启动和停止应用的时候,使用pid文件识别就可以解决相关问题了。
设置监听的内网网段是(192.168.0.0/16 172.17.0.0/16)
现状:
(1)主机可以使用代理
(2)Docker容器中无法使用代理,甚至无法联网
更新后发现systemctl start ss-tproxy无法启动
systemctl status ss-tproxy如下
Failed at step EXEC spawning /usr/bin/ss-tproxy: Permission denied
关闭SeLinux可以正常启动
回退到commit 5b393a3a8107c961c91bec2f933e3ed0d309f900
可以正常启用
有空我在找找具体原因
我怀疑是 iptables 的问题,帮忙看看这个 iptables 有没有问题,谢谢了!
bash-4.4# iptables-save
# Generated by iptables-save v1.6.2 on Sun Mar 31 10:25:35 2019
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:SETMARK - [0:0]
:SSTP_OUT - [0:0]
:SSTP_PRE - [0:0]
-A PREROUTING -j SSTP_PRE
-A OUTPUT -j SSTP_OUT
-A SETMARK -d 8.8.8.8/32 -p udp -j MARK --set-xmark 0x2333/0xffffffff
-A SETMARK -m set --match-set gfwlist dst -j MARK --set-xmark 0x2333/0xffffffff
-A SSTP_OUT -p tcp -j SETMARK
-A SSTP_OUT -p udp -j SETMARK
-A SSTP_PRE -s 192.168.2.0/24 -p udp -m udp --dport 53 -m mark ! --mark 0x2333 -j ACCEPT
-A SSTP_PRE -s 192.168.2.0/24 -p tcp -m mark ! --mark 0x2333 -j SETMARK
-A SSTP_PRE -s 192.168.2.0/24 -p udp -m mark ! --mark 0x2333 -j SETMARK
-A SSTP_PRE -p tcp -m mark --mark 0x2333 -j TPROXY --on-port 60080 --on-ip 127.0.0.1 --tproxy-mark 0x0/0x0
-A SSTP_PRE -p udp -m mark --mark 0x2333 -j TPROXY --on-port 60080 --on-ip 127.0.0.1 --tproxy-mark 0x0/0x0
COMMIT
# Completed on Sun Mar 31 10:25:35 2019
# Generated by iptables-save v1.6.2 on Sun Mar 31 10:25:35 2019
*raw
:PREROUTING ACCEPT [10:736]
:OUTPUT ACCEPT [9:442]
COMMIT
# Completed on Sun Mar 31 10:25:35 2019
# Generated by iptables-save v1.6.2 on Sun Mar 31 10:25:35 2019
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:SSTP_OUT - [0:0]
:SSTP_PRE - [0:0]
-A PREROUTING -j SSTP_PRE
-A OUTPUT -j SSTP_OUT
-A SSTP_OUT -d 127.0.0.1/32 -p udp -m udp --dport 53 -j REDIRECT --to-ports 53
-A SSTP_PRE -s 192.168.2.0/24 -p udp -m udp --dport 53 -m mark ! --mark 0x2333 -j REDIRECT --to-ports 53
COMMIT
# Completed on Sun Mar 31 10:25:35 2019
# Generated by iptables-save v1.6.2 on Sun Mar 31 10:25:35 2019
*filter
:INPUT ACCEPT [10:736]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [9:442]
COMMIT
# Completed on Sun Mar 31 10:25:35 2019
我这里计划假设从国外往国内的ss代理,所以需求是搭梯子的往国内的代理。
使用的是最新的提交:
b0e8dea
以下使用 client 指代非网关机器, server 指代运行 ss-tproxy 的机器。
设置成 chnroute 模式,client 运行:
curl https://news.qq.com
就一直卡住,没有输出,而 server 就正常。
client 和 server 获取国外服务器均正常:
curl https://www.google.com
设置成 global 模式,两台机器获取国内国外服务器都正常。
已经使用 /usr/local/bin/ss-tproxy update-chnroute 更新过 chnroute 表。
以下是调试信息:
Client:
#dig news.qq.com
; <<>> DiG 9.14.0 <<>> news.qq.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 517
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;news.qq.com. IN A
;; ANSWER SECTION:
news.qq.com. 69 IN CNAME https.qq.com.
https.qq.com. 545 IN A 183.3.226.35
;; Query time: 30 msec
;; SERVER: 168.168.0.14#53(168.168.0.14)
;; WHEN: Tue Apr 09 12:58:29 CST 2019
;; MSG SIZE rcvd: 76
Server:
# ipset test chnroute 183.3.226.35
183.3.226.35 is in set chnroute.
ss-tproxy.conf:
## mode
#mode='global'
#mode='gfwlist'
mode='chnroute'
## proxy
proxy_tproxy='false' # 纯TPROXY方式
proxy_server=(xxx01 xxx02) # 服务器的地址
proxy_dports='' # 服务器的端口
proxy_tcport='60080' # TCP 监听端口
proxy_udport='60080' # UDP 监听端口
proxy_runcmd='systemctl start [email protected]' # 启动的命令行
proxy_kilcmd='systemctl stop [email protected]' # 停止的命令行
## dnsmasq
dnsmasq_cache_size='10240' # DNS 缓存条目
dnsmasq_cache_time='3600' # DNS 缓存时间
dnsmasq_log_enable='true' # 是否记录日志
dnsmasq_log_file='/var/log/dnsmasq.log' # 日志文件路径
## chinadns
chinadns_mutation='false' # DNS 压缩指针
chinadns_verbose='false' # 记录详细日志
chinadns_logfile='/var/log/chinadns.log' # 日志文件路径
## dns
dns_modify='false' # 直接修改 resolv.conf
dns_remote='8.8.8.8:53' # 国外 DNS,必须指定端口
dns_direct='114.114.114.114' # 国内 DNS,不能指定端口
## ipts
ipts_rt_tab='100' # iproute2 路由表名或 ID
ipts_rt_mark='0x2333' # iproute2 策略路由的标记
ipts_non_snat='false' # 不设置 SNAT iptables 规则
ipts_intranet=(192.168.1.0/24 168.168.0.0/16) # 内网网段,多个请用空格隔开
环境安装和配置略复杂,我做了个镜像 感觉不是很理想
大神可以提供个官方docker镜像吗?供小白傻瓜化使用你的作品
Vray官方dokodemo-door已经支持linux 的tproxy转发数据,能否求个例子转发tcp数据,目前udp也是网上抄来的。
ip rule add fwmark 0x01/0x01 table 100
ip route add local 0.0.0.0/0 dev lo table 100
iptables -t mangle -N V2RAY
iptables -t mangle -A V2RAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 0x01/0x01
iptables -t mangle -A PREROUTING -j V2RAY
iptables -t mangle -I V2RAY -d 192.168.1.0/24 -j RETURN
想实现电视盒子走奈飞线路,其他设备走其他线路
是不是可以在脚本中判断用户设置的地址是否包含字符‘:’来判断是不是ipv6地址呢?然后在256-260行的地方简单地改变一下,如果是ipv6地址那么就不用return了,因为iptables 只处理ipv4。这是我自己用的脚本,大概是这样的。我不擅长Shell,大佬见笑了。
start_ss_redir(){
# Start the shadowsocks-redir
sudo ss-redir -s 2333:1111:5555:2fff:5454:ffff:ffff:2333 -p 23333 \
-m aes-256-cfb -b 0.0.0.0 -l 65535 -k password -u -v
}
if [ "$1" = "start" ]
then
sudo iptables -t nat -F PREROUTING #clear the PREROUTING chain
sudo iptables -t nat -F OUTPUT #clear the PREROUTING chain
sudo iptables -t nat -F SS_TCP #clear the chain
sudo iptables -t nat -X SS_TCP #delete the chain
sudo iptables -t nat -N SS_TCP # Create new chain
# Ignore shadowsocks server's addresses to avoid loop
# sudo iptables -t nat -A SS_TCP -p tcp --dport 65535 -j RETURN
# 我们在用ipv6所以这里不需要
# Ignore LANs addresses to bypass the proxy
# See Wikipedia and RFC5735 for full list of reserved networks
sudo iptables -t nat -A SS_TCP -d 0.0.0.0/8 -j RETURN
sudo iptables -t nat -A SS_TCP -d 10.0.0.0/8 -j RETURN
sudo iptables -t nat -A SS_TCP -d 127.0.0.0/8 -j RETURN
sudo iptables -t nat -A SS_TCP -d 169.254.0.0/16 -j RETURN
sudo iptables -t nat -A SS_TCP -d 172.16.0.0/12 -j RETURN
sudo iptables -t nat -A SS_TCP -d 192.168.0.0/16 -j RETURN
sudo iptables -t nat -A SS_TCP -d 224.0.0.0/4 -j RETURN
sudo iptables -t nat -A SS_TCP -d 240.0.0.0/4 -j RETURN
# Anything else should be redirected to shadowsocks's local port
sudo iptables -t nat -A SS_TCP -p tcp -j REDIRECT --to-ports 65535
# apply the rules to TCP packages from WLAN Hotspot
sudo iptables -t nat -A PREROUTING -p tcp -s 10.42.0.0/24 \
-j SS_TCP
# apply the rules to local processes
sudo iptables -t nat -A OUTPUT -p tcp -j SS_TCP
start_ss_redir;
elif [ "$1" = "clear" ]
then
sudo iptables -t nat -F PREROUTING #clear the PREROUTING chain
sudo iptables -t nat -F OUTPUT #clear the OUTPUT chain
sudo iptables -t nat -F SS_TCP #clear the chain
sudo iptables -t nat -X SS_TCP #delete the chain
else
echo "没有输入参数"
fi
自己 添加 hook? 有例子吗?
# 列出ipset 已有IP
root@VM-0-9-ubuntu:~# ipset list
Name: gfwlist
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 600
References: 2
Number of entries: 4
Members:
151.101.0.133
151.101.128.133
151.101.192.133
151.101.64.133
# 更新gfwlist
root@VM-0-9-ubuntu:~# ss-tproxy update-gfwlist
# 更新完看 ipset 有没有新增IP,结果没有增加
root@VM-0-9-ubuntu:~# ipset list
Name: gfwlist
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 600
References: 2
Number of entries: 4
Members:
151.101.0.133
151.101.128.133
151.101.192.133
151.101.64.133
# 测试解析是否会自动添加到IPset
root@VM-0-9-ubuntu:~# nslookup -port=60053 google.com
Server: 127.0.0.1
Address: 127.0.0.1#60053
Non-authoritative answer:
Name: google.com
Address: 216.58.200.46
Name: google.com
Address: 2404:6800:4008:801::200e
# 结果也没有增加
root@VM-0-9-ubuntu:~# ipset list
Name: gfwlist
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 600
References: 2
Number of entries: 4
Members:
151.101.0.133
151.101.128.133
151.101.192.133
151.101.64.133
报文流向: LAN ----》 iptables-->ss-redir-->haproxy--》 ss-server,
但我发现,haproxy 收到的连接源IP都是本机了,这样就使用不了Haproxy的源IP 负载均衡策略了。
能指点一下有没有什么方法可以ss-redir向haproxy建链的时候,带上代理的真实的内网IP地址?
谢谢
昨天折腾了五六个小时…除了网速原因还有就是流程太繁琐了…
ss 不是编译安装还跑不起来…希望优化流程或者出 docker 版本吧,一个新机子,装个 docker 然后直 run 就能当一个网关,我想作者也是希望使用越来越方便的
我系统是ubuntu 18.01
运行命令 find /lib/modules/$(uname -r) -type f -name '*.ko*' | grep 'xt_TPROXY'
显示的是 /lib/modules/4.15.0-42-generic/kernel/net/netfilter/xt_TPROXY.ko
一键脚本就会报错
手动部署正常
创建/tmp/tproxy/resolv.conf 然后mount --bind /tmp/tproxy/resolv.conf /etc/resolv.conf
结束后umount /etc/resolv.conf
即可还原
在linux的软路由上,dnsmasq通常也会作为DHCP server ,其依赖于自带的配置文件/etc/dnsmasq.conf
中的配置。但由于ss-tproxy在启动dnsmasq时使用了-C
参数,其自带的配置文件/etc/dnsmasq.conf
不再会被加载,导致软路由失去了DHCP server的功能。
所以建议在启动dnsmasq的时候也一并加载一下/etc/dnsmasq.conf
,通常各大发行版默认的/etc/dnsmasq.conf
中全部都是注释,加载一下也不会对原有功能造成冲突。
稍微说明一下,他说的“桥接模式”是这样的,如下图:
ss-tproxy 运行在 bridge 服务器上,这个 bridge 服务器有两个网卡,一个连接出口路由,一个连接内网总线,然后将这两张网卡进行桥接,得到一个逻辑网卡,假设为 br0,br0 网卡通过 DHCP 方式获取路由器分配的 IP 地址信息,然后,这个 bridge 主机能够正常上外网,其它内网主机也能够正常上外网。
但默认情况下,ss-tproxy 并不能正常工作,需要进行几处改动,如下:
br_netfilter
内核模块:modprobe br_netfilter
# 网卡间转发
net.ipv4.ip_forward = 1
# 接收 localnet
net.ipv4.conf.all.route_localnet = 1
net.ipv4.conf.default.route_localnet = 1
# 2 层数据打到 3 层来
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-arptables = 1
proxy_tproxy='false'
、ipts_non_snat='true'
-j REDIRECT --to-ports $port
改为 -j DNAT --to-destination 127.0.0.1:$port
请到 README.md 里面查看,里面有关于桥接模式下的透明代理的详细说明
你好
我的操作系统是Ubuntu 18.04
今天貌似更新了下Systemd,ss-tproxy之前一直能用的自启服务突然失效了
systemctl status ss-tproxy
结果如下
● ss-tproxy.service - linux transparent proxy script
Loaded: loaded (/etc/systemd/system/ss-tproxy.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2019-02-03 21:04:12 CST; 49s ago
Process: 6393 ExecStart=/usr/local/bin/ss-tproxy start (code=exited, status=1/FAILURE)
Process: 6391 ExecStartPre=/bin/bash -c until ping -nq -c1 -W1 114.114.114.114 &>/dev/null; do :; done (code=exited, status=0/SUCCESS)
Main PID: 6393 (code=exited, status=1/FAILURE)
2月 03 21:04:12 username systemd[1]: Starting linux transparent proxy script...
2月 03 21:04:12 username ss-tproxy[6393]: [ERR]: Require command not found: 'chinadns'
2月 03 21:04:12 username systemd[1]: ss-tproxy.service: Main process exited, code=exited, status=1/FAILURE
2月 03 21:04:12 username systemd[1]: ss-tproxy.service: Failed with result 'exit-code'.
2月 03 21:04:12 username systemd[1]: Failed to start linux transparent proxy script.
可是我安装了ChinaDNS,ss-tproxy check-command
没有输出,单独使用ss-tproxy也正常
命令行键入chinadns结果如下
Sun Feb 3 21:16:18 2019 CHNROUTE_FILE not specified, CHNRoute is disabled
Sun Feb 3 21:16:18 2019 chinadns.c:554 bind: Permission denied
Sun Feb 3 21:16:18 2019 Can't bind address 0.0.0.0:53
使用的ssr 代理
ss-tproxy.conf 配置如下
启动之后
2018-11-12 15:28:05 ERROR: [udp] remote_recv_bind: Address already in use
2018-11-12 15:28:05 ERROR: [udp] remote_recv_bind: Address already in use
2018-11-12 15:28:05 ERROR: [udp] remote_recv_bind: Address already in use
这个是啥很么问题呢? 望解答,谢谢。
在debian 9.9 iptables v1.6.2下运行正常。在debian buster,iptables v1.8.2下启动则会报错。几个表不存在。
之前都没问题的,但最近发现dnsforwarder一启动就变僵尸进程了,不知道作者有没有碰到这个问题?
请问ssr配置域名时无法连接是什么问题?使用ip地址却很正常?
因为我代理服务器(.2)不在路由器(.1)上,我用iptables DNAT透明代理,结果发现DNAT会强行改remote ip。。。
于是我找到这个项目,但我在路由器上运行报错
首先,看了你的文章和脚本学习到很多,很感谢!
然后有一个小疑惑:我还是不太理解dnsforwarder在整个作用,搜索了一下,dnsforwarder是"将下游的 UDP 协议的 DNS 查询转换成 TCP 协议的 DNS 查询后发送到上游服务器"的作用。但是文中看起来,dnsforwarder好像只是一个DNS 缓存和加速的用途,这是不是可以用Dnsmasq来取代?用dnsforwarder把DNS查询转成TCP,再从本机的chinadns转出去,会不会多了一步?
在使用 tun2socks 模式下,Shadowsocks-mu-py拉取json报错 JSON ValueError: Expecting property name: line 1 column 2 (char 1)
而访问其他被墙网站都是正常的,请问这个是什么原因?
你好!我现在在openwrt路由器里面有个socks5的代理在运行,我想把它变成透明代理,但是这个代理只支持tcp,可以给我一份v2吗?谢谢!
Cannot run properly. Need Help.
$ sudo ss-tproxy restart
[sudo] paul 的密码:
ss-redir [stopped]
ss-tunnel [stopped]
chinadns [stopped]
dnsforwarder [stopped]
ss-redir [running]
ss-tunnel [running]
chinadns [running]
dnsforwarder [stopped]
// as ss-redir
{
"port": 60080,
"protocol": "dokodemo-door",
"settings": {
"network": "tcp,udp",
"followRedirect": true,
"domainOverride": ["quic"]
}
},
// as ss-tunnel
{
"port": 60053,
"protocol": "dokodemo-door",
"settings": {
"address": "8.8.8.8",
"port": 53,
"network": "udp",
"followRedirect": false
}
},
这个配置settings中漏了一个参数:"domainOverride": ["tls","http"],
dnsmasq: bad option at line 6 of /dev/fd/63
RTNETLINK answers: File exists
mount: warning: /etc/resolv.conf seems to be mounted read-write.
mode: tproxy_gfwlist
ssr-redir: [stopped]
ssr-tunnel: [stopped]
dnsmasq: [stopped]
第一 这个能不能直接安装在国内的服务器上,因为现在国内很多区域性的问题,这样用户通过VPN或SS连接国内的服务器,就充当了一级的网关的角色!
第二 有没有可以,将所有的dns的请求,全部转发到网关的53上,这样就不用管Client怎么设置dns,都可以正确使用了!
rt
这款软件能否支持goflyway呢
首先,感谢作者提供这样一个脚本,真的很方便。
我接下来的问题可能和脚本是无关的,但如果作者有时间的话大家可以一起探讨下。
环境介绍
服务器介绍
脚本使用Chnroute + SS方式,并且加了所有的服务器公网IP到Iptables表让他们不走ss-tproxy
proxy_tproxy='false' # 纯TPROXY方式
proxy_server='10.3.100.2' # 服务器的地址
proxy_tcport='60080' # TCP 监听端口
proxy_udport='60080' # UDP 监听端口
proxy_runcmd='(ss-redir -s 10.3.100.2 -p * -m * -k *-b 0.0.0.0 -l 60080 --no-delay --reuse-port -u -v </dev/null &>>/var/log/ss-redir.log &)' # 启动的命令行
proxy_kilcmd='kill -9 $(pidof ss-redir)' # 停止的命令
该模式使用正常,但是我将10.3.100.2换成10.3.101.1(同一台服务器)ss-tproxy就工作不正常。具体的log如下
cat chinadns.log
Fri Nov 23 00:49:33 2018 request ip.sb
Fri Nov 23 00:49:33 2018 request ip.sb
Fri Nov 23 00:49:33 2018 response ip.sb from 114.114.114.114:53 - 47.52.68.57, filter
Fri Nov 23 00:49:33 2018 response ip.sb from 114.114.114.114:53 - pass
Fri Nov 23 00:49:38 2018 request ip.sb
Fri Nov 23 00:49:38 2018 response ip.sb from 114.114.114.114:53 - 47.52.68.57, filter
Fri Nov 23 00:49:43 2018 request ip.sb
Fri Nov 23 00:49:43 2018 response ip.sb from 114.114.114.114:53 - Fri Nov 23 00:51:05 2018 request ip.sb
Fri Nov 23 00:51:05 2018 request ip.sb
Fri Nov 23 00:51:05 2018 response ip.sb from 114.114.114.114:53 - 47.52.68.57, filter
Fri Nov 23 00:51:05 2018 response ip.sb from 114.114.114.114:53 - pass
Fri Nov 23 00:51:10 2018 request ip.sb
Fri Nov 23 00:51:10 2018 response ip.sb from 114.114.114.114:53 - 47.52.68.57, filter
Fri Nov 23 00:51:15 2018 request ip.sb
Fri Nov 23 00:51:15 2018 response ip.sb from 114.114.114.114:53 - Fri Nov 23 00:59:51 2018 request ip.sb
Fri Nov 23 00:59:51 2018 request ip.sb
Fri Nov 23 00:59:51 2018 response ip.sb from 114.114.114.114:53 - 47.52.68.57, filter
Fri Nov 23 00:59:51 2018 response ip.sb from 114.114.114.114:53 - pass
Fri Nov 23 00:59:56 2018 request ip.sb
Fri Nov 23 00:59:56 2018 response ip.sb from 114.114.114.114:53 - 47.52.68.57, filter
Fri Nov 23 01:00:01 2018 request ip.sb
此时 德国服务器上并没有收到DNS请求。
2018-11-23 00:38:54 INFO: [udp] server receive a packet
2018-11-23 00:38:54 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:38:59 INFO: [udp] server receive a packet
2018-11-23 00:38:59 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:39:04 INFO: [udp] server receive a packet
2018-11-23 00:39:04 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:39:14 INFO: [udp] server receive a packet
2018-11-23 00:39:14 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:39:19 INFO: [udp] server receive a packet
2018-11-23 00:39:19 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:39:30 INFO: [udp] server receive a packet
2018-11-23 00:39:30 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:39:35 INFO: [udp] server receive a packet
2018-11-23 00:39:35 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:39:40 INFO: [udp] server receive a packet
2018-11-23 00:39:40 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:40:47 INFO: [udp] server receive a packet
2018-11-23 00:40:47 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:40:52 INFO: [udp] server receive a packet
2018-11-23 00:40:52 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:08 INFO: [udp] server receive a packet
2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:08 INFO: [udp] server receive a packet
2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:08 INFO: [udp] server receive a packet
2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:08 INFO: [udp] server receive a packet
2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:08 INFO: [udp] server receive a packet
2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:08 INFO: [udp] server receive a packet
2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:08 INFO: [udp] server receive a packet
2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:08 INFO: [udp] server receive a packet
2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:08 INFO: [udp] server receive a packet
2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:08 INFO: [udp] server receive a packet
2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:08 INFO: [udp] server receive a packet
2018-11-23 00:41:08 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:13 INFO: [udp] server receive a packet
2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:13 INFO: [udp] server receive a packet
2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:13 INFO: [udp] server receive a packet
2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:13 INFO: [udp] server receive a packet
2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:13 INFO: [udp] server receive a packet
2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:13 INFO: [udp] server receive a packet
2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:13 INFO: [udp] server receive a packet
2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:13 INFO: [udp] server receive a packet
2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:13 INFO: [udp] server receive a packet
2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:13 INFO: [udp] server receive a packet
2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
2018-11-23 00:41:13 INFO: [udp] server receive a packet
2018-11-23 00:41:13 INFO: [udp] cache hit: 8.8.8.8:53 <-> 172.17.25.255:34754
这是阿里云上的ss-redir的log。
How to write multiple servers, I try to follow the instruction, set 2 proxy server in configure file but it not working.
mode='global'
#mode='gfwlist'
#mode='chnroute'
proxy_tproxy='true' # 纯TPROXY方式
proxy_server=(a.net b.net) # 服务器的地址
proxy_tcport='1080' # TCP 监听端口
proxy_udport='1080' # UDP 监听端口
在PI上安装作为网关工作在主路由下
ChinaDNS国内DNS 设置为114.114.114.114 工作正常
修改为同一局域网下的自建DNS(AdGuardHome 单独使用正常)所有流量走代理
ip rule add fwmark 0x01/0x01 table 100
ip route add local 0.0.0.0/0 dev lo table 100
iptables -t mangle -N V2RAY
iptables -t mangle -I V2RAY -d 192.168.1.0/24 -j RETURN
iptables -t mangle -I V2RAY -d 127.0.0.1/32 -j RETURN
iptables -t mangle -A V2RAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 0x01/0x01
iptables -t mangle -A V2RAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 0x01/0x01
iptables -t mangle -A PREROUTING -j V2RAY
按照上面例子可以实现V2RAY TCP和UDP全部走tproxy,但是端口映射会失败。
我感觉好像所有流量去了TPROXY之后都送给了dokodemo-door才会这样,有没有什么办法不送某个端口流量给dokodemo-door.
我v2ray地址上的某个端口映射到了公网,用上面的例子无法成功映射。
求方法让私网映射端口工作正常。
Line 397 in ca6dcc8
iptables -t nat -F OUTPUT
iptables -t nat -F PREROUTING
iptables -t mangle -F OUTPUT
iptables -t mangle -F PREROUTING
如果原来有规则的话,会被这几个指令清掉吧?是不是自己 new 一条链比较好?
大概看了下脚本,tproxy应该是全部端口转发了吧,有时候只需要转发制定的端口就够了。
最近入了台软路由,打算直接上Arch Linux当路由,到时候ss-tproxy可能会派上用场,嘿嘿。
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.