Clash: العديد من المشكلات المتعلقة بوضع Fake IP كبوابة وكيل

تم إنشاؤها على ١٢ مايو ٢٠١٩  ·  17تعليقات  ·  مصدر: Dreamacro/clash

  1. حاليًا ، لا تستجيب Clash لحزم ICMP الخاصة بـ IP المزيف ، مما قد يتسبب في سلوك غير متوقع لبعض التطبيقات
  2. نظرًا لاستخدام Fake IP ، ولا تملك Clash القدرة على إعادة توجيه UDP ، ستحاول بعض تطبيقات UDP الاتصال بـ IP المزيف وتفشل (على سبيل المثال ، TeamSpeak)

ال 17 كومينتر

سيحل وضع TUN هاتين المشكلتين

أود أن أسأل ، أنا الآن أستخدم clash كوكيل شفاف على جهاز التوجيه ، وآمل في استخدام عنوان IP مزيف ، هل يمكنني استخدام وضع TUN؟ إذا كان الأمر كذلك ، فهل يمكنني مشاركة بعض معلومات التكوين؟

آمل أن أستخدم IP وهمية (مقارنة بـ redir-host) لأنني أعتقد أنه أكثر منطقية. في الوقت الحالي ، تعمل جميع المواقف تقريبًا بشكل جيد. المشكلة الوحيدة هي أن الاتصال يفشل عندما يتأخر ملك اكتشاف المجد. أعتقد أن السبب في ذلك هو أن udp يستخدم وهمية. مشكلة الملكية الفكرية ، لذلك أود أن أسأل.

شكرا جزيلا.

لم يتم تنفيذ TUN بعد. ممارستي الحالية هي أخذ ملف وهمي بدون UDP ، وأخذ مضيف redir إذا لزم الأمر (أي ، فتح مثيلتين من Clash)

في يوم السبت ، 27 يوليو 2019 الساعة 2:43 صباحًا كتب AylinZhao [email protected] :

أود أن أسأل ، أنا الآن أستخدم clash كوكيل شفاف على جهاز التوجيه وآمل في استخدام عنوان IP مزيف. هل يمكنني استخدام وضع TUN؟ إذا كان الأمر كذلك ، فهل يمكنني مشاركة بعض معلومات التكوين؟

تريد استخدام وهمية
سبب IP (مقارنة بـ redir-host) هو أنه أكثر منطقية. في الوقت الحالي ، تعمل جميع المواقف تقريبًا بشكل جيد. المشكلة الوحيدة هي أن الاتصال يفشل عندما يتأخر اكتشاف ملك المجد. أعتقد أن السبب في ذلك هو استخدام udp
مشكلة الملكية الفكرية ، لذلك أود أن أسأل.

شكرا جزيلا.

-
أنت تتلقى هذا لأنك قمت بتأليف الموضوع.

قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Dreamacro/clash/issues/179؟email_source=notifications&email_token=AB6FI752JQQZPMZBH4KYEHLQBNAWRA5CNFSM4HMJDBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBW63LNMVXHJK25MZBH4KYEHLQBNAWRA5CNFSM4HMJDBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJK515MZ559،issued
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AB6FI7YKTOA2BX525XOUELLQBNAWRANCNFSM4HMJDBCQ
.

BirkhoffLee شكرًا لك ، هذه الفكرة جيدة جدًا ، هل يمكنني التحويل إلى حالات مختلفة من خلال iptables؟إذا كانت الإجابة بنعم ، فهل يمكنك مشاركة طريقة التحويل

BirkhoffLee شكرًا لك ، هذه الفكرة جيدة جدًا ، هل يمكنني التحويل إلى حالات مختلفة من خلال iptables؟إذا كانت الإجابة بنعم ، فهل يمكنك مشاركة طريقة التحويل

إنها نفس طريقة المثيل ، لكن اثنين من 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

Plus Fake DNS من اختراع 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

بهذه الطريقة ، يمكن للجهاز الذي يحتاج إلى Fake IP تغيير DNS إلى 198.19.0.1.

تحرير: مصحح Fake IP CIDR

شكرا للمشاركة. أفهم أن هذا يهدف إلى تنفيذ استراتيجيات دقة مختلفة من خلال تعيين نظام أسماء نطاقات مختلف لأجهزة مختلفة.

وضعي الحالي هو أنه في حالة تعيين جهاز التوجيه باستخدام وكيل شفاف ، فإن بعض حركة مرور udp (اختبار تأخير King of Honor) لنفس الجهاز (هاتفي المحمول) تأمل في التعامل معها بشكل صحيح ، ولا أعرف ما إذا كان هناك أي طريقة.

الحل المفضل هو أن كل شيء يتم على جهاز التوجيه وشفاف لجميع الأجهزة.

شكرا للمشاركة. أفهم أن هذا يهدف إلى تنفيذ استراتيجيات دقة مختلفة من خلال تعيين نظام أسماء نطاقات مختلف لأجهزة مختلفة.

وضعي الحالي هو أنه في حالة تعيين جهاز التوجيه باستخدام وكيل شفاف ، فإن بعض حركة مرور udp (اختبار تأخير King of Honor) لنفس الجهاز (هاتفي المحمول) تأمل في التعامل معها بشكل صحيح ، ولا أعرف ما إذا كان هناك أي طريقة.

الحل المفضل هو أن كل شيء يتم على جهاز التوجيه وشفاف لجميع الأجهزة.

ليس بعد

افهم ، شكرا مرة أخرى

هل يمكنك اعتبار مثل هذا النموذج وهمي IP Proxy فقط:

  1. بالنسبة لأسماء النطاقات التي تتطلب وكيلاً ، قم بإرجاع عنوان IP المزيف
  2. بالنسبة لأسماء المجالات الأخرى ، سيتم دائمًا إرجاع عنوان IP الحقيقي
    2.1 إذا كانت هناك قاعدة اسم المجال التي تحدد الاتصال المباشر ، فإن IP الحقيقي مطلوب
    2.2 بالنسبة لشريحة IP التي تتطلب وكيلاً (القواعد الجغرافية) ، فإنها تحتاج أيضًا إلى الاستعلام عن عنوان IP الحقيقي أولاً ثم مقارنة قاعدة البيانات الجغرافية ، ثم بدء الاتصال
    2.3 لشرائح IP المتبقية المتصلة مباشرة ، يلزم أيضًا IP الحقيقي

بهذه الطريقة ، لا تزال استعلامات DNS غير الضرورية لا يتم إنشاؤها لأسماء النطاقات التي تحتاج إلى وكيل.
بالنسبة لقطاع IP الذي يحتاج إلى وكيل ، يكون وقت بدء الاتصال هو نفسه.
للحالات الأخرى ، مطلوب IP الحقيقي.

لا أعرف ما إذا كان فهمي للعملية صحيحًا ، يرجى تصحيح ذلك.

هل يمكنك اعتبار مثل هذا النموذج وهمي IP Proxy فقط:

  1. بالنسبة لأسماء النطاقات التي تتطلب وكيلاً ، قم بإرجاع عنوان IP المزيف
  2. بالنسبة لأسماء المجالات الأخرى ، سيتم دائمًا إرجاع عنوان IP الحقيقي
    2.1 إذا كانت هناك قاعدة اسم المجال التي تحدد الاتصال المباشر ، فإن IP الحقيقي مطلوب
    2.2 بالنسبة لشريحة IP التي تتطلب وكيلاً (القواعد الجغرافية) ، فإنها تحتاج أيضًا إلى الاستعلام عن عنوان IP الحقيقي أولاً ثم مقارنة قاعدة البيانات الجغرافية ، ثم بدء الاتصال
    2.3 لشرائح IP المتبقية المتصلة مباشرة ، يلزم أيضًا IP الحقيقي

بهذه الطريقة ، لا تزال استعلامات DNS غير الضرورية لا يتم إنشاؤها لأسماء النطاقات التي تحتاج إلى وكيل.
بالنسبة لقطاع IP الذي يحتاج إلى وكيل ، يكون وقت بدء الاتصال هو نفسه.
للحالات الأخرى ، مطلوب IP الحقيقي.

لا أعرف ما إذا كان فهمي للعملية صحيحًا ، يرجى تصحيح ذلك.

يتم تنفيذ إرجاع عنوان IP الوهمي فقط على اسم المجال المراد توكيله في القواعد ، والآخر يتم إرجاع IP الحقيقي؟

beyondkmp نعم

BirkhoffLee شكرًا لك ، هذه الفكرة جيدة جدًا ، هل يمكنني التحويل إلى حالات مختلفة من خلال iptables؟إذا كانت الإجابة بنعم ، فهل يمكنك مشاركة طريقة التحويل

إنها نفس طريقة المثيل ، لكن اثنين من 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

Plus Fake DNS من اختراع 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

بهذه الطريقة ، يمكن للجهاز الذي يحتاج إلى Fake IP تغيير DNS إلى 198.19.0.1.

تحرير: مصحح Fake IP CIDR

طريقتك جيدة ، أريد أن أجربها ، هل لي أن أسأل ،
كيف يتم فتح 2 حالات Clash؟ تم تعيين أحد منافذ الوكيل على 9999؟

  1. حاليًا ، لا تستجيب Clash لحزم ICMP الخاصة بـ IP المزيف ، مما قد يتسبب في سلوك غير متوقع لبعض التطبيقات
  2. نظرًا لاستخدام Fake IP ، ولا تملك Clash القدرة على إعادة توجيه UDP ، ستحاول بعض تطبيقات UDP الاتصال بـ IP المزيف وتفشل (على سبيل المثال ، TeamSpeak)

https://github.com/vernesong/OpenClash/releases/tag/v0.33.7-beta
يوفر الإصدار 0.33.7 من Openclash حلاً من خلال إنشاء قائمة بأسماء المجال للسماح لأسماء نطاقات معينة باستخدام نظام أسماء نطاقات محدد.

https://github.com/Dreamacro/clash/releases/tag/TUN يمكنك تجربة ثنائي TUN التجريبي

هذه الآلية المزيفة معقدة للغاية لدرجة أنه ليس من الملائم فك حزمها مباشرة والحصول على المضيف مثل v2ray.

في وضع IP المزيف ، لا يمكن لـ JMGO Cloud الاتصال بالإنترنت

هل يمكنك اعتبار مثل هذا النموذج وهمي IP Proxy فقط:

  1. بالنسبة لأسماء النطاقات التي تتطلب وكيلاً ، قم بإرجاع عنوان IP المزيف
  2. بالنسبة لأسماء المجالات الأخرى ، سيتم دائمًا إرجاع عنوان IP الحقيقي
    2.1 إذا كانت هناك قاعدة اسم المجال التي تحدد الاتصال المباشر ، فإن IP الحقيقي مطلوب
    2.2 بالنسبة لشريحة IP التي تتطلب وكيلاً (القواعد الجغرافية) ، فإنها تحتاج أيضًا إلى الاستعلام عن عنوان IP الحقيقي أولاً ثم مقارنة قاعدة البيانات الجغرافية ، ثم بدء الاتصال
    2.3 لشرائح IP المتبقية المتصلة مباشرة ، يلزم أيضًا IP الحقيقي

بهذه الطريقة ، لا تزال استعلامات DNS غير الضرورية لا يتم إنشاؤها لأسماء النطاقات التي تحتاج إلى وكيل.
بالنسبة لقطاع IP الذي يحتاج إلى وكيل ، يكون وقت بدء الاتصال هو نفسه.
للحالات الأخرى ، مطلوب IP الحقيقي.

لا أعرف ما إذا كان فهمي للعملية صحيحًا ، يرجى تصحيح ذلك.

آمل أن يتمكن المطورون من التفكير في مثل هذه الميزات الجديدة ، ولكن لا يزال من المستحيل القيام بذلك.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات