Clash: ゲートウェイプロキシとしての偽のIPモードのいくつかの問題

TUNモードはこれら2つの問題を解決します

質問したいのですが、clashをルーターの透過プロキシとして使用しており、fake-ipを使用したいのですが、TUNモードを使用できますか？使用している場合、構成情報を共有できますか？

（redir-hostと比較して）偽のipを使用したいのは、それがより合理的だと思うからです。現在、ほとんどすべての状況がうまく機能しています。唯一の問題は、King of Honorの検出が遅れると接続が失敗することです。これは、udpが偽を使用しているためだと思います。 ipの問題なので、聞きたいです。

どうもありがとう。

TUNはまだ実装されていません。私の現在の慣習は、UDPなしでfakeipを使用し、redir-hostを使用する（つまり、2つのClashインスタンスを開く）ことです。

2:43 AylinZhaoので土、2019年7月27日に[email protected]書きました：

質問したいのですが、clashをルーターの透過プロキシとして使用しており、fake-ipを使用したいのですが、TUNモードを使用できますか？使用している場合、構成情報を共有できますか？

偽物を使いたい
ip（redir-hostと比較して）の理由は、より合理的であるためです。現在、ほとんどすべての状況がうまく機能しています。唯一の問題は、栄光の王の検出が遅れると接続が接続できないことです。udpが偽物を使用しているためだと思います。
ipの問題なので、お聞きしたいのですが。

どうもありがとう。

—
スレッドを作成したため、これを受け取っています。

このメールに直接返信し、GitHubで表示してください
https://github.com/Dreamacro/clash/issues/179?email_source=notifications&email_token=AB6FI752JQQZPMZBH4KYEHLQBNAWRA5CNFSM4HMJDBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBW63LNMVXHJK25MZBH4KYEHLQBNAWRA5CNFSM4HMJDBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBH4KYEHLQBNAWRA5CNFSM5
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AB6FI7YKTOA2BX525XOUELLQBNAWRANCNFSM4HMJDBCQ
。

@BirkhoffLeeありがとうございます。このアイデアは非常に優れています転送されますか？はいの場合、流用の方法を共有できますか

@BirkhoffLeeありがとうございます。このアイデアは非常に優れています転送されますか？はいの場合、流用の方法を共有できますか

インスタンスと同じ方法ですが、2つの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

さらに、Sukkaによって発明された偽のDNS

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

このようにして、偽のIPを必要とするデバイスはDNSを198.19.0.1に変更できます。

編集：偽のIPCIDRを修正

共有していただきありがとうございます。これは、デバイスごとに異なるdnを設定することにより、異なる解決戦略を実装することであると理解しています。

私の現在の状況では、ルーターが透過プロキシに設定されている状態で、同じデバイス（私の携帯電話）の一部のudpトラフィック（キングオナー遅延テスト）が正しく処理されることを望んでいますが、方法があるかどうかはわかりません。

推奨される解決策は、すべてがルーター上で実行され、すべてのデバイスに対して透過的になることです。

共有していただきありがとうございます。これは、デバイスごとに異なるdnを設定することにより、異なる解決戦略を実装することであると理解しています。

私の現在の状況では、ルーターが透過プロキシに設定されている状態で、同じデバイス（私の携帯電話）の一部のudpトラフィック（キングオナー遅延テスト）が正しく処理されることを望んでいますが、方法があるかどうかはわかりません。

推奨される解決策は、すべてがルーター上で実行され、すべてのデバイスに対して透過的になることです。

未だに

理解して、もう一度ありがとう

そのようなモデルをfake-ip-proxy-onlyと見なすことができますか？

1. プロキシが必要なドメイン名の場合は、偽のipを返します
2. 他のドメイン名の場合、実際のIPは常に返されます
   2.1直接接続を定義するドメイン名ルールがある場合、実際のIPが必要です
   2.2プロキシ（geoルール）を必要とするipセグメントの場合、最初に実際のipを照会し、次にgeoデータベースを比較してから、接続を開始する必要もあります。
   2.3残りの直接接続されたIPセグメントには、実際のIPも必要です

このようにして、プロキシを必要とするドメイン名に対して不要なdnsクエリが生成されることはありません。
プロキシが必要なipセグメントの場合、接続を開始する時間は同じです。
その他の状況では、実際のIPが必要です。

プロセスの理解が正しいかどうかわかりません。訂正してください。

そのようなモデルをfake-ip-proxy-onlyと見なすことができますか？

1. プロキシが必要なドメイン名の場合は、偽のipを返します
2. 他のドメイン名の場合、実際のIPは常に返されます
   2.1直接接続を定義するドメイン名ルールがある場合、実際のIPが必要です
   2.2プロキシ（geoルール）を必要とするipセグメントの場合、最初に実際のipを照会し、次にgeoデータベースを比較してから、接続を開始する必要もあります。
   2.3残りの直接接続されたIPセグメントには、実際のIPも必要です

このようにして、プロキシを必要とするドメイン名に対して不要なdnsクエリが生成されることはありません。
プロキシが必要なipセグメントの場合、接続を開始する時間は同じです。
その他の状況では、実際のIPが必要です。

プロセスの理解が正しいかどうかわかりません。訂正してください。

ルールでプロキシされるドメイン名に対して偽のIPリターンのみが実行され、他のすべては実際のIPを返しますか？

@beyondkmpはい

@BirkhoffLeeありがとうございます。このアイデアは非常に優れています転送されますか？はいの場合、流用の方法を共有できますか

インスタンスと同じ方法ですが、2つの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

さらに、Sukkaによって発明された偽のDNS

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

このようにして、偽のIPを必要とするデバイスはDNSを198.19.0.1に変更できます。

編集：偽のIPCIDRを修正

あなたの方法は良いです、私はそれを試してみたいです、私は尋ねることができます、
2つのClashインスタンスを開く方法は？プロキシポートの1つが9999に設定されていますか？

1. 現在、Clashは偽のIPのICMPパケットに応答しないため、一部のアプリケーションで予期しない動作が発生する可能性があります。
2. 偽のIPが使用されており、Clashには現在UDP転送機能がないため、一部のUDPアプリケーションは偽のIPに接続しようとして失敗します（TeamSpeakなど）。

https://github.com/vernesong/OpenClash/releases/tag/v0.33.7-beta
Openclashバージョン0.33.7は、特定のドメイン名が特定のdnを使用できるようにドメイン名リストを確立することでソリューションを提供します。

https://github.com/Dreamacro/clash/releases/tag/TUN実験的なTUNバイナリを試すことができ

このfakeipメカニズムは非常に複雑であるため、v2rayのようなホストを直接解凍して取得するのは便利ではありません。

偽のIPモードでは、JMGOクラウドはインターネットに接続できません

そのようなモデルをfake-ip-proxy-onlyと見なすことができますか？

1. プロキシが必要なドメイン名の場合は、偽のipを返します
2. 他のドメイン名の場合、実際のIPは常に返されます
   2.1直接接続を定義するドメイン名ルールがある場合、実際のIPが必要です
   2.2プロキシ（geoルール）を必要とするipセグメントの場合、最初に実際のipを照会し、次にgeoデータベースを比較してから、接続を開始する必要もあります。
   2.3残りの直接接続されたIPセグメントには、実際のIPも必要です

このようにして、プロキシを必要とするドメイン名に対して不要なdnsクエリが生成されることはありません。
プロキシが必要なipセグメントの場合、接続を開始する時間は同じです。
その他の状況では、実際のIPが必要です。

プロセスの理解が正しいかどうかわかりません。訂正してください。

開発者がそのような新機能を検討できることを願っていますが、それでもそうすることは不可能のようです。