Clash: Vários problemas do modo IP falso como um proxy de gateway

Criado em 12 mai. 2019  ·  17Comentários  ·  Fonte: Dreamacro/clash

  1. Atualmente, o Clash não responde a pacotes ICMP de ip falso, o que pode causar comportamento inesperado de alguns aplicativos
  2. 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)

Todos 17 comentários

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:

  1. Para nomes de domínio que requerem proxy, retorne ip falso
  2. 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ário

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:

  1. Para nomes de domínio que requerem proxy, retorne ip falso
  2. 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ário

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.

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?

  1. Atualmente, o Clash não responde a pacotes ICMP de ip falso, o que pode causar comportamento inesperado de alguns aplicativos
  2. 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:

  1. Para nomes de domínio que requerem proxy, retorne ip falso
  2. 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ário

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.

Espero que os desenvolvedores possam considerar esses novos recursos, mas ainda parece impossível fazê-lo.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

OneHappyForever picture OneHappyForever  ·  3Comentários

dazirangege picture dazirangege  ·  3Comentários

ingjieye picture ingjieye  ·  6Comentários

Anankke picture Anankke  ·  5Comentários

FenghenHome picture FenghenHome  ·  6Comentários