O modo TUN resolverá esses dois problemas
Eu gostaria de perguntar, eu agora uso o clash como um proxy transparente no roteador e espero usar o ip falso. Posso usar o modo TUN? Em caso afirmativo, posso compartilhar algumas informações de configuração?
Espero usar ip falso (em comparação com redirecion-host) porque acho que é mais razoável. No momento, quase todas as situações funcionam bem. O único problema é que a conexão falha quando a detecção do King Glory atrasa. Acho que é porque udp usa falso. problema de ip, então eu gostaria de perguntar.
Muito obrigado.
O TUN ainda não foi implementado. Minha prática atual é usar fakeip sem UDP e usar redirecion-host (ou seja, abrir duas instâncias do Clash).
No sábado, 27 de julho de 2019 às 2h43, AylinZhao [email protected] escreveu:
Eu gostaria de perguntar, eu uso o clash como um proxy transparente no roteador e espero usar o ip falso, posso usar o modo TUN? Em caso afirmativo, posso compartilhar algumas informações de configuração?
Quer usar fake
O motivo do ip (comparado ao redirecion-host) é que ele é mais razoável. No momento, quase todas as situações estão funcionando bem. O único problema é que a conexão não pode ser conectada quando a detecção do rei da glória está atrasada. Acho que é porque o udp usa fake
problema de ip, então eu gostaria de perguntar.Muito obrigado.
-
Você está recebendo isso porque é o autor do tópico.Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Dreamacro/clash/issues/179?email_source=notifications&email_token=AB6FI752JQQZPMZBH4KYEHLQBNAWRA5CNFSM4HMJDBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBH4KYEHLQBNAWRA5CNFSM4HMJDBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBH4KYEHLQBNAWRA5CNFSM5
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AB6FI7YKTOA2BX525XOUELLQBNAWRANCNFSM4HMJDBCQ
.
@BirkhoffLee Obrigado, essa ideia é muito boa, posso desviar para diferentes instâncias através do iptables?Se sim, você pode compartilhar o método de desvio
@BirkhoffLee Obrigado, essa ideia é muito boa, posso desviar para diferentes instâncias através do iptables?Se sim, você pode compartilhar o método de desvio
O mesmo método que uma instância, mas dois iptables DNAT:
# 到 fake ip range 的 tcp 全部轉發到 clash fakeip
iptables -t nat -A clash_lan -p tcp -d 198.18.0.0/16 -j DNAT --to-destination 10.0.1.6:23456
# 其他 tcp 80/443 全部轉發到 clash redirhost
iptables -t nat -A clash_lan \! -d 198.18.0.0/16 -p tcp --dport 80 -j DNAT --to-destination 10.0.1.6:9999
iptables -t nat -A clash_lan \! -d 198.18.0.0/16 -p tcp --dport 443 -j DNAT --to-destination 10.0.1.6:9999
iptables -t nat -A PREROUTING -p tcp -j clash_lan
Além disso, DNS falso inventado por Sukka
iptables -t nat -N clash_fakedns
iptables -t nat -A clash_fakedns -p udp --dport 53 -j DNAT --to-destination 10.0.1.6:23453
iptables -t nat -A clash_fakedns -p tcp --dport 53 -j DNAT --to-destination 10.0.1.6:23453
iptables -t nat -A PREROUTING -p udp -d 198.19.0.0/24 -j clash_fakedns
iptables -t nat -A PREROUTING -p tcp -d 198.19.0.0/24 -j clash_fakedns
Desta forma, o dispositivo que precisa do Fake IP pode alterar o DNS para 198.19.0.1.
EDIT: CIDR de IP falso corrigido
Obrigado por compartilhar. Eu entendo que isso é para implementar estratégias de resolução diferentes, definindo dns diferentes para dispositivos diferentes.
Minha situação atual é que sob a condição de que o roteador esteja configurado com um proxy transparente, algum tráfego udp (o teste de atraso King Honor) do mesmo dispositivo (meu celular) espera ser tratado corretamente, não sei se há como.
A solução preferida é que tudo seja feito no roteador e seja transparente para todos os dispositivos.
Obrigado por compartilhar. Eu entendo que isso é para implementar estratégias de resolução diferentes, definindo dns diferentes para dispositivos diferentes.
Minha situação atual é que sob a condição de que o roteador esteja configurado com um proxy transparente, algum tráfego udp (o teste de atraso King Honor) do mesmo dispositivo (meu celular) espera ser tratado corretamente, não sei se há como.
A solução preferida é que tudo seja feito no roteador e seja transparente para todos os dispositivos.
Ainda não
Entenda obrigado novamente
Você pode considerar esse modelo falso-ip-proxy-only:
Dessa forma, consultas desnecessárias de DNS ainda não são geradas para nomes de domínio que precisam ser proxy.
Para o segmento de ip que precisa de um proxy, o tempo para iniciar uma conexão é o mesmo.
Para outras situações, IP real é necessário.
Não sei se meu entendimento do processo está correto, corrija-me.
Você pode considerar esse modelo falso-ip-proxy-only:
- Para nomes de domínio que requerem proxy, retorne ip falso
- Para outros nomes de domínio, o ip real sempre será retornado
2.1 Se houver uma regra de nome de domínio que defina a conexão direta, o IP real é necessário
2.2 Para o segmento de ip que requer proxy (regras geográficas), ele também precisa consultar primeiro o ip real e, em seguida, comparar o banco de dados geográfico e, em seguida, iniciar uma conexão
2.3 Para os demais segmentos de ip conectados diretamente, o ip real também é necessárioDessa forma, consultas desnecessárias de DNS ainda não são geradas para nomes de domínio que precisam ser proxy.
Para o segmento de ip que precisa de um proxy, o tempo para iniciar uma conexão é o mesmo.
Para outras situações, IP real é necessário.Não sei se meu entendimento do processo está correto, corrija-me.
Somente o retorno do ip falso é realizado no nome de domínio a ser proxy nas regras, e os demais retornam ip real?
@beyondkmp sim
@BirkhoffLee Obrigado, essa ideia é muito boa, posso desviar para diferentes instâncias através do iptables?Se sim, você pode compartilhar o método de desvio
O mesmo método que uma instância, mas dois iptables DNAT:
# 到 fake ip range 的 tcp 全部轉發到 clash fakeip iptables -t nat -A clash_lan -p tcp -d 198.18.0.0/16 -j DNAT --to-destination 10.0.1.6:23456 # 其他 tcp 80/443 全部轉發到 clash redirhost iptables -t nat -A clash_lan \! -d 198.18.0.0/16 -p tcp --dport 80 -j DNAT --to-destination 10.0.1.6:9999 iptables -t nat -A clash_lan \! -d 198.18.0.0/16 -p tcp --dport 443 -j DNAT --to-destination 10.0.1.6:9999 iptables -t nat -A PREROUTING -p tcp -j clash_lan
Além disso, DNS falso inventado por Sukka
iptables -t nat -N clash_fakedns iptables -t nat -A clash_fakedns -p udp --dport 53 -j DNAT --to-destination 10.0.1.6:23453 iptables -t nat -A clash_fakedns -p tcp --dport 53 -j DNAT --to-destination 10.0.1.6:23453 iptables -t nat -A PREROUTING -p udp -d 198.19.0.0/24 -j clash_fakedns iptables -t nat -A PREROUTING -p tcp -d 198.19.0.0/24 -j clash_fakedns
Desta forma, o dispositivo que precisa do Fake IP pode alterar o DNS para 198.19.0.1.
EDIT: CIDR de IP falso corrigido
Seu método é bom, eu quero experimentar, posso perguntar,
Como abrir 2 instâncias do Clash? Uma das portas proxy está definida para 9999?
- Atualmente, o Clash não responde a pacotes ICMP de ip falso, o que pode causar comportamento inesperado de alguns aplicativos
- Como o IP falso é usado e o Clash ainda não tem a capacidade de encaminhar UDP, alguns aplicativos UDP tentarão se conectar ao ip falso e falharão (por exemplo, TeamSpeak)
https://github.com/vernesong/OpenClash/releases/tag/v0.33.7-beta
O Openclash versão 0.33.7 fornece uma solução estabelecendo uma lista de nomes de domínio para permitir que nomes de domínio específicos usem DNS específicos.
https://github.com/Dreamacro/clash/releases/tag/TUN Você pode tentar o binário TUN experimental
Esse mecanismo de fakeip é tão complicado que não é mais conveniente descompactar diretamente e obter o host como o v2ray.
No modo de ip falso, o JMGO Cloud não consegue se conectar à Internet
Você pode considerar esse modelo falso-ip-proxy-only:
- Para nomes de domínio que requerem proxy, retorne ip falso
- Para outros nomes de domínio, o ip real sempre será retornado
2.1 Se houver uma regra de nome de domínio que defina a conexão direta, o IP real é necessário
2.2 Para o segmento de ip que requer proxy (regras geográficas), ele também precisa consultar primeiro o ip real e, em seguida, comparar o banco de dados geográfico e, em seguida, iniciar uma conexão
2.3 Para os demais segmentos de ip conectados diretamente, o ip real também é necessárioDessa forma, consultas desnecessárias de DNS ainda não são geradas para nomes de domínio que precisam ser proxy.
Para o segmento de ip que precisa de um proxy, o tempo para iniciar uma conexão é o mesmo.
Para outras situações, IP real é necessário.Não sei se meu entendimento do processo está correto, corrija-me.
Espero que os desenvolvedores possam considerar esses novos recursos, mas ainda parece impossível fazê-lo.