توجيهات Listen وBind وBindSame في Tinyproxy: أي عنوان هو الفائز
يختار Listen العنوان الذي يقبل العملاء، ويختار Bind مصدر الاتصالات الصادرة. لا يثبّت أي منهما مسارًا، فتحقق من المسار على حدة.
يستجيب الوكيل ويكتمل الطلب، ومع ذلك تظل الجهة الوجهة تسجّل عنوان الشبكة المحلية. لا شيء في سجل الوكيل يبدو خطأً، والسطر الذي عدّلته هو السطر الذي أوصتك الوثائق بتعديله. على مضيف يملك عنوان شبكة محلية وعنوان نفق معًا، تحدّد ثلاثة توجيهات أي عنوان يظهر وأين، وواحد منها فقط يخص الجانب الصادر. وقراءتها بترتيب خاطئ تدفعك إلى جدول التوجيه بلا سبب.
العَرَض: الوجهة ترى عنوان الشبكة المحلية
يتصل العميل بالوكيل عبر عنوان الشبكة المحلية، فيفتح الوكيل اتصاله الخاص إلى الوجهة. يختار ذلك الاتصال الثاني عنوان مصدر وفق قواعد النواة، وهو افتراضيًا ما يختاره بحث المسار. لذلك تسجّل الوجهة العنوان الأساسي للمضيف رغم أن كل بايت مرّ عبر الوكيل. لا شيء معطوب من حيث إعادة التمرير، ولهذا لا يملك سجل الوكيل ما يقوله عن ذلك.
الصورة المعكوسة لذلك العطل أسهل في الملاحظة: ثبّت المصدر الصادر على عنوان النفق فتتوقف عملاء الشبكة المحلية عن الوصول إلى المستمع تمامًا. تلك النسخة تعلن عن نفسها، بينما تختبئ الأولى خلف طلب ناجح. وكلتاهما تنبعان من معاملة توجيه واحد كأنه يجيب عن السؤالين.
ثلاثة توجيهات وثلاثة عناوين مختلفة
يسمّي Listen العنوان المحلي الذي يقبل عملاء الوكيل. ويوفّر Bind عنوان مصدر للاتصالات التي يفتحها الوكيل إلى الخارج، ويطلب BindSame إعادة استخدام العنوان المحلي للاتصال الذي قبله للتو. تلك ثلاثة أسئلة منفصلة، وسطر واحد لا يجيب إلا عن واحد منها. والخلط بينها هو السبب المعتاد في أن يبدو التغيير بلا أثر.
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The route, not the proxy: the source cannot reach that destination |
اقرأ الإعداد المشروح المرفق بالنسخة المثبّتة، لأن القيم الافتراضية والصياغات المقبولة تتغيّر بين الإصدارات. وملف الإعداد النموذجي للمشروع يوثّق كل توجيه إلى جانب الآخر. قارن ذلك الملف بالملف الموجود على القرص، لا بدليل كُتب لتوزيعة أخرى.
اضبط المستمع والمصدر الصادر بشكل مستقل
خذ مضيفًا عنوان شبكته المحلية 192.168.50.10 وعنوان نفقها 10.90.0.3. إذا كان على عملاء الشبكة المحلية الوصول إلى الوكيل بينما تغادر طلباتهم من النفق، فهذان قراران مستقلان ويجب كتابة كليهما. والمقطع التالي يعبّر عن ذلك بالضبط ولا شيء غيره.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noهذا ليس إعدادًا كاملًا، فاحتفظ بالمنفذ المعتمد والمصادقة وضوابط وصول العملاء وقيود الوجهات. ويجب أن ينتمي العنوانان إلى هذا المضيف داخل فضاء أسماء الشبكة الخاص بـTinyproxy، لأن قيمة Bind لا يمكن للعملية امتلاكها تفشل عند الاتصال لا عند بدء التشغيل. ويصف BindSame yes سياسة مختلفة، حيث يصبح العنوان المحلي للاتصال المقبول هو المصدر الصادر. وفي الإصدارات الحالية يتقدّم ذلك الفرع على قائمة Bind، وهكذا يختفي مصدر مُعدّ دون أي خطأ.
تحقّق من المسار الذي يفترضه المصدر
اختيار عنوان مصدر لا ينشئ مسارًا، فاسأل النواة عما ستفعله بذلك المصدر وتلك الوجهة. البحث الذي يسمّي واجهة النفق هو الحد الأدنى من الدليل، والذي يسمّي واجهة الشبكة المحلية يعني أن المصدر لا يمكن أن يعمل كما هو مكتوب. والبحث سياقي: فهو يقيّم قواعد السياسة والجدول النافذ في ذلك الفضاء. وهو ليس اتصالًا، ولا يقول شيئًا عمّا سيعرضه NAT لاحقًا على الخدمة.
ip -4 route get 203.0.113.25 from 10.90.0.3استخدم عنوانًا توثيقيًا في المثال واستبدله بالخدمة المصرّح لك باختبارها. نفّذ البحث داخل فضاء أسماء الوكيل عندما يعمل الوكيل في حاوية، لأن قواعد المضيف ليست القواعد التي تراها العملية. وعندما يغيب مسار النفق المقصود، اطلب من مسؤول الشبكة إصلاحه بدلًا من إضافة قواعد خاصة بالوجهات إلى مضيف الوكيل. لا تمسح مسارات المضيف ولا تعطّل المسارات المدفوعة من الخادم لتنجح قراءة بحث، حتى لو فعل دليل أقدم ذلك، لأن تلك التغييرات تنقل سلوك VPN المعتمد للمضيف بأكمله لإصلاح مسار وكيل واحد.
أكّد المصدر عند الوجهة
اقرأ المصدر حيث يصل الطلب، لا حيث يغادر. سجل تطبيق الوجهة، أو جهاز الحافة أمامها، يسجّل العنوان الذي رآه فعلًا، بينما يستطيع الوكيل إخبارك بما نوى فقط. أرسل طلبًا جديدًا واحدًا عبر المستمع المقصود بعد التغيير، لأن اتصالًا مخزّنًا في الذاكرة لا يثبت شيئًا عن الربط الجديد. ثم قارن ذلك العنوان المسجّل بالعنوان الذي أعددته.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sSأمر curl ليس إلا مولّد حركة؛ والعنوان الجدير بالتحقق هو الذي سجّله الطرف البعيد، لا النظير الذي صادف أن اتصل به curl. وإذا اختلف الاثنان، فحدّد هل يأتي الفرق من اختيار المصدر أم من ترجمة لاحقة في الطريق، لأن تلك تُصلح في مواضع مختلفة. وخطّط لتغييرات العناوين وإعادة تشغيل الوكيل معًا أيضًا، لأن ربط عنوان لم يعد النفق يملكه يفشل بهدوء بعد إعادة الاتصال. وحدّد سلوك DNS وIPv6 بشكل منفصل كذلك، لأن مقطع IPv4 أعلاه لا يثبت شيئًا عن أي منهما.