اتصال IPv6 فقط، خدمة IPv4: دع وكيل SOCKS يجسر بينهما

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

مقبسان، عائلتا عناوين

يسمي طلب SOCKS5 الوجهة بأحد ثلاثة أشكال: عنوان v4 حرفي، أو عنوان v6 حرفي، أو اسم ليحله الوكيل. يصف الطلب أين يجب أن يتصل الوكيل، لا كيف يبدو اتصال العميل بالوكيل.

اقرأ أنواع العناوين هذه كثلاثة خيارات مستقلة داخل رسالة واحدة. يمكن لوكيل يُبلغ عبر IPv6 أن يفتح مقبس وجهة IPv4 متى كان لديه خروج IPv4 عامل وسمحت سياسته بالطلب. تحدد مواصفة SOCKS5 هذه الأنواع دون أي إشارة إلى نقل العميل.

مثال SSH مضبوط

خذ مضيف SSH مصرحاً لك باستخدامه، يجيب على IPv6 ويستطيع بنفسه الوصول إلى خدمة HTTPS موجودة على v4 فقط. تضع إعادة التوجيه الديناميكي في OpenSSH مستمع SOCKS محلياً على جهازك بينما تجري جلسة الدخول عبر v6.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

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

مع تشغيل الجلسة، يبدو الطلب هكذا:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

اتصال الاسترجاع ليس مسار إنترنت IPv4. ما يغادر جهازك هو جلسة الدخول عبر v6، والطرف الآخر هو من يفتح مقبس الوجهة. صيغة socks5h تفوض أيضاً تحليل الأسماء إلى ذلك الطرف، وهذا مهم حين لا يملك العميل مسار محلل IPv4 خاصاً به.

ما تراه الوجهة فعلاً

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

التمرير هو أيضاً المكان الذي يظهر فيه نصفا المحادثة، وهذه خاصية مفيدة أثناء التشخيص وعبء إن كان التمرير مشتركاً بلا سياسة.

هذا ليس DNS64 أو NAT64

يجيب DNS64 بسجلات مُولَّفة تنوب عن وجهات v4، ويعيد NAT64 كتابة الحزم على مسار مُهيأ. لا يصف أي منهما ما يحدث هنا، حيث تنتهي محادثة نقل وتبدأ أخرى ولا يفسر أي عنوان مُولَّف النتيجة. لذا لا يقول طلب ناجح شيئاً عن خدمات الترجمة التي يشغلها مزودك، وقد يشغل الوكيل NAT عادياً على خرجه.

يمكن أن يوجد أي من الآليتين في الشبكة نفسها، لذا صف ما تحققت منه فعلاً بدل ما يبدو أقرب.

اعرف النطاق قبل أن تعد به

تحمل إعادة التوجيه الديناميكي في OpenSSH اتصالات TCP، لا حركة IP عشوائية، لذا تحتاج UDP وICMP وأي بروتوكول يتجاهل الوكيل إلى تصميم مدعوم مختلف. حافظ على التحقق من مفتاح مضيف SSH وعلى قيود إعادة التوجيه في الخادم وعلى التحقق من شهادة HTTPS، لأن الوكيل مشارك موثوق إضافي وليس سبباً لإضعاف فحوص الهوية. إن كان الهدف حمل النقل الخارجي لـ VPN عبر الوكيل، فتحقق من أن الطرفين يدعمان ذلك النقل بدل افتراض أن أي مستمع SOCKS يمكنه تمريره.

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