وكلاء SOCKS5 وSOCKS4

يتيح خادم وكيل SOCKS للتطبيق طلب الاتصال بوجهة عبر خادم وسيط. ويفتح الوكيل الاتصال المطلوب ويمرّر البيانات في الاتجاهين. ويواصل التطبيق استخدام بروتوكوله الخاص، لذلك يعمل هذا مع طلبات الويب وعملاء API ونقل الملفات وغيرها من البرامج التي تدعم SOCKS.

لإعداد جديد، يوفر SOCKS5 عادةً الخيارات الأكثر فائدة: صيغ عناوين أكثر، واختيارًا بين طرق مصادقة، ودعم UDP. ويبقى SOCKS4 مفيدًا للبرامج التي تتطلب الإصدار الأقدم. وتتناول مقالة وكلاء SOCKS وHTTP الاختيار الأوسع بين هذه البروتوكولات ووكلاء HTTP.

كيف يتصل تطبيق عبر SOCKS

لنأخذ تطبيقًا يفتح https://example.com/ عبر وكيل SOCKS5. يصل أولًا إلى الوكيل، ويطلب منه فتح اتصال بالموقع، وبعد ذلك فقط يتبادل بيانات الموقع. وللعملية أربع مراحل:

1. يتصل التطبيق باسم مضيف الوكيل أو عنوان IP الخاص به ومنفذ الاستماع عبر TCP.
2. يختار التطبيق والوكيل طريقة وصول. وإذا كانت تتطلب بيانات اعتماد، يقدمها التطبيق ويتحقق منها الوكيل.
3. يرسل التطبيق طلب SOCKS CONNECT بعنوان الوجهة ومنفذها. ويفحص الوكيل قواعد الوصول لديه، ويحاول إنشاء الاتصال التالي، ويبلغ بالنتيجة.
4. بعد رد ناجح، يتواصل التطبيق مع الوجهة عبر الوكيل. ولموقع HTTPS، ينشئ TLS مع الموقع ويتحقق من شهادته قبل إرسال طلب الويب.

ينتمي رقما المنفذين إلى خادمين مختلفين. فقد يستمع وكيل توضيحي على proxy.example:1080، بينما يُوصل إلى الموقع عند example.com:443. والمنفذ 1080 معتاد لSOCKS، لكن قد تستخدم الخدمة منفذًا آخر. استخدم منفذ الاستماع المخصص لوكيلك؛ فهو لا يحل محل منفذ الوجهة.

أثناء تمرير TCP العادي، ينقل SOCKS تدفق بايتات التطبيق دون الحاجة إلى تفسير كل طلب HTTP أو أمر ملف. ويواصل التطبيق التحدث ببروتوكوله الخاص مع الوجهة. ولهذا تستطيع آلية اتصال SOCKS نفسها خدمة عملاء الويب وأنواع برامج أخرى.

CONNECT أمر داخل SOCKS له صيغة رسائل خاصة به؛ وهو مختلف عن طريقة HTTP CONNECT. ويعرّف SOCKS أيضًا BIND للتطبيقات التي تحتاج إلى اتصال خادم عائد عبر الوكيل، كما قد يحدث في FTP النشط. ويحتاج BIND إلى دعم منفصل، ولا يُستخدم في طلب موقع أو API عادي.

ما الذي يتغير بين SOCKS4 وSOCKS4a وSOCKS5

يفتح SOCKS4 اتصالات TCP بعناوين IPv4. ويضيف SOCKS4a خيار إرسال اسم مضيف ليجد الوكيل عنوان IP له عبر DNS. ويضيف SOCKS5 اختيار طرق المصادقة، ويقبل عناوين IPv4 وIPv6 وأسماء المضيفين، ويعرّف تمرير UDP.

هذه قدرات البروتوكول. ويجب أن ينفذ التطبيق العميل وخدمة الوكلاء الميزة المحددة التي تنوي استخدامها. فمثلًا، قد تتعامل خدمة SOCKS5 مع اتصالات TCP دون توفير تمرير UDP قابل للاستخدام.

يمكن أن يحمل طلب SOCKS5 عنوان وجهة IPv6، لكن يجب أن يستطيع الوكيل أيضًا الوصول إلى خادم IPv6 ذاك. ويمكن أن يستخدم الاتصالان إصدارَي IP مختلفين: فقد يصل التطبيق إلى الوكيل عبر IPv4، بينما يتصل الوكيل بالوجهة عبر IPv6.

SOCKS4a امتداد لSOCKS4، وليس اسمًا آخر لكل اتصال SOCKS4. وإذا كان عميل قديم يرسل عناوين IPv4 فقط، فلا يمنحه اختيار SOCKS4 تحليل DNS عن بعد. ويتطلب SOCKS4a دعم الطرفين. وعادةً يكون SOCKS5 الخيار الأبسط حين يدعمه الطرفان؛ ولا يحسن اختيار SOCKS4 وحده سمعة عنوان IP للخروج أو سرعته.

من يحلل اسم الوجهة

قبل وصول اتصال إلى خادم مسمى، يجب تحويل اسمه إلى عنوان IP. ويمكن لSOCKS5 قبول نتيجة ذلك البحث أو الاسم نفسه. ويحدد إعداد DNS في التطبيق العميل أيهما يرسل.

مع DNS المحلي، يسأل التطبيق محلل الأسماء المضبوط لديه عن reports.example. وافترض أن الإجابة 203.0.113.27: يطلب التطبيق بعد ذلك اتصال SOCKS إلى 203.0.113.27:443. وقد حدث البحث أصلًا من جهة التطبيق العميل، مع أن اتصال الموقع اللاحق يمر عبر الوكيل.

مع DNS من جهة الوكيل، يرسل التطبيق reports.example:443 دون البحث محليًا عن تلك الوجهة أولًا. ويحصل الوكيل على عنوان IP عبر DNS، ويفتح الاتصال المطلوب. ويصل اسم المضيف إلى الوكيل كجزء من طلب SOCKS.

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

في curl، يختار الأمران التاليان وضعَي DNS:

curl --proxy socks5://proxy.example:1080 https://example.com/
curl --proxy socks5h://proxy.example:1080 https://example.com/

يجعل socks5:// أداة curl تحلل اسم الموقع محليًا؛ ويمرّره socks5h:// إلى الوكيل. ويستخدم كلاهما SOCKS5. وتعني h تحليل اسم المضيف لدى الوكيل في صيغة URL لهذا العميل. ولا تحول SOCKS5 إلى HTTPS ولا تضيف تشفيرًا. وقد تستخدم تطبيقات أخرى مربع اختيار أو تختار DNS البعيد تلقائيًا. استبدل اسم مضيف الوكيل التوضيحي ومنفذه ببيانات خدمتك، وقدم المصادقة المطلوبة.

لا يتطلب تمرير اسم نطاق في طلب SOCKS5 TCP دعم تمرير UDP. فالوكيل يجري البحث باستخدام إعداد DNS الخاص به. وهذا مختلف عن مطالبة SOCKS5 بنقل رزم UDP الخاصة بالتطبيق العميل.

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

المصادقة والتشفير

يتيح SOCKS5 للتطبيق العميل عرض طرق المصادقة التي يدعمها، وللوكيل اختيار واحدة منها. واسم المستخدم وكلمة المرور أحد الخيارات. والخيار الآخر اتصال دون تبادل تسجيل دخول SOCKS، قد تسمح به الخدمة بعد مطابقة عنوان IP المصدر للتطبيق العميل مع قائمة السماح. ولذلك قد تظل نقطة اتصال دون حقل كلمة مرور تقيد الوصول.

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

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

أثناء تمرير SOCKS العادي، يحمي HTTPS تبادل التطبيق مع الموقع، مع تفعيل التحقق من الشهادة ودون اعتراض TLS. ويبقى بروتوكول تطبيق غير مشفر دون تشفير عبر المُرحّل. ولا يعد دعم SOCKS5 أو المصادقة بكلمة مرور وحده بحركة بيانات مشفرة.

ما زال الوكيل يعرف عنوان IP الذي يتصل منه التطبيق العميل، والوجهة المطلوبة، وتوقيت الاتصال. وترى الوجهة عنوان IP للخروج من الوكيل وتتلقى بيانات التطبيق المقصودة لها. وقد تظل ملفات تعريف الارتباط وتسجيل الدخول ومعرّفات التطبيق الأخرى تحدد المستخدم؛ ولا يزيلها تغيير إصدار SOCKS.

كيف ينقل SOCKS5 بيانات TCP وUDP

يوفر TCP تدفق بايتات مرتبًا. ويمكن لطلب متصفح أو استدعاء API أو جلسة SSH استخدام اتصال SOCKS TCP حين يدعم التطبيق العميل ذلك المسار ويسمح الوكيل بالوجهة. ولا يثبت النجاح على منفذ الموقع 443 توافر منفذ تطبيق آخر.

يرسل UDP رزم بيانات منفصلة. ويفتح عميل SOCKS5 أولًا اتصال تحكم TCP، ويطلب مُرحّلًا باستخدام UDP ASSOCIATE. ويعيد الوكيل عنوان المُرحّل ومنفذ UDP. ويرسل التطبيق العميل رزم بياناته إلى هناك مع رؤوس SOCKS التي تصف وجهاتها. وينهي إغلاق اتصال التحكم TCP ارتباط UDP هذا؛ وتنتقل رزم البيانات بصورة منفصلة عن اتصال التحكم، لا داخل تدفق SOCKS CONNECT عادي.

يجب أن يدعم التطبيق والخدمة هذه الآلية، وأن تسمح الشبكة بمسار UDP. وقد يكمل برنامج تسجيل الدخول عبر TCP بينما تظل وظيفة الصوت أو اللعبة أو غيرها من وظائف UDP تفشل. ويُظهر طلب HTTPS ناجح عبر SOCKS CONNECT تمرير TCP، لا عمل UDP. ويستخدم QUIC بروتوكول UDP، لكن إمكان استخدام QUIC يعتمد أيضًا على التطبيق العميل والمسار الكامل؛ ولا تثبته تسمية SOCKS5 وحدها.

متى يفيد SOCKS

يفيد SOCKS عندما يحتاج البرنامج إلى اتصال وسيط مع الاحتفاظ ببروتوكول التطبيق الخاص به. فيستطيع برنامج نصي طلب بيانات API عبر عنوان IP مخصص للخروج، ويستطيع عميل نقل ملفات الوصول إلى خادم بعيد عبر مسار معتمد، ويستطيع تطبيق سطح مكتب متوافق استخدام وكيل دون أن يكون متصفح ويب. وتعتمد كل حالة على دعم العميل لSOCKS ومنافذ الوجهة التي تسمح بها الخدمة.

للعمل المتكرر مع الحساب أو الخادم نفسه، قد تناسب نقطة خروج ثابتة. وللمهام المنفصلة، قد تفيد خدمة متناوبة. ولا يحدد SOCKS4 وSOCKS5 هذا السلوك: فالخدمة تحدد عنوان IP للخروج ونوع شبكته ومشاركة عملاء آخرين فيه وموعد تغيره. كذلك لا يقدم إصدار البروتوكول ترتيبًا للسرعة؛ بل تؤثر مسافة المسار وحمل الخادم وعرض النطاق المتاح في النتيجة.

قد يكون دعم التطبيق العميل أضيق من البروتوكول. فتنفيذ SOCKS5 المدمج في Chrome يحلل أسماء الوجهة عبر الوكيل، لكنه لا يجري مصادقة SOCKS5 باسم المستخدم وكلمة المرور ولا يمرّر UDP. ولذلك قد تعمل نقطة اتصال لا تقبل إلا كلمة مرور في curl وتفشل عبر إعداد المتصفح المدمج. والمحول الخارجي جزء منفصل من الاتصال بقدراته الخاصة.

ينطبق الوكيل المضبوط داخل برنامج واحد على اتصالات ذلك البرنامج المدعومة. ولا يضبط أداة تنزيل أو برنامجًا نصيًا منفصلًا. وكذلك تؤثر إعدادات وكيل النظام في البرامج التي تستخدمها. وعندما يعيد محول توجيه اتصالات تطبيق لا يدعم SOCKS أصلًا، يهم نطاق تغطيته لTCP وUDP وDNS. ولا يوفر SOCKS تمرير ICMP المعتاد، لذا لا يعد ping اختبارًا لهذا المسار عبر الوكيل.

إعدادات الاتصال واختبار مفيد

ابدأ بعنوان الوكيل ومنفذ الاستماع وإصدار SOCKS وطريقة الوصول الموفرة لنقطة الاتصال. ولا يحدد رقم مثل 1080 البروتوكول بحد ذاته. واختر SOCKS في التطبيق العميل بدل إدخال العنوان نفسه في حقل وكيل يدعم HTTP فقط.

تفوّض بيانات اعتماد الوكيل استخدام الوسيط، بينما يفوّض تسجيل الدخول إلى الموقع استخدام الموقع. وتنتمي إلى إعدادات مختلفة. وفي curl، يزود --proxy-user بيانات اعتماد الوكيل، بينما يزود --user بيانات اعتماد الوجهة. وللوصول عبر IP، يجب أن تطابق قائمة السماح عنوان IP المصدر للتطبيق العميل كما يراه الوكيل، وقد يتغير عندما ينتقل التطبيق العميل بين الشبكات.

اختر وضع DNS المقصود، ثم افحص قواعد التجاوز. فقد يُتخطى الوكيل المضبوط لوجهات ضمن قائمة استثناء. وفي curl، قد يسبب NO_PROXY ذلك؛ ويمسح --noproxy "" تلك الاستثناءات لاستدعاء واحد عندما تريد عمدًا اختبار مسار الوكيل.

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

ثم جرّب المهمة الحقيقية. فتغير IP يبين مسار الطلب المختبر، لكنه لا يقيس جميع وسائل النقل ولا يثبت استجابة موقع آخر. اختبر UDP أو IPv6 بصورة منفصلة عندما تتطلبهما المهمة، وقيّم زمن الاستجابة واستقرار الاتصال تحت حمل عمل ممثل.

تحديد الخطأ بحسب مرحلة الاتصال

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

إذا نجح اتصال HTTPS مع التحقق من الشهادة، وأعاد الموقع صفحة تسجيل دخول أو CAPTCHA أو رفض وصول، فقد حمل اتصال SOCKS ذلك التبادل بالفعل. فافحص استجابة الموقع وسلوك التطبيق. أما إذا أظهر الطلب عنوان IP العام المعتاد لك، فتحقق من الوكيل المختار وقواعد التجاوز في ذلك البرنامج.