Clash: Plusieurs problèmes de mode Fake IP en tant que proxy de passerelle

Le mode TUN résoudra ces deux problèmes

Je voudrais demander, j'utilise clash comme proxy transparent sur le routeur et j'espère utiliser fake-ip, puis-je utiliser le mode TUN? Si oui, puis-je partager des informations de configuration?

J'espère utiliser une fausse adresse IP (par rapport à redir-host) car je pense que c'est plus raisonnable. À l'heure actuelle, presque toutes les situations fonctionnent bien. Le seul problème est que la connexion échoue lorsque la détection de King Glory est retardée. Je suppose que c'est parce que udp utilise un faux. problème IP, alors je voudrais demander.

Merci beaucoup.

TUN n'a pas encore été implémenté. Ma pratique actuelle est de prendre fakeip sans UDP et de prendre redir-host si nécessaire (c'est-à-dire ouvrir deux instances Clash)

Le samedi 27 juillet 2019 à 02:43, AylinZhao [email protected] a écrit:

Je voudrais demander, j'utilise maintenant clash comme proxy transparent sur le routeur et j'espère utiliser fake-ip. Puis-je utiliser le mode TUN? Si oui, puis-je partager des informations de configuration?

Vous voulez utiliser de faux
La raison d'ip (par rapport à redir-host) est qu'il est plus raisonnable. À l'heure actuelle, presque toutes les situations fonctionnent bien. Le seul problème est que la connexion échoue lorsque la détection du roi de gloire est retardée. Je suppose que c'est parce que udp utilise un faux
problème IP, donc je veux demander.

Merci beaucoup.

-
Vous recevez ceci parce que vous avez créé le fil.

Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/Dreamacro/clash/issues/179?email_source=notifications&email_token=AB6FI752JQQZPMZBH4KYEHLQBNAWRA5CNFSM4HMJDBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBW63LNMVXHJK25MZBH4KYEHLQBNAWRA5CNFSM4HMJDBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBH4KYEHLQBNAWRA5CNFSM5
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AB6FI7YKTOA2BX525XOUELLQBNAWRANCNFSM4HMJDBCQ
.

@BirkhoffLee Merci, cette idée est très bonne, puis-je détourner vers différentes instances via iptables?Si oui, pouvez-vous partager la méthode de détournement

@BirkhoffLee Merci, cette idée est très bonne, puis-je détourner vers différentes instances via iptables?Si oui, pouvez-vous partager la méthode de détournement

La même méthode qu'une instance, mais deux DNAT iptables:

# 到 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

Plus un faux DNS inventé par 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

De cette façon, les appareils qui nécessitent une Fake IP peuvent changer le DNS en 198.19.0.1.

EDIT: Correction d'un faux CIDR IP

Merci d'avoir partagé. Je comprends que cela consiste à atteindre différentes stratégies de résolution en définissant différents DNS pour différents appareils.

Ma situation actuelle est que sous la condition que le routeur soit configuré avec un proxy transparent, une partie du trafic udp du même appareil (mon téléphone portable) (le test de délai King of Honor) espère être traité correctement, je ne sais pas s'il existe un moyen.

La solution préférée est que tout est fait sur le routeur et transparent pour tous les appareils.

Merci d'avoir partagé. Je comprends que cela consiste à atteindre différentes stratégies de résolution en définissant différents DNS pour différents appareils.

Ma situation actuelle est que sous la condition que le routeur soit configuré avec un proxy transparent, une partie du trafic udp du même appareil (mon téléphone portable) (le test de délai King of Honor) espère être traité correctement, je ne sais pas s'il existe un moyen.

La solution préférée est que tout est fait sur le routeur et transparent pour tous les appareils.

Pas encore

Comprenez, merci encore

Pouvez-vous considérer un tel modèle comme un faux-ip-proxy-only:

1. Pour les noms de domaine qui nécessitent un proxy, renvoyez une fausse adresse IP
2. Pour les autres noms de domaine, la vraie adresse IP sera toujours retournée
   2.1 S'il existe une règle de nom de domaine qui définit la connexion directe, une adresse IP réelle est requise
   2.2 Pour le segment IP qui nécessite un proxy (règles géographiques), il doit également interroger d'abord l'adresse IP réelle, puis comparer la base de données géographique, puis établir une connexion
   2.3 Pour les segments IP directement connectés restants, une adresse IP réelle est également requise

De cette manière, les requêtes DNS inutiles ne sont toujours pas générées pour les noms de domaine qui nécessitent un proxy.
Pour le segment IP qui a besoin d'un proxy, le temps d'initialisation d'une connexion est le même.
Pour d'autres situations, une véritable IP est requise.

Je ne sais pas si ma compréhension du processus est correcte, veuillez me corriger.

Pouvez-vous considérer un tel modèle comme un faux-ip-proxy-only:

1. Pour les noms de domaine qui nécessitent un proxy, renvoyez une fausse adresse IP
2. Pour les autres noms de domaine, la vraie adresse IP sera toujours retournée
   2.1 S'il existe une règle de nom de domaine qui définit la connexion directe, une adresse IP réelle est requise
   2.2 Pour le segment IP qui nécessite un proxy (règles géographiques), il doit également interroger d'abord l'adresse IP réelle, puis comparer la base de données géographique, puis établir une connexion
   2.3 Pour les segments IP directement connectés restants, une adresse IP réelle est également requise

De cette manière, les requêtes DNS inutiles ne sont toujours pas générées pour les noms de domaine qui nécessitent un proxy.
Pour le segment IP qui a besoin d'un proxy, le temps d'initialisation d'une connexion est le même.
Pour d'autres situations, une véritable IP est requise.

Je ne sais pas si ma compréhension du processus est correcte, veuillez me corriger.

Seul le faux retour d'ip est effectué sur le nom de domaine pour être mandaté dans les règles, et les autres retournent tous une vraie ip?

@beyondkmp oui

@BirkhoffLee Merci, cette idée est très bonne, puis-je détourner vers différentes instances via iptables?Si oui, pouvez-vous partager la méthode de détournement

La même méthode qu'une instance, mais deux DNAT iptables:

# 到 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

Plus un faux DNS inventé par 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

De cette façon, les appareils qui nécessitent une Fake IP peuvent changer le DNS en 198.19.0.1.

EDIT: Correction d'un faux CIDR IP

Votre méthode est bonne, je veux l'essayer, puis-je demander,
Comment ouvrir 2 instances Clash? L'un des ports proxy est défini sur 9999?

1. Actuellement, Clash ne répond pas au paquet ICMP de faux ip, ce qui peut provoquer un comportement inattendu de certaines applications
2. Étant donné que la fausse adresse IP est utilisée et que Clash n'a pas encore de capacités de transfert UDP, certaines applications UDP essaieront de se connecter à la fausse adresse IP et échoueront (par exemple, TeamSpeak)

https://github.com/vernesong/OpenClash/releases/tag/v0.33.7-beta
Openclash version 0.33.7 fournit une solution en établissant une liste de noms de domaine pour permettre à des noms de domaine spécifiques d'utiliser des DNS spécifiques.

https://github.com/Dreamacro/clash/releases/tag/TUN Vous pouvez essayer le binaire expérimental TUN

Ce mécanisme de fakeip est si compliqué qu'il n'est pas plus pratique de décompresser et d'obtenir directement l'hôte comme v2ray.

En mode faux ip, le JMGO Cloud ne peut pas se connecter à Internet

Pouvez-vous considérer un tel modèle comme un faux-ip-proxy-only:

1. Pour les noms de domaine qui nécessitent un proxy, renvoyez une fausse adresse IP
2. Pour les autres noms de domaine, la vraie adresse IP sera toujours retournée
   2.1 S'il existe une règle de nom de domaine qui définit la connexion directe, une adresse IP réelle est requise
   2.2 Pour le segment IP qui nécessite un proxy (règles géographiques), il doit également interroger d'abord l'adresse IP réelle, puis comparer la base de données géographique, puis établir une connexion
   2.3 Pour les segments IP directement connectés restants, une adresse IP réelle est également requise

De cette manière, les requêtes DNS inutiles ne sont toujours pas générées pour les noms de domaine qui nécessitent un proxy.
Pour le segment IP qui a besoin d'un proxy, le temps d'initialisation d'une connexion est le même.
Pour d'autres situations, une véritable IP est requise.

Je ne sais pas si ma compréhension du processus est correcte, veuillez me corriger.

J'espère que les développeurs pourront envisager de telles nouvelles fonctionnalités, mais cela semble toujours impossible.