Closed fengqi closed 2 years ago
inbound打开sniffing完事,不用折腾dns,最后发出去的是域名,到达服务器后再解析。
inbound打开sniffing完事,不用折腾dns,最后发出去的是域名,到达服务器后再解析。
sniffing 我开了,我看到日志有输出,accepted tcp:8.8.8.8:53 [hk],所以应该是走了hk吧
"inbounds": [
{
"listen": "0.0.0.0",
"port": "1089",
"protocol": "socks",
"settings": {
"udp": true,
"ip": "192.168.1.100"
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls"
],
"metadataOnly": false,
"routeOnly": true
}
}
],
不用管dns走了哪里,最后发给服务器的是域名,都会在服务器端重新解析。
不用管dns走了哪里,最后发给服务器的是域名,都会在服务器端重新解析。
我的使用场景是网关使用iptables+gfwlist+ipt2socks把流量导到xray客户端再分流的,DNS解析在网关就完成了,xray实际收到的请求是ip+端口,因为开启来流量探测所以能能分流
但是我通过tcpdump在hk和us分别抓包查看,us上并没有dns发出去的包,hk上有
客户端xray配置你写域名探测的参数没?写了 发给vps端是域名,不写,发到vps的是在你客户端dns解析到的ip。
或者客户端不写,在接收的vps配置写域名嗅探参数,xray收到也是域名了
不用管dns走了哪里,最后发给服务器的是域名,都会在服务器端重新解析。
我的使用场景是网关使用iptables+gfwlist+ipt2socks把流量导到xray客户端再分流的,DNS解析在网关就完成了,xray实际收到的请求是ip+端口,我通过tcpdump在hk和us分别抓包查看,us上并没有dns发出去的包,hk上有
打开sniffing以后会重写流量目的地,把ip换成域名。你看us机xray的日志,你客户端打开了sniffing,us机收到的应该就是域名。
话说为啥不直接tproxy入站,还要多过一层ipt2socks。
看你才发iss就想问你客户端应该是透明代理 你也不没说清楚,后来说了详细情况。建议你开日志 debug看就知道了
客户端xray配置你写域名探测的参数没?写了 发给vps端是域名,不写,发到vps的是在你客户端dns解析到的ip。
或者客户端不写,在接收的vps配置写域名嗅探参数,xray收到也是域名了
域名探测的参数是指routeOnly吗,你看下2楼我贴的sniffing
客户端xray配置你写域名探测的参数没?写了 发给vps端是域名,不写,发到vps的是在你客户端dns解析到的ip。
或者客户端不写,在接收的vps配置写域名嗅探参数,xray收到也是域名了
是指routeOnly吗,我开了以后,在hk和us都能抓到dns请求了,等于解析了两次,一次是网关,一次是xray
客户端xray配置你写域名探测的参数没?写了 发给vps端是域名,不写,发到vps的是在你客户端dns解析到的ip。 或者客户端不写,在接收的vps配置写域名嗅探参数,xray收到也是域名了
域名探测的参数是指routeOnly吗,你看下2楼我贴的sniffing
客户端xray配置你写域名探测的参数没?写了 发给vps端是域名,不写,发到vps的是在你客户端dns解析到的ip。 或者客户端不写,在接收的vps配置写域名嗅探参数,xray收到也是域名了
是指routeOnly吗,我开了以后,在hk和us都能抓到dns请求了,等于解析了两次,一次是网关,一次是xray
不是路由only开它 传给vps的是你本地dns解析后的ip
你不如帖个你客户端xray配置,不然我们对空气分析
还帖你中转机的xray配置
不用管dns走了哪里,最后发给服务器的是域名,都会在服务器端重新解析。
我的使用场景是网关使用iptables+gfwlist+ipt2socks把流量导到xray客户端再分流的,DNS解析在网关就完成了,xray实际收到的请求是ip+端口,我通过tcpdump在hk和us分别抓包查看,us上并没有dns发出去的包,hk上有
打开sniffing以后会重写流量目的地,把ip换成域名。你看us机xray的日志,你客户端打开了sniffing,us机收到的应该就是域名。
话说为啥不直接tproxy入站,还要多过一层ipt2socks。
因为之前一直跑的隧道加速原始trojan,再在hk上wg转到us的,现在全直连,就尝试分流了
你不如帖个你客户端xray配置,不然我们对空气分析
还帖你中转机的xray配置
完整配置我补充在主贴了
你说这些没实质作用,不帖你配置真是靠猜,说完只能靠你自己研究。或去xraytg问网友,看有人好心帮忙不
你1楼看了下猜是中转机 我上面是说你帖个客户端的xray
说错了我再看看1楼
看了1楼你编辑记录,我就记得当时看是只有中转机配置,你修改了。你改好嘛。。。写清楚客户端 中转机。。。
你1楼看了下猜是中转机 我上面是说你帖个客户端的xray
说错了我再看看1楼
看了1楼你编辑记录,我就记得当时看是只有中转机配置,你修改了。你改好嘛。。。写清楚客户端 中转机。。。
改好了,主贴的配置是客户端,本地局域网的设备,全部设备是:1网关,2内网机器,3hk机器,4us机器
看了1楼客户端配置,没发现有什么问题,开了域名嗅探的,你现在是什么问题。要帮你分析,你得帖下客户端或中转机的日志。开debug,比如测下访问netflix。你如果看不懂日志,就帖上来看有网友帮忙分析不。
客户端这么写没问题,dns部分不用分流,反正到了US鸡还要重新解析,用HK鸡解析应该还快点。
现在有个问题是 DNS 全部走 hk 隧道了,虽然最终的请求走 us,但这应该达不到最好的效果,我想要的效果是 DNS 和请求都都分别走 hk 和 us。
你如果是问这个,你是透明代理模式,DNS解析,是你自己设置怎么处理的。你客户端配置也不是把DNS流量引入到Xray来处理(没写 ,没看到你有Xray配置处理透明代理DNS流量那些代码)
所以我只说建议你看看你透明代理DNS你怎么处理的(我也不懂这方面的技术了)
我现在开启了routeOnly,算是解决问题了,因为假定4个8是就近返回,现在us上又解析了一次。
我的DNS是网关iptables开了劫持,然后使用 dns2socks 导入到xray的inbounds里来
因为不是所有的客户端都支持udp+tcp和tproxy,以及网关性能弱鸡,所以我暂定的方案是都转发到内网nas的socks上
完美状态是:走us流量的dns只走us不过hk,这就需要dns也能被路由
Xray自身可以实现类似dnscrypt的效果,即通过VPS解析DNS。 使用dokodemo-door入站协议、dns出站协议、内部DNS分流就能实现VPS端解析DNS。
{
"inbounds": [
{
"tag": "dns-hk",
"protocol": "dokodemo-door",
"port": 8054,
"settings": {
"address": "8.8.8.8",
"port": 53,
"network": "tcp,udp"
}
},
{
"tag": "dns-us",
"protocol": "dokodemo-door",
"port": 8055,
"settings": {
"address": "8.8.8.8",
"port": 53,
"network": "tcp,udp"
}
},
{
"tag": "tproxy-in",
"protocol": "dokodemo-door",
"port": 8090,
"settings": {
"network": "tcp,udp",
"followRedirect": true
},
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls", "quic"]
},
"streamSettings": {
"sockopt": {
"tproxy": "tproxy"
}
}
}
],
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"streamSettings": {
"sockopt": { "mark": 255 }
}
},
{
"tag": "dns-fwd",
"protocol": "dns",
"streamSettings": {
"sockopt": { "mark": 255 }
}
},
{
"tag": "block",
"protocol": "blackhole",
"streamSettings": {
"sockopt": { "mark": 255 }
}
}
],
"dns": {
"tag": "dns-query",
"servers": [
"223.5.5.5",
{
"address": "127.0.0.1",
"port": 8054,
"domains": ["domain:hk"]
},{
"address": "127.0.0.1",
"port": 8055,
"domains": ["geosite:greatfire", "geosite:gfw"]
}
]
},
"routing": {
"rules": [
{
"type": "field",
"inboundTag": ["dns-query"],
"outboundTag": "direct"
},
{
"type": "field",
"inboundTag": ["tproxy-in"],
"network": "udp",
"port": 53,
"outboundTag": "dns-fwd"
},
{
"type": "field",
"inboundTag": ["dns-hk"],
"outboundTag": "proxy-hk"
},
{
"type": "field",
"inboundTag": ["dns-us"],
"outboundTag": "proxy-us"
},
{
"type": "field",
"inboundTag": ["tproxy-in"],
"domains": ["domain:hk"],
"outboundTag": "proxy-hk"
},
{
"type": "field",
"inboundTag": ["tproxy-in"],
"domains": ["geosite:gfw", "geosite:greatfire"],
"outboundTag": "proxy-us"
}
]
}
}
@azzvx 这跟我的架构不太一样,你这种配置是需要xray接管全部流量,再做直连或者分流?
我用的是iptables+dnsmasq+gfwlist+ipset做的分流,把需要加速的流量转为socks导入到xray,我稍后尝试下把tproxy和dns直接导入到xray看看,因为xray运行在局域网的一台机器上,而不是在网关,所以不确定能不能成功。
@azzvx 这跟我的架构不太一样,你这种配置是需要xray接管全部流量,再做直连或者分流?
我用的是iptables+dnsmasq+gfwlist+ipset做的分流,把需要加速的流量转为socks导入到xray,我稍后尝试下把tproxy和dns直接导入到xray看看,因为xray运行在局域网的一台机器上,而不是在网关,所以不确定能不能成功。
上面的配置是简化版的,我的直连在iptables/nftables就做好了。另外你可以把tproxy-in改成socks-in,原理是一样的。 如果你想直接把xray当成dnsmasq的上游,还可以加下面的配置,然后dnsmasq设置转发[XrayIP#8053]
{
"inbounds": [
{
"tag": "dns-in",
"protocol": "dokodemo-door",
"port": 8053,
"settings": {
"address": "114.114.114.114",
"port": 53,
"network": "tcp,udp"
}
}
],
"outbounds": [
{
"tag": "dns-fwd",
"protocol": "dns",
"streamSettings": {
"sockopt": { "mark": 255 }
}
}
],
"routing": {
"rules": [
{
"type": "field",
"inboundTag": ["dns-in"],
"outboundTag": "dns-fwd"
}
]
}
}
@azzvx 这跟我的架构不太一样,你这种配置是需要xray接管全部流量,再做直连或者分流? 我用的是iptables+dnsmasq+gfwlist+ipset做的分流,把需要加速的流量转为socks导入到xray,我稍后尝试下把tproxy和dns直接导入到xray看看,因为xray运行在局域网的一台机器上,而不是在网关,所以不确定能不能成功。
上面的配置是简化版的,我的直连在iptables/nftables就做好了。另外你可以把tproxy-in改成socks-in,原理是一样的。 如果你想直接把xray当成dnsmasq的上游,还可以加下面的配置,然后dnsmasq设置转发[XrayIP#8053]
{ "inbounds": [ { "tag": "dns-in", "protocol": "dokodemo-door", "port": 8053, "settings": { "address": "114.114.114.114", "port": 53, "network": "tcp,udp" } } ], "outbounds": [ { "tag": "dns-fwd", "protocol": "dns", "streamSettings": { "sockopt": { "mark": 255 } } } ], "routing": { "rules": [ { "type": "field", "inboundTag": ["dns-in"], "outboundTag": "dns-fwd" } ] } }
恩,你帖的配置我能看懂,我总结下我的问题应该是dns分流不生效所以被迫解析两次dns,dnsmasq直接转到xray我倒是没想到的, 我的dns现在是 iptables->dnsmasq->dns2socks->xray socks-in,挺绕的,我试试直接转过来会不会起效果
恩,你帖的配置我能看懂,我总结下我的问题应该是dns分流不生效所以被迫解析两次dns,dnsmasq直接转到xray我倒是没想到的, 我的dns现在是 iptables->dnsmasq->dns2socks->xray socks-in,挺绕的,我试试直接转过来会不会起效果
你的DNS这么复杂的么?我现在就dnsmasq(广告过滤) -> xray(dns分流) -> smartdns(国内dns解析) + vps(国外dns解析) 另外按你这种做法,直接iptables做端口转发,把dns查询转到xray就成了啊。
恩,你帖的配置我能看懂,我总结下我的问题应该是dns分流不生效所以被迫解析两次dns,dnsmasq直接转到xray我倒是没想到的, 我的dns现在是 iptables->dnsmasq->dns2socks->xray socks-in,挺绕的,我试试直接转过来会不会起效果
你的DNS这么复杂的么?我现在就dnsmasq(广告过滤) -> xray(dns分流) -> smartdns(国内dns解析) + vps(国外dns解析) 另外按你这种做法,直接iptables做端口转发,把dns查询转到xray就成了啊。
对,之前是没有xray分流和dns分流这一环的,只有一个trojan client socks-in直通hk,我现在调整下看看, 其实之前的完整的架构应该是 网关:iptables->dnsmasq国外->dns2socks-> 局域网机器1:xray socks-in->us/hk,调整后 网关:iptables->dnsmasq国外-> 局域网机器1:xray dns-in -> us/hk 网关:iptables->dnsmasq其他-> 局域网机器2:adguard home -> direct
之前看起来比较复杂,是因为把除gfwlist以外的算力全部转移出去了,不过链路没选择好。
这种方式不知道为啥不生效,流量是从socks-in和hk/us-dns-in进来的
"dns": {
"tag": "dns-query",
"servers": [
"223.5.5.5",
{
"address": "127.0.0.1",
"port": 8054,
"domains": ["domain:hk"]
},{
"address": "127.0.0.1",
"port": 8055,
"domains": ["geosite:greatfire", "geosite:gfw"]
}
]
},
我现在改成了在网关的dnsmasq上用了两个conf文件分别转发到hk/us-dns-in,然后xray再开流量嗅探分流,抓包看到只有一次dns请求,就是dnsmasq那边稍微麻烦了一些
{
"log": {
"loglevel": "warning",
"dnsLog": true
},
"inbounds": [
{
"tag": "socks-in",
"listen": "0.0.0.0",
"port": "1089",
"protocol": "socks",
"settings": {
"udp": true,
"ip": "192.168.1.8"
},
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls"],
"routeOnly": true
}
},
{
"tag": "dns-hk-in",
"protocol": "dokodemo-door",
"port": 5301,
"settings": {
"address": "8.8.8.8",
"port": 53,
"network": "tcp,udp"
}
},
{
"tag": "dns-us-in",
"protocol": "dokodemo-door",
"port": 5302,
"settings": {
"address": "8.8.8.8",
"port": 53,
"network": "tcp,udp"
}
}
],
"outbounds": [
{
"tag": "us",
"protocol": "trojan",
},
{
"tag": "hk",
"protocol": "trojan",
}
],
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"inboundTag": ["dns-hk-in"],
"outboundTag": "hk"
},
{
"type": "field",
"inboundTag": ["dns-us-in"],
"outboundTag": "us"
},
{
"type": "field",
"outboundTag": "us",
"domain": [
"geosite:google",
"geosite:netflix",
"geosite:spotify"
]
},
{
"type": "field",
"outboundTag": "hk",
"network": "udp,tcp"
}
]
}
}
"outbounds": [
{
"tag": "dns-fwd",
"protocol": "dns",
"streamSettings": {
"sockopt": { "mark": 255 }
}
}
],
这个出站代理很重要,是用来拦截DNS查询到内置DNS服务器用的,只有路由到这个了,Xray才会用内置DNS服务器进行分流。 dns-in -> 路由 -> dns-fwd -> 内置DNS服务器分流 -> 出站
不论你的DNS查询从哪里入站的,只要路由到DNS出站协议了,都会交给Xray内置DNS服务器处理。
再说说Xray啥时候使用内置DNS服务器吧: 1.当dns查询路由到dns出站协议的时候 2.路由domainStrategy为IPIfNonMatch或IPOnDemand时,需要匹配IP的时候 3.freedom出站协议的domainStrategy为UseIP、UseIPv4或UseIPv6时,对外发出的连接使用内部DNS解析的结果 也就是外部dns查询路由到dns出站协议的时候,xray可以当成一个带分流功能的dns服务器使用
然后讲讲上面的dns-in,dns-fwd,dns-hk,dns-us,内置dns服务器,这些东西究竟是怎么工作的。
假设你打了个nslookup www.jd.hk 223.5.5.5
1.你的iptables把这个查询转发给了dnsmasq(原来的查询地址223.5.5.5被丢弃了),dnsmasq又把这个这个请求转发给xray
2.xray的dns-in接受了这个请求,因为dns-in是个任意门,你可以把它当成一个端口转发,你设置地址是114.114.114.114,这时候你dns的查询服务器就成了114.114.114.114
3.请求进入路由,dns-in被路由到了dns-fwd,查询被内置dns服务器接受,开始dns分流
4.因为你的域名www.jd.hk匹配domain:hk的规则,dns查询被转发到127.0.0.1:8054,即dns-hk,dns查询的地址就重写成了8.8.8.8
5.dns-hk的查询进入路由,路由到proxy-hk,那么就会通过hk的vps向8.8.8.8查询www.jd.hk的ip并返回结果
假设不路由dns-in到dns-fwd,那么nslookup www.jd.hk 223.5.5.5
实质上会变成nslookup www.jd.hk 114.114.114.114
假设路由dns-in到proxy-hk,所有dns查询都会通过hk的vps查询,服务器是114.114.114.114,相当于通过xray实现了dnscrypt的功能,此时的查询结果符合hk vps的网络环境,你还可以在内置dns的服务器那里设置clientIP为pppoe网关ip来保证查询的结果符合你本地的网络环境(如果你在dns-in设置的服务器ip支持edns)
你应该留个tg,他来单独请教你
你应该留个tg,他来单独请教你
终于搞定了,有个地方没绕过来,就是让入站的dns进路由,我现在是通过5300入站,routing里面设置到dns-fwd来开启dns路由,然后路由到hk或者us。 还有坑的地方是,dns的规则是domains,routing里面是domain。
{
"log": {
"loglevel": "warning",
"dnsLog": true
},
"inbounds": [
{
"tag": "socks-in",
"listen": "0.0.0.0",
"port": "1089",
"protocol": "socks",
"settings": {
"udp": true,
"ip": "192.168.1.8"
},
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls"],
"routeOnly": true
}
},
{
"tag": "dns-in",
"protocol": "dokodemo-door",
"port": 5300,
"settings": {
"address": "8.8.8.8",
"port": 53,
"network": "tcp,udp"
}
},
{
"tag": "dns-hk-in",
"protocol": "dokodemo-door",
"port": 5301,
"settings": {
"address": "8.8.8.8",
"port": 53,
"network": "tcp,udp"
}
},
{
"tag": "dns-us-in",
"protocol": "dokodemo-door",
"port": 5302,
"settings": {
"address": "8.8.8.8",
"port": 53,
"network": "tcp,udp"
}
}
],
"outbounds": [
{
"tag": "direct",
"protocol": "freedom"
},
{
"tag": "dns-fwd",
"protocol": "dns"
},
{
"tag": "trojan-us",
"protocol": "trojan",
},
{
"tag": "trojan-hk",
"protocol": "trojan",
}
],
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"inboundTag": ["dns-query"],
"outboundTag": "direct"
},
{
"type": "field",
"inboundTag": ["dns-in"],
"network": "udp",
"port": 53,
"outboundTag": "dns-fwd"
},
{
"type": "field",
"inboundTag": ["dns-hk-in"],
"outboundTag": "trojan-hk"
},
{
"type": "field",
"inboundTag": ["dns-us-in"],
"outboundTag": "trojan-us"
},
{
"type": "field",
"inboundTag": ["socks-in"],
"outboundTag": "trojan-us",
"domain": [
"geosite:google",
"geosite:netflix",
"geosite:spotify"
]
},
{
"type": "field",
"inboundTag": ["socks-in"],
"outboundTag": "trojan-hk",
"network": "udp,tcp"
}
]
},
"dns": {
"tag": "dns-query",
"queryStrategy": "UseIPv4",
"servers": [
{
"address": "127.0.0.1",
"port": 5301
},
{
"address": "127.0.0.1",
"port": 5302,
"domains": [
"geosite:google",
"geosite:netflix",
"geosite:spotify"
]
}
]
}
}
现有 hk 和 us 两台机器,Netflix、Spotify 等流媒体通过规则走的 us 隧道,其他的域名走 hk 隧道,
现在有个问题是 DNS 全部走 hk 隧道了,虽然最终的请求走 us,但这应该达不到最好的效果,我想要的效果是 DNS 和请求都都分别走 hk 和 us。
我尝试这么配,貌似不起效果