Clash: [سؤال] دور الاحتياط في نظام أسماء النطاقات

تم إنشاؤها على ١٧ أبريل ٢٠٢٠ · 6تعليقات · مصدر: Dreamacro/clash

على سبيل المثال ، قم بتكوين مثل هذا في التكوين

dns:
  enable: true
  listen: :53
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
  fallback:
    - 8.8.8.8

سؤالي هو ماذا يفعل الاحتياطي؟

قرأت هذا المقال: تأثير تلوث DNS على Clash (لنظام التشغيل Windows)

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

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

أنا في حيرة شديدة لأنه نظرًا لأن خادم الأسماء يمكنه تحديد عنوان IP الملوث مباشرةً ، فإن IP الملوث سيرسل المضيف مباشرةً إلى الخادم الوكيل ، وسيحل الخادم الوكيل عنوان IP الصحيح والملائم لـ CDN ، أليس هناك حاجة إلى الرجوع؟

أعلم أنني أفكر في شيء خاطئ ، أنا هنا لطلب النصيحة ، لا تضحك علي ...

question

مصدر

ju0594

التعليق الأكثر فائدة

لا يمكن الحكم على عنوان IP الملوث ، ولكن عندما يكون GeoIP الذي تم إرجاعه بواسطة DNS الأول ليس CN ، سيتم أخذ قيمة DNS الاحتياطي. نظرًا لأن GeoIP الملوث موجود في الخارج ، يمكن أن يمنع الصدام التلوث من هذا المستوى. بالطبع ، الفرضية هي قم بتعيين DNS المنبع للمجموعة الاحتياطية (مثل DNS الخالي من التلوث [تعرض الانقراض الأساسي في الجدار] ، من خلال المنافذ غير القياسية ، DNS عبر TLS / HTTPS).
يمكنك الرجوع إلى: https://github.com/Dreamacro/clash/issues/621#issuecomment -614702773

بالنسبة لـ cfw wiki ، حتى إذا كانت ملوثة ، فهذا يعني أنه إذا أدت قاعدة مطابقة الاتصال الحالية إلى وكيل ، فإن clash سيغير الاتصال الذي بدأه IP إلى اسم المضيف الأصلي الخاص به ويرسله إلى العقدة البعيدة ، لذلك حتى العميل / يحصل المستعرض على عنوان IP الملوث ولن يؤثر على الاتصال النهائي ، لأنه تم تجاهل IP الملوث عند إرساله إلى الوكيل البعيد عبر clash وإعادة تطبيق اسم المضيف الأصلي ، وهو redir- أصل اسم وضع المضيف.
مرجع إضافي: الحديث عن سلوك تحليل DNS في بيئة الوكيل | مدونة Sukka

Mosney في ٢٣ أبريل ٢٠٢٠

👍4

ال 6 كومينتر

نظام DNS المدمج هو لحل مشكلة دقة DNS للوكيل الشفاف ، فليس من الضروري فتحه للاستخدام العادي

h3fang في ١٨ أبريل ٢٠٢٠

Mosney في ٢٣ أبريل ٢٠٢٠

👍4

nameserver الخادم الموجود في ملوث (مثل خادم DNS خالٍ من التلوث تم إنشاؤه محليًا) فإن fallback ليس ضروريًا للتعيين
إذا كانت القواعد تتطابق مع Proxy ، فإنهم ببساطة لا يستخدمون عنوان IP الذي تم حله ، ويرسلون اسم النطاق مباشرة إلى الخادم الوكيل ، مما يحل مشكلة CDN.
إذا تطابقت القاعدة مع DIRECT ، فستبدأ اتصالاً مباشرًا بعنوان IP الذي تم حله

عند استخدام بروكسي Socks5 / Http (s) ، لا يحتاج النظام إلى معرفة عنوان IP الهدف للاتصال ، ما عليك سوى إرسال طلب اسم المجال إلى الخادم الوكيل.
عند استخدام وكيل شفاف ، لأنه تطبيق قياسي لـ TCP / IP ، فإن الحزمة التي تحصل عليها Clash لا تحتوي على معلومات اسم المجال ، لذلك يجب على Clash استخدام وظيفة DNS المضمنة لإجراء تعيين اسم المجال IP <-> ، بحيث يمكن لـ Clash إرسال النظام تتم استعادة DST-IP في حزمة TCP / UDP إلى اسم المجال وتتم مطابقة القاعدة

.
يجب أن يكون فهمي صحيحًا ، أليس كذلك؟
ملاحظة: وثائق Clash ليست في الحقيقة مفصلة للغاية ، تحقق من المعلومات في كل مكان ...

muink في ٢١ يوليو ٢٠٢٠

👍2

nameserver الخادم الموجود في ملوث (مثل خادم DNS خالٍ من التلوث تم إنشاؤه محليًا) فإن fallback ليس ضروريًا للتعيين
إذا كانت القواعد تتطابق مع Proxy ، فإنهم ببساطة لا يستخدمون عنوان IP الذي تم حله ، ويرسلون اسم النطاق مباشرة إلى الخادم الوكيل ، مما يحل مشكلة CDN.
إذا تطابقت القاعدة مع DIRECT ، فستبدأ اتصالاً مباشرًا بعنوان IP الذي تم حله
.
عند استخدام بروكسي Socks5 / Http (s) ، لا يحتاج النظام إلى معرفة عنوان IP الهدف للاتصال ، ما عليك سوى إرسال طلب اسم المجال إلى الخادم الوكيل.
عند استخدام وكيل شفاف ، لأنه تطبيق قياسي لـ TCP / IP ، فإن الحزمة التي تحصل عليها Clash لا تحتوي على معلومات اسم المجال ، لذلك يجب على Clash استخدام وظيفة DNS المضمنة لإجراء تعيين اسم المجال IP <-> ، بحيث يمكن لـ Clash إرسال النظام تتم استعادة DST-IP في حزمة TCP / UDP إلى اسم المجال وتتم مطابقة القاعدة
.
يجب أن يكون فهمي صحيحًا ، أليس كذلك؟
ملاحظة: وثائق Clash ليست في الحقيقة مفصلة للغاية ، تحقق من المعلومات في كل مكان ...

عفوًا ، إذا لم يتم استخدامه كوكيل شفاف ، ولكن فقط كعميل ، فهل سيتم حل استخدام مضيف redir مرة أخرى أكثر من وضع IP المزيف (بافتراض اسم المجال الذي يتم تشغيله من خلال الوكيل) ، أم أن الجميع متماثلون؟

akw5454521 في ٢٧ يوليو ٢٠٢٠

@ akw5454521
لا يتضمن وضع IP الوهمي في الواقع حل نظام أسماء النطاقات. بعد تلقي clash لطلب نظام أسماء النطاقات ، يرسل مباشرةً عنوان IP المحجوز إلى المستخدم ، وينشئ اتصالاً مباشرًا بالخادم البعيد من خلال socks5 من خلال اسم المجال في طلب نظام أسماء النطاقات ، ثم يعود من خلال عنوان IP المحجوز ينشئ المستخدم الاتصال الفعلي
يحتاج وضع redir-host إلى التحليل ، وتكون نتيجة التحليل ذات مغزى فقط عندما تتطابق مع قاعدة الاتصال المباشر (تنشئ اتصالاً بشكل مباشر). لا يهم ما إذا كانت نتيجة تحليل اسم المجال الذي يجب أن يكون وكيلاً مزيفة ، لأن هذه الخطوة هي نفس الخطوة IP المزيفة أعلاه الغرض المراد تحقيقه هو نفسه ، فقط للمستخدم والصراع لتأسيس المراسلات بين اسم المجال و IP. الطلب إلى الخادم البعيد هو اسم المجال بدلاً من IP الذي تم حله.

بالنسبة لمسألة السرعة ، وهمية IP لأطول فترة ممكنة

muink في ٢٨ يوليو ٢٠٢٠

أود أن أسأل ، إذا كان في وضع redir-host ، إذا حدد GeoIP أنه ليس CN ، فسوف يتراجع ، وإذا كان يفي بشروط الوكيل في نفس الوقت ، فسيتم إرسال المضيف مباشرةً إلى جهاز التحكم عن بُعد للتحليل ، أي ما إذا كان IP قد استقبله العميل لا يهم ما إذا كان هذا صحيحًا (لأنه إذا تم تحديد أنه يجب حل العامل من الطرف البعيد) ، فأنا أريد أن أسأل ما معنى المجموعة الاحتياطية ، فمن الأفضل استخدام التلوث في خادم الأسماء مباشرةً ، على أي حال ، يجب حله من الطرف البعيد.
(ملاحظة: أنا شخصياً أعتقد أنه فقط عندما يكون اسم المجال ملوثًا ويتقرر أنه ليس وكيلًا ، فإن الرجوع سيعمل حقًا)

بالإضافة إلى ذلك ، قد يكون هناك تأخير كبير جدًا عند طلب نظام أسماء النطاقات في الاحتياطي (مثل tls: //dns.google ، وما إلى ذلك ) ، لذلك ينتظر العميل وقتًا طويلاً ، أليس كذلك؟