Redsocks يستمع على واجهة الرجوع المحلية لكن حركة VPN لا تصل أبدًا

يرتفع النفق ويستطيع العميل أن يرسل ping إلى البوابة، لكن كل طلب ويب يمر عبر مسار الوكيل يموت. عملية redsocks تعمل ومنفذها يستمع، لذلك تبدو الخدمة سليمة من البوابة نفسها. ما يفشل هو خطوة التسليم: حزمة يعاد توجيهها من النفق لا تهبط على المقبس الذي شغلته. عنوان الربط وهدف إعادة التوجيه يجب أن يتطابقا، وعادة لا يُفحص إلا أحدهما.

أين تهبط الحزمة المعاد توجيهها فعليًا

الوكيل الشفاف على البوابة يستخدم هدف REDIRECT في جدول nat عند PREROUTING لإعادة كتابة وجهة اتصال قادم إلى منفذ محلي. الوجهة المعاد كتابتها عنوان محلي كما يُرى من الواجهة التي وصلت عليها الحزمة، وليس عنوان الرجوع المحلي لعملية بدأت في مكان آخر. المستمع المرتبط بـ 127.0.0.1 فقط يقبل الاتصالات التي كانت محلية على المضيف أصلًا، وهذه بالضبط الحالة التي تظل تعمل بينما تفشل حركة النفق. واجهة الرجوع المحلية الخاصة بالعميل عنوان ثالث وليست أبدًا هدف قاعدة البوابة.

لذلك قبل لمس بيانات اعتماد الخادم الأعلى، أثبت حقيقتين: إلى أي عنوان محلي تعيد القاعدة الكتابة، وإلى أي عنوان يرتبط مقبس الوكيل.

اقرأ المستمع وقاعدة إعادة التوجيه معًا

اطبع جدول المقابس وقواعد nat في تمريرة واحدة، لأن قاعدة تشير إلى منفذ لا يملكه أحد تبدو مطابقة لقاعدة تشير إلى العنوان الخطأ. sudo ss -ltnp | grep redsocks يظهر عنوان الربط والعملية المالكة. sudo iptables -t nat -S PREROUTING يظهر هدف REDIRECT، ويظهر sudo iptables -t nat -L PREROUTING -v -n ما إذا كان أي شيء قد طابقه.

القفز إلى سلسلة مستخدم باسم REDSOCKS لا يحقق شيئًا ما لم تكن تلك السلسلة موجودة وتحمل الاستثناءات المقصودة وإجراء REDIRECT. اقرأ السلسلة التي يقفز إليها باستخدام sudo iptables -t nat -S REDSOCKS بدلًا من افتراض أن الاسم يقوم بالعمل.

ثم قارن القيمتين. إذا كانت القاعدة تعيد التوجيه إلى عنوان بوابة على المنفذ 12345 وكان المستمع يبلغ عن 127.0.0.1:12345، فإن عدم التطابق يفسر الفشل دون أي تشخيص إضافي.

اربط بضيق، ثم قيّد ما يمكنه الوصول إليه

الإعداد النموذجي في المنبع يضع المستمع على واجهة الرجوع المحلية لسبب وجيه: الوكيل الشفاف يقبل الاتصالات نيابة عن أي شخص يستطيع الوصول إليه. تغيير الربط إلى 0.0.0.0 يصلح التسليم ويفتح المنفذ في الوقت نفسه على كل الواجهات، وهذا تغيير أمني وليس إصلاحًا محايدًا. فضّل الربط بالعنوان المحلي المحدد الذي تستهدفه إعادة التوجيه، وأبقِ المنفذ مغلقًا على الواجهات غير الموثوقة. إن كان الربط الأوسع لا مفر منه، فأضف قاعدة جدار حماية على المضيف تسمح فقط بنطاق مصدر النفق وحركة البوابة المحلية نفسها.

فتح المنفذ على الواجهة العامة غير مطلوب أبدًا لحركة VPN المعاد توجيهها، لأن الاتصال ينتهي محليًا بعد إعادة الكتابة. لا تعرض الوكيل للإنترنت لجعل إعادة توجيه محلية تعمل.

أثبته باتصال جديد من عميل

اختبر من عميل VPN حقيقي باتصال TCP جديد، لا من صدفة على البوابة. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com على العميل يمارس المسار المعاد توجيهه من طرف إلى طرف.

ثم أكّد أن الاتصال المباشر بالمستمع من شبكة غير موثوقة لا يزال مرفوضًا، وأن اتصال الوكيل الصادر بنفسه لا يُلتقط مرة أخرى بالقاعدة نفسها. يظهر الالتقاط المتكرر كـوكيل يتصل بنفسه ولا يكمل أي طلب أبدًا. أضف وجهة الوكيل إلى مجموعة الاستثناءات، أو علّم حزمه الصادرة حتى تتخطاها السلسلة.

أخيرًا، تذكّر ما لا يغطيه هذا المسار. إعادة توجيه TCP العادية في redsocks لا تحول UDP أو QUIC أو DNS إلى حركة SOCKS، والوجهات الخاصة تحتاج عادة إلى استثناءات صريحة. اختبار محلي ناجح يثبت فقط مسار الرجوع المحلي الذي لم يكن المشكلة يومًا.