كتابة خادم SOCKS4 بسيط بلغة المجمع. ما هو خادم SOCKS ولماذا هو مطلوب؟

المقال مخصص لبروتوكول SOCKS5 - بنيته الداخلية، تطبيق عمليبالإضافة إلى خوادم وعملاء SOCKS المتاحين لمنصة Unix

[فالنتين سينيتسين (فال AT linuxcenter DOT ru)]

قال سافا: "آسف يا بوه". - قام تيجر بمضغ جميع الأسلاك من خادم البريد، ولم يصل البريد لفترة طويلة...
"الأسلاك،" فكر بوه بغضب. - الجوارب متماسكة من هذه الأسلاك.

أندريه شيرباكوف "9600 باود وهذا كل شيء، هذا كل شيء، هذا كل شيء..."

في هذه المقالة سنتحدث عن بروتوكول SOCKS[ حاشية سفلية: "الجوارب" - الإنجليزية. "الجوارب"، "الجوارب"]. بمساعدتها يمكنك حل أكثر من غيرها مهام مختلفة: تنظيم الوصول الآمن إلى الخدمات الموجودة في الخلف جدار الحماية(جدار الحماية)، أو إخفاء عنوان IP الحقيقي الخاص بك أثناء العمل مع موارد الشبكة غير الملائمة، أو تنفيذ خادم وكيل عالمي يدعم أي بروتوكولات مستوى التطبيق(HTTP، FTP، POP3/SMTP، ICQ، وما إلى ذلك). لسوء الحظ، على الرغم من بساطة SOCKS وثرائها، فإن العديد من مسؤولي النظام ليسوا على دراية بها وليس لديهم أي فكرة عن مدى فائدتها. أود أن آمل أنه بعد قراءة هذه المادة، سيأخذ البروتوكول المنسي بشكل غير مستحق مكانه الصحيح في ترسانته. لنقم بالحجز على الفور: ستشير جميع العروض التقديمية اللاحقة إلى الإصدار الخامس من SOCKS، SOCKS5. لا يزال الإصدار الرابع السابق (SOCKS4) متداولًا على الإنترنت، إلا أن إمكانياته محدودة أكثر.

بالمناسبة، لا علاقة لاسم البروتوكول بعناصر الجوارب المذكورة في النقوش وهو اختصار بسيط لـ "SOCK-et-S" - "المآخذ"، أو في ترجمة أكثر دراية لترجمة متخصص في الكمبيوتر الأذن "مآخذ". تم اقتراح هذا المصطلح من قبل المبدعين كخيار عملي، وتم تطبيقه. كما تعلم، فإن المقابس هي أساس أي واجهة برمجة تطبيقات تنفذ اتصالات الشبكة - Unix وWinsock وما إلى ذلك. لإرسال البيانات عبر الشبكة، يحتاج التطبيق ببساطة إلى كتابتها في مأخذ توصيل، على غرار ما يحدث عند تخزين المعلومات في شبكة ملف محلي. وفي كلتا الحالتين، لا داعي للقلق بشأن ما يحدث خلف الكواليس - إضافة بيانات المستخدم معلومات رسمية، يتم تقسيم الأجزاء مع تغليفها اللاحق إلى مخططات البيانات والإرسال الفعلي بواسطة أجزاء أخرى من نظام التشغيل - مكدس TCP / IP وبرامج تشغيل الأجهزة، والتي لا يعرف التطبيق شيئًا عنها. يتيح لك "تقسيم العمل" هذا تغيير إجراء تسليم الرسائل حسب الرغبة، بشرط أن تظل واجهة برمجة التطبيق ثابتة. هذه هي الميزة التي تكمن وراء أيديولوجية SOCKS. تتمثل المهمة الرئيسية لهذا البروتوكول في إدخال وسيط معين يسمى خادم SOCKS أو وكيل SOCKS في عملية تبادل البيانات "العادية". عندما يريد العميل (تطبيق يدعم SOCKS: متصفح الويب Mozilla، عميل ICQ Miranda IM، وما إلى ذلك، انظر أدناه) إرسال أي معلومات عبر الشبكة، فإنه ينشئ اتصالاً ليس مع المستلم الحقيقي، ولكن مع خادم SOCKS، والتي بدورها تقوم بإعادة توجيه البيانات إلى وجهتها، ولكن بالنيابة عنها. من وجهة نظر الخادم "الحقيقي" (على سبيل المثال، موقع الويب الذي يريد المستخدم المشاهدة فيه موزيلا فايرفوكس) وكيل SOCKS هو العميل الأكثر شيوعًا. وبالتالي، يتم إخفاء هوية (عنوان IP) للعميل الحقيقي عن الخادم الذي يخدمه. هذا الظرف المريح للغاية محفوف بالمخاطر المحتملة (يمكنك الاختباء أنت، لكنهم يستطيعون منك)، لذلك، قامت خوادم SOCKS الواقعية بتطوير أنظمة التحكم في الوصول (منع الاتصالات الواردة والصادرة إلى قائمة معينة من العناوين) ودعم ترخيص المستخدم باستخدام كلمة المرور (انظر أدناه).

لاحظ أنه بما أن SOCKS تعمل بمستوى أقل من مستوى التطبيق (أي النقل) لنموذج OSI، فإن دعمها لن يتطلب أي تغييرات في منطق العميل، ناهيك عن الخادم. في الواقع، كل ما هو مطلوب هو تعديل تنفيذ الوظائف المسؤولة عن الخلق إتصال شبكةوإرسال البيانات: Connect() وbind() وsend() وما إلى ذلك. ومن الناحية العملية، يتم تحقيق ذلك عادة عن طريق الاعتراض مكالمات النظاممع استبدالها لاحقًا بنظيراتها الداعمة لـ SOCKS. لا توجد تغييرات على التعليمات البرمجية المصدر تطبيقات العميل، ناهيك عن الوصول إلى النصوص المصدر، كقاعدة عامة، غير مطلوب. يُعرف هذا الإجراء القوي باسم "التسمم" وسيتم مناقشته بالتفصيل أدناه.

الآن بعد أن أصبح لدينا فهم عام لـ SOCKS، يمكننا الانتقال إلى نظرة أكثر تفصيلاً. من هذا البروتوكول.

مواصفات سوكس5

تم وصف بروتوكول SOCKS5 بالتفصيل في RFC1928. على عكس المعايير الوحشية مثل HTTP 1.1، فإن مواصفات SOCKS تتسع لـ 9 صفحات ويمكن لأي شخص تحليلها بسهولة. المعلومات المقدمة هنا هي ملخص مختصر لها وتهدف إلى مساعدتك في هذه المسألة البسيطة.

كما ذكرنا سابقًا، SOCKS5 هو بروتوكول طبقة النقل. يتم استخدام "جيرانها" - TCP و UDP مباشرة لنقل البيانات القادمة من طبقة التطبيق (من تطبيقات مخصصة)، مما يعني أن وكيل SOCKS يجب أن يكون قادرًا على العمل بشكل صحيح مع كل واحد منهم. لاحظ أيضًا أن بروتوكول ICMP الذي تستخدمه الأدوات المساعدة ping وtraceroute يقع أسفل طبقة النقل، وبالتالي، للأسف، لا يمكن تجميعه.[ حاشية سفلية: هناك امتدادات غير قياسية لبروتوكول SOCKS تسمح لك بالعمل مع ICMP، ومع ذلك، لن يتم مناقشتها في هذه المقالة].

قبل إرسال أي بيانات، يجب على العميل أن يمر بإجراءات الترخيص على خادم SOCKS. وللقيام بذلك، فإنه يفتح اتصال TCP بالمنفذ 1080 (القيمة الافتراضية) لخادم SOCKS ويرسل رسالة عبره تحتوي على أرقام التعليمات البرمجية لطرق المصادقة التي يدعمها. يختار خادم SOCKS إحدى الطرق حسب تقديره ويبلغ رقمها للعميل. وترد قائمة ببعض القيم المحتملة في الجدول 1. كما ترون بسهولة، قد تكون المصادقة غائبة (في الممارسة العملية، وهذا يعني على الأرجح أن خادم SOCKS يميز العملاء عن طريق عناوين IP الخاصة بهم) أو على أساس اسم المستخدم وكلمة المرور. في الحالة الأخيرة فمن الممكن عدد كبير من خيارات مختلفة، بدءًا من "مصادقة اسم المستخدم/كلمة المرور" (RFC 1929)، التي تنص على نقل كلمة مرور نص واضح، إلى CHAP (كلمة مرور مشفرة وبيانات واضحة) الأكثر أمانًا وGSSAPI (RFC 1961)، والتي يمكن استخدامها لـ حماية التشفير الكاملة لحركة المرور. بعد التفويض الناجح، يصبح العميل قادرًا على إرسال الطلبات (الأوامر)، وإنشاء الاتصالات الصادرة، وحتى استقبال الاتصالات الواردة.

إنشاء اتصال TCP صادر

لإنشاء اتصال TCP صادر، يرسل العميل طلب "CONNECT" إلى خادم SOCKS، الذي يحدد العنوان ومنفذ التسليم. لتحديد مضيف المستلم، يمكن استخدام كل من عناوين IP (IPv4/IPv6 مدعومة) وأسماء النطاقات المؤهلة بالكامل. في الحالة الأخيرة، يعتني خادم SOCKS بحلها، وبالتالي فإن الشبكة التي يعمل فيها العميل يمكن، من حيث المبدأ، الاستغناء عن خادم DNS. في رسالة الرد، يقوم خادم SOCKS بالإبلاغ عن رمز خطأ (كالعادة، 0 يشير إلى نجاح العملية)، بالإضافة إلى عنوان IP (BND.ADDR) ومنفذ TCP (BND.PORT) الذي سيتم استخدامه فعليًا التواصل مع العقدة المطلوبة. نظرًا لأن خوادم SOCKS تحتوي عادةً على أكثر من واجهة شبكة واحدة، فقد يكون عنوان IP هذا مختلفًا عن العنوان الذي تم إنشاء اتصال التحكم به. يقوم العميل بعد ذلك بفتح جلسة TCP جديدة باستخدام BND.ADDR:BND.PORT ويرسل البيانات. يتم إنهاء اتصال TCP الصادر عند إغلاق جلسة التحكم. لاحظ أنه قد يتم رفض طلب CONNECT بواسطة وكيل SOCKS إذا كان عنوان المصدر (العميل) أو الوجهة (الخادم) محظورًا [ حاشية سفلية: أو غير مسموح بها صراحةً، اعتمادًا على التنفيذ المحدد والسياسة المختارة] ليتم خدمتها من قبل مسؤول النظام.

إنشاء اتصال UDP الصادر

على عكس بروتوكول البث TCP، الذي يتضمن إنشاء جلسة، بروتوكول UDPهو مخطط بيانات، وبالتالي يصعب التعامل معه إلى حد ما. ظهر دعمه فقط في SOCKS5.

قبل إرسال مخططات بيانات UDP، يطلب العميل خادم SOCKS جمعية UDPباستخدام الأمر "UDP ASSOCIATE". يعد اقتران UDP نوعًا من الجلسات الافتراضية بين العميل وخادم SOCKS. في الطلب الصادر، يحدد العميل المزعومالعنوان والمنفذ الذي سيكون بمثابة مصدر لمخططات بيانات UDP المستقبلية. إذا لم تكن هذه المعلومات معروفة بعد عند إنشاء اقتران UDP، فيجب على العميل استخدام المجموعة 0.0.0.0:0 (أو، على سبيل المثال، x.x.x.x:0 إذا كان رقم المنفذ فقط غير معروف). في رسالة الاستجابة، يحدد خادم SOCKS عنوان IP (BND.ADDR) ومنفذ UDP (BND.PORT) الذي يجب إرسال مخططات البيانات الصادرة إليه. في هذه الحالة، تتم الإشارة مباشرة إلى عنوان ومنفذ المستلم الحقيقي في النص (يمكننا القول أن تغليف UDP يحدث). هأنت يتم استخدام المعلمات، بالإضافة إلى عنوان المرسل والمنفذ، لتحديد ما إذا كان يمكن إرسال مخطط البيانات. كما ترون بسهولة، يؤدي هذا إلى إنشاء حمل إضافي على خادم SOCKS: يجب تطبيق قواعد التصفية على كل مخطط بيانات UDP، بينما في حالة اتصال TCP، يتم تقييم شرعيته مرة واحدة، في الوقت الذي ينفذ فيه خادم SOCKS " الأمر "الاتصال". وفقًا للمعيار، يجب أن يتأكد خادم SOCKS من أن عنوان IP الخاص بمرسل مخطط البيانات يتطابق مع عنوان المضيف الذي أنشأ اقتران UDP. يتم إتلاف اقتران UDP في نفس الوقت مع إغلاق جلسة التحكم في TCP التي تم إرسال أمر UDP ASSOCIATE فيها.

تواجه العديد من خوادم SOCKS الحالية مشكلات خطيرة إذا تم وضع جدار الحماية NAT (ترجمة عنوان الشبكة) بينها وبين العميل الذي يطلب اقتران UDP. ويكمن السبب في ذلك في التغيير في عنوان المصدر والمنفذ الذي يحدث في اللحظة التي يعبر فيها مخطط بيانات UDP جدار الحماية. ونتيجة لذلك، يبدأ الخادم وتطبيق العميل المطمئن في التحدث لغات مختلفة: عنوان المصدر المقصود والمنفذ المحدد في أمر "UDP ASSOCIATE" لم يعد يتوافق مع المعلمات الفعلية لمخططات البيانات التي يتلقاها خادم SOCKS. ونتيجة لذلك، يتم تجاهلهم باعتبارهم لا ينتمون إلى جمعية UDP. يمكن حل المشكلة عن طريق تحديد 0.0.0.0:0 باعتباره المصدر المقصود (انظر أعلاه)، والذي يجب أن يفسره خادم SOCKS على أنه "أي مخطط بيانات UDP يأتي من نفس عنوان أمر إنشاء الارتباط". لسوء الحظ، فإن معظم خوادم SOCKS الفعلية تفسر المعيار بشكل أضيق ولا تسمح لك بتعيين كل من العنوان المقصود ومنفذ المرسل على الصفر في نفس الوقت. من بين التطبيقات التي اختبرها المؤلف، فإن "خدعة إعادة توجيه UDP عبر NAT" الموصوفة هنا تسمح بتنفيذ واحد فقط - Dante.

استقبال الاتصالات الواردة

يمكن أن تكون هذه الميزة الأصلية مفيدة في الحالات التي يتم فيها تبديل العميل والخادم "الحقيقي" في المخطط الموضح أعلاه، وهو ما يمكن أن يحدث، على سبيل المثال، في بروتوكولات مثل FTP. ولغرض مزيد من المناقشة، سنفترض أنه تم بالفعل إنشاء قناة اتصال "مباشرة" بين "العميل" (الطرف الذي على وشك قبول الاتصال الوارد) و"الخادم" (الطرف الذي يبدأ الاتصال الوارد) باستخدام الأمر "الاتصال". لفتح قناة "عكسية"، يجب على "العميل" إرسال أمر "BIND" إلى خادم SOCKS، مع تحديد معلماته عنوان IP والمنفذ الذي سيستخدمه لاستقبال الاتصال الوارد. ردًا على ذلك، يقوم خادم SOCKS بالإبلاغ عن عنوان IP والمنفذ المخصص له للحفاظ على القناة "العكسية". ومن المتوقع أن يقوم "العميل" بتمرير هذه المعلمات إلى "الخادم" باستخدام التسهيلات التي توفرها بروتوكولات طبقة التطبيق (على سبيل المثال، أمر FTP "PORT"). بعد أن يقبل خادم SOCKS (أو يرفض) الاتصال الوارد، فإنه يعيد إخطار "العميل"، ويخبره بعنوان IP والمنفذ الذي يستخدمه "الخادم". لاحظ أنه لا يمكن قبول الاتصالات الواردة إلا من خلال تطبيق اهتم مطوروه بدعم SOCKS في مرحلة التصميم. بخلاف ذلك (إذا كان التطبيق يعمل مع خادم SOCKS من خلال برنامج مآخذ توصيل)، فلن يتمكن من تقديم معلومات صحيحة حول عنوان مأخذ التوصيل الذي ينتظر "التعليقات" (أي أنه سيولد أمر "PORT" غير صحيح في مثال FTP الذي تمت مناقشته أعلاه).

جوارب "سلاسل".

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

سيرجي لوكيانينكو "متاهة التأملات"

تجعل بنية بروتوكول SOCKS5 من السهل دمج خوادم SOCKS في مجموعات متتالية، أو كما يطلق عليها أيضًا "السلاسل". من الجدير بالذكر أنه يمكن تنفيذ جميع الإجراءات اللازمة لذلك من جانب العميل. الشرط الوحيد لـ "روابط" السلسلة هو أنها يجب أن "تثق" ببعضها البعض (أي السماح بإنشاء الاتصالات الواردة والصادرة). إذا كانت خوادم SOCKS التي تشكل التتالي ليست مجهولة (أي أنها تستخدم اسم المستخدم/كلمة المرور، أو CHAP، أو أنظمة مصادقة مماثلة)، فمن الضروري أيضًا أن يتمكن المستخدم من إكمال إجراء التفويض بنجاح على كل منها.

لنفترض أن لدينا مجموعة من خوادم N SOCKS تحمل اسم SOCKS1، SOCKS2، ...، SOCKSN، تلبي جميع المتطلبات المذكورة أعلاه. وبعد ذلك، لإنشاء سلسلة، يمكن للعميل القيام بما يلي:

متى اتصال TCP الصادر:يتصل العميل بـ Socks1، ويمر بإجراءات التفويض (إذا لزم الأمر) ويرسل أمر "CONNECT"، مع تحديد Socks2 كعنوان التسليم. من خلال تنفيذ هذا الطلب، ستنشئ الجوارب 1 اتصالًا جديدًا مع الجوارب 2 وستنقل بانتظام جميع المعلومات التي تمر عبرها إلى العميل، في حين لن تخمن الجوارب 2 حتى مع من تتواصل فعليًا. يتم بعد ذلك تكرار الإجراء حتى يتم إنشاء اتصال بين الجوارب (N-1) والجواربN. يتصل الخادم الأخير في السلسلة مباشرة بالعقدة التي تهم العميل. يتم نقل البيانات في الوضع العادي: يرسل العميل الحزمة إلى خادم SOCKS1، والذي بدوره يرسلها إلى SOCKS2، ... وهكذا حتى يتم الوصول إلى العقدة النهائية.

متى اتصال UDP الصادر:يتصل العميل بـ Socks1، ويمر بإجراءات التفويض ويرسل بالتسلسل أمرين: "CONNECT" (عنوان التسليم - Socks2) و"UDP ASSOCIATE". وبالتالي، يتم إنشاء اتصالين جديدين: قناة UDP افتراضية بين العميل وSocks1، وجلسة TCP بين Socks1 وSocks2. باستخدام جلسة TCP هذه، يرسل العميل (نيابة عن الجوارب 1) الأمر "UDP ASSOCIATE" إلى خادم الجوارب 2 (يفتح قناة UDP بين الجوارب 1 وSocks2) و"الاتصال" إلى خادم الجوارب 3. يستمر الإجراء حتى يتم إنشاء قنوات UDP افتراضية بين كافة خوادم SOCKS في السلسلة. لإرسال أي بيانات، يقوم العميل أولاً بإجراء تغليف N-fold لمخطط بيانات UDP، وتحديد SOCKS1، SOCKS2، SOCKS3، SOCKSN وعنوان المستلم الحقيقي بالتسلسل كعنوان التسليم، ثم يرسلها إلى خادم SOCKS1. لاحظ أنه في الممارسة العملية هذا الخيارالمتتالية نادرة للغاية. ويرجع ذلك إلى حقيقة أن خوادم SOCKS، مثل NAT Firewalls، يمكنها تغيير المنفذ المصدر لمخطط البيانات، مما سيؤدي إلى المشكلات الموضحة بالتفصيل في قسم "إنشاء اتصال UDP صادر".

باستخدام سلاسل خوادم SOCKS التي لا تتطلب المصادقة، يمكن للعميل زيادة عدم الكشف عن هويته بشكل كبير أثناء العمل على الإنترنت (انظر النقش). يمكنك العثور على العديد من البرامج على الإنترنت التي تنفذ المخططات الموضحة هنا. هذه، على سبيل المثال، هي SocksChain (http://www.ufasoft.com/socks/ ) لنظام التشغيل Windows أو ProxyChains ( ) ليونكس. تعد خوادم Cascading SOCKS أيضًا جزءًا لا يتجزأ من بعض المضافات، وأبرزها FreeCap (http://www.freecap.ru/ ).

خوادم سوكس

الآن بعد أن أصبحنا على دراية جيدة بمبادئ تشغيل خادم SOCKS، فقد حان الوقت للانتقال من النظرية إلى التطبيق. يوجد عدد كبير من البرامج في العالم التي تطبق بروتوكول SOCKS5. أنها تغطي جميع تلك الشعبية نظام التشغيل(يونكس، ويندوز، ...) وطرق التوزيع (برامج مجانية، برامج تجريبية، مفتوحة المصدر، إلخ). سننظر هنا بإيجاز في التطبيقات الأكثر شهرة (أو المثيرة للاهتمام من وجهة نظر المؤلف).

لنبدأ بالتنفيذ المرجعي لـ SOCKS5 (http://www.socks.permeo.com/)، الذي أعدته شركة NEC وتملكه حالياًشركة بيرميو. النسخة الحاليةمرقمة 1.0r11 ومؤرخة في أغسطس 2000. كما يمكنك تخمينه بسهولة من الاسم، هذا الخادم هو تطبيق مرجعي للبروتوكول، وبشكل عام، ليس مخصصًا للاستخدام الصناعي. ومع ذلك، لأسباب غير واضحة جدًا بالنسبة لي، فقد تم تضمينه في منافذ FreeBSD، وبالتالي فهو معيار فعلي على هذه المنصة. يتمتع المنتج بدعم GSSAPI ويتم توزيعه في كود المصدر، ولكن بموجب ترخيص خاص. يحظر الاستخدام التجاري لهذا الخادم.

يحظى Dante، الذي طورته شركة Inferno Nettverk النرويجية، بشعبية خاصة بين مؤيدي Linux. يتطور المنتج، ولكن ليس بسرعة كبيرة ( احدث اصدار، 1.1.15، بتاريخ 31 يناير 2005) وهو مناسب تمامًا للاستخدام العملي. كما ذكرنا سابقًا، يسمح Dante لاقترانات UDP بالعمل بشكل صحيح حتى لو مرت عبر جدار حماية NAT. يتم توزيع البرنامج في كود المصدر بموجب ترخيص BSD. يشتمل Dante على مكتبة للتجميع الشفاف لتطبيقات Unix (انظر أدناه)

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

على عكس خوادم وكيل HTTP، ينقل SOCKS جميع البيانات من العميل دون إضافة أي شيء من تلقاء نفسه، أي من وجهة نظر الخادم النهائي، فإن وكيل SOCKS هو عميل عادي. تعتبر SOCKS أكثر عالمية - فهي لا تعتمد على بروتوكولات طبقة تطبيق محددة (الطبقة 7 من نموذج OSI) وتعتمد على معيار TCP/IP - بروتوكول الطبقة الرابعة. لكن وكيل HTTP يقوم بتخزين البيانات مؤقتًا ويمكنه تصفية محتوى البيانات المرسلة بعناية أكبر.

تم تطوير هذا البروتوكول بواسطة David Koblas، مسؤول النظام في MIPS Computer Systems. بعد أن أصبحت MIPS جزءًا من Silicon Graphics (SGI) في ذلك العام، ألقى كوبلاس محاضرة عن SOCKS في ندوة Usenix Security Symposium، وأصبحت SOCKS متاحة للجمهور. تم تمديد البروتوكول إلى الإصدار 4 بواسطة Ying-Da Lee من مختبر أنظمة NEC.

بروتوكول الجوارب 4

تم تصميم SOCKS 4 للعمل من خلال جدار الحماية دون مصادقة لتطبيقات خادم العميل التي تعمل عبر TCP، مثل TELNET وFTP وبروتوكولات الاتصال الشائعة مثل HTTP وWAIS وGOPHER. بشكل أساسي، يمكن اعتبار خادم SOCKS بمثابة جدار حماية يدعم بروتوكول SOCKS.

يبدو طلب SOCKS 4 النموذجي على النحو التالي (كل حقل بايت واحد):

طلب العميل إلى خادم SOCKS:

• الحقل 1: رقم إصدار SOCKS، 1 بايت (يجب أن يكون 0x04 لهذا الإصدار)
• الحقل 2: رمز الأمر، 1 بايت:
  • 0x02 = تعيين منفذ TCP/IP (ربط)
• الحقل 3: رقم المنفذ، 2 بايت
• الحقل 4: عنوان IP، 4 بايت
• الحقل 5: معرف المستخدم، سلسلة متغيرة الطول، منتهية ببايت فارغ (0x00). يهدف هذا الحقل إلى تحديد هوية المستخدم (انظر الهوية)

استجابة الخادم لعميل SOCKS:

• الحقل 1: بايت فارغ
• الحقل 2: رمز الاستجابة، 1 بايت:
  • 0x5a = تم قبول الطلب
  • 0x5b = الطلب مرفوض أو غير صالح
  • 0x5c = فشل الطلب لأن المعرف ليس قيد التشغيل (أو لا يمكن الوصول إليه من الخادم)
  • 0x5d = فشل الطلب لأن معرف العميل لم يتمكن من التحقق من صحة معرف المستخدم في الطلب
• الحقل 3: يجب تجاهل 2 بايت عشوائيًا
• الحقل 4: يجب تجاهل 4 بايتات عشوائية

بروتوكول الجوارب 5

يعمل SOCKS 5 على توسيع نموذج SOCKS 4 عن طريق إضافة دعم UDP وتوفير مخططات عالميةمصادقة قوية وتوسيع طرق العنونة عن طريق إضافة دعم لأسماء النطاق وعناوين IPv6. التثبيت الأولييتكون الاتصال الآن مما يلي:

• يتصل العميل ويرسل تحية تتضمن قائمة بطرق المصادقة المدعومة
• يختار الخادم إحداها (أو يرسل استجابة فشل الطلب إذا لم تكن أي من الطرق المقترحة مقبولة)
• اعتمادًا على الطريقة المختارة، قد يتم تمرير عدد من الرسائل بين العميل والخادم
• يرسل العميل طلب اتصال، على غرار SOCKS 4
• يستجيب الخادم، على غرار SOCKS 4

يتم ترقيم طرق المصادقة على النحو التالي:

• 0x00 - لا يلزم المصادقة
• 0x01 - جاسابي
• 0x02 - اسم المستخدم/كلمة المرور
• 0x03-0x7F - محجوز بواسطة IANA
• 0x80-0xFE - محجوز لطرق الاستخدام الخاص

الترحيب الأولي من العميل:

• الحقل 2: عدد طرق المصادقة المدعومة، 1 بايت
• الحقل 3: أرقام طرق المصادقة، طول متغير، 1 بايت لكل طريقة مدعومة

يُبلغ الخادم عن اختياره:

• الحقل 1: إصدار SOCKS، 1 بايت (0x05 لهذا الإصدار)
• الحقل 2: طريقة المصادقة المحددة، 1 بايت، أو 0xFF إذا لم يتم اقتراح طريقة مقبولة

يعتمد التحديد اللاحق على الطريقة المختارة.

طلب العميل:

• الحقل 1: رقم إصدار SOCKS (يجب أن يكون 0x05 لهذا الإصدار)
• الحقل 2: رمز الأمر، 1 بايت:
  • 0x01 = إعداد اتصال TCP/IP
  • 0x02 = تعيين منفذ TCP/IP (ربط)
  • 0x03 = اقتران منفذ UDP
• الحقل 3: البايت المحجوز، يجب أن يكون 0x00
• الحقل 4: نوع العنوان، 1 بايت:
  • 0x01 = عنوان IPv4
  • 0x03 = اسم المجال
  • 0x04 = عنوان IPv6
• الحقل 5: تعيين العنوان
  • 4 بايت لعنوان IPv4
  • 16 بايت لعنوان IPv6
• الحقل 6: رقم المنفذ، 2 بايت

استجابة الخادم:

• الحقل 1: رقم إصدار SOCKS، 1 بايت (0x05 لهذا الإصدار)
• الحقل 2: رمز الاستجابة، 1 بايت:
  • 0x00 = تم قبول الطلب
  • 0x01 = خطأ في خادم SOCKS
  • 0x02 = الاتصال محظور بموجب مجموعة القواعد
  • 0x03 = الشبكة غير متاحة
  • 0x04 = المضيف غير قابل للوصول
  • 0x05 = تم رفض الاتصال
  • 0x06 = انتهت صلاحية مدة البقاء (TTL).
  • 0x07 = الأمر غير مدعوم / خطأ في البروتوكول
  • 0x08 = نوع العنوان غير مدعوم
• الحقل 3: البايت محجوز، يجب أن يكون 0x00
• الحقل 4: نوع العنوان اللاحق، 1 بايت:
  • 0x01 = عنوان IPv4
  • 0x03 = اسم المجال
  • 0x04 = عنوان IPv6
• الحقل 5: تعيين العنوان
  • 4 بايت لعنوان IPv4
  • البايت الأول هو طول الاسم، متبوعًا باسم المجال بدون قيمة فارغة
  • 16 بايت لعنوان IPv6
• الحقل 6: رقم المنفذ، 2 بايت

التنفيذ

• Sun Java System Web Proxy Server - خادم وكيل للتخزين المؤقت لـ Solaris وLinux وWindows. يدعم مرشحات HTTPS وNSAPI I/O وإعادة التكوين الديناميكي والوكيل العكسي.
• DeleGate عبارة عن بوابة متعددة الوظائف على مستوى التطبيق وخادم وكيل يعمل على منصات مختلفة. بالإضافة إلى SOCKS، فهو يدعم أيضًا HTTP(S)، وFTP، وNNTP، وSMTP، وPOP، وIMAP، وLDAP، وTelnet، وDNS والبروتوكولات الأخرى.
• 3proxy - خادم وكيل خفيف الوزن مع دعم SOCKS-proxy
• WinGate هو خادم وكيل متعدد البروتوكولات مع دعم SOCKS لنظام التشغيل Windows.
• يتيح لك OpenSSH إنشاء أنفاق محددة ديناميكيًا من خلال مجموعة فرعية من بروتوكول SOCKS.

أنظر أيضا

• تور- شبكة مجهولةالتوجيه البصلي، مع واجهة SOCKS.

روابط

• RFC 1928 - الإصدار 5 من بروتوكول SOCKS
• RFC 1928 (الروسية) - بروتوكول SOCKS 5
• RFC 1929 - مصادقة اسم المستخدم/كلمة المرور لـ SOCKS V5
• RFC 1961 (الإنجليزية) - طريقة مصادقة GSS-API للإصدار 5 من SOCKS
• SOCKS: بروتوكول لوكيل TCP عبر جدران الحماية - بروتوكول SOCKS 4

مؤسسة ويكيميديا. 2010.

ترى ما هو "الجوارب" في القواميس الأخرى:

جوارب- هو بروتوكول إنترنت يسمح لتطبيقات خادم العميل باستخدام خدمات جدار حماية الشبكة بشفافية. SOCKS هو اختصار لـ SOCKetS [ ]… ... ويكيبيديا

جوارب- للتنقل، يعد Búsqueda SOCKS بروتوكول إنترنت يسمح لخادم عميل التطبيقات باستخدام خدمات جدار الحماية الأحمر بطريقة شفافة. SOCKS هو اختصار لـ SOCKETS. العملاء الذين يفتقدون… … ويكيبيديا الإسبانية

بروتوكول شبكة يسمح لتطبيقات خادم العميل باستخدام الخدمات بشفافية خلف جدران الحماية. SOCKS هو اختصار لـ SOCKetS (المآخذ). عملاء خلف جدار الحماية يحتاجون إلى الوصول إلى... ... ويكيبيديا

جوارب- غرفة الإحاطة في Weißen Hauses Betty Currie und Socks ... ويكيبيديا الألمانية

جوارب- فوق بوبيتري دي لا سالا دي برينسا دي لا كاسا بلانكا. الجوارب (بالإسبانية: Calcetines، مارس 1989، 20 فبراير 2009) هي قطة عائلة رئيس الولايات المتحدة بيل كلينتون خلال فترة رئاسته. Fue la única mascota... ... ويكيبيديا الإسبانية

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

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

وحدات الماكرو وهياكل البيانات المستخدمة في البرنامج

لنقم بإنشاء ملف التضمين، include.inc. في هذا الملفنضع المعايير في كتابة ويندوزبرامج وحدات الماكرو + هياكل للعمل مع SOCKS4. لن أقدم هنا جميع وحدات الماكرو، وسأقدم فقط الوصف والوظيفة اللازمة لحل المشكلة الرئيسية، وكل شيء آخر ستجده في الملف المرفق مع أكواد المصدر.
; SOCKS4 - البنية التي يستخدمها العميل عند طلب الاتصال؛ إلى الخادم المحدد (DSTIP)/المنفذ (DSTPORT) CONNECT_SOCK4 Struc VN Db؟ سي دي ديسيبل؟ دي إس تي بورت دو؟ DSTIP د؟ ديسيبل فارغة؟ CONNECT_SOCK4 ينتهي؛ SOCKS4 - استجابة الخادم الوكيل حول الاتصال. RESPONSE_SOCK4 سترك VN DB ؟ مؤتمر نزع السلاح ديسيبل؟ DSTPORT دو؟ DSTIP د؟ RESPONSE_SOCK4 ينتهي

بشكل عام، لا تختلف بنيات CONNECT_SOCK4 وRESPONSE_SOCK4، لأننا ننفذ البروتوكول دون ترخيص. لكنني قررت أن أتركهم منفصلين حتى أتمكن في المستقبل من تغييرهم بسهولة للتحسين. في الهياكل نفسها، في متغير VN، تتم الإشارة إلى إصدار البروتوكول؛ في حالتنا، يجب أن يكون هناك دائمًا 4؛ في حالة SOCKS5، يحتوي هذا المتغير على 5 (البروتوكول مشابه بشكل أساسي). يتم استخدام متغير القرص المضغوط لإرجاع نتيجة طلب الخادم الوكيل إلى العميل إلى العنوان الذي طلبه العميل (90 - اتصال ناجح / 91 - فشل الاتصال).
لدينا في الواقع ثلاث مراحل في البرنامج.
* أولاً، نقوم بتهيئة المقبس، والاستماع إلى المقبس لطلبات العميل، وإنشاء سلسلة معالجة.
*المرحلة الثانية هي تحليل طلب العميل ومحاولة إنشاء وتوصيل مأخذ توصيل بالخادم الذي طلبه العميل.
* والمرحلة الثالثة والأخيرة هي إرسال البيانات بين مقبس العميل والمقبس الذي قمنا بإنشائه وتوصيله بالعنوان المطلوب.

تنفيذ المرحلة الأولى، تهيئة البرنامج:

; الإجراء الرئيسي هو إجراء البدء لبرنامج WinMain Proc LOCAL ThreadId, hServSock:DWORD LOCAL hostname :BYTE LOCAL _wsa:WSADATA LOCAL _our:sockaddr_in ; إطلاق مكتبة العمل مع المقابس، نستخدم وظيفة الإصدار 1.1؛ دعنا نطلب ذلك كحد أدنى لاستدعاء WSAStartup, 0101h, ADDR _wsa .if eax == 0 ; نأخذ عنواننا، ونجهز هيكلًا لتهيئة مقبس الخادم، استدعاء gethostname، ADDR hostname، 256 استدعاء gethostbyname، ADDR hostname .if eax == 0 استدعاء inet_addr، ADDR hostname .else mov eax، mov eax، mov eax، .endif mov _our sin_addr، eax استدعاء inet_ntoa، eax mov _our.sin_family، AF_INET mov _our.sin_addr.S_un.S_addr، INADDR_ANY xor eax، eax ; أدخل المنفذ الذي نريد الاستماع من خلاله إلى الرسائل الواردة mov ax، SOCKS_PORT استدعاء htons، eax mov _our.sin_port، ax استدعاء المقبس، AF_INET، SOCK_STREAM، 0 .if eax != INVALID_SOCKET ; احفظ مقبس الخادم الذي تم إنشاؤه mov hServSock, eax ; نقوم بربط مقبس الخادم بعنواننا والمنفذ المطلوب باستدعاء bind, hServSock, ADDR _our, SIZEOF sockaddr_in .if eax != SOCKET_ERROR @@: ; قم ببدء المقبس للانتظار واستدعاء الاستماع، hServSock، SOMAXCONN .repeat ؛ لقد وصل العميل، ونتلقى مأخذ توصيل مع العميل الوارد الذي يستدعي قبول، hServSock، NULL، NULL .until eax != INVALID_SOCKET ; قم بإنشاء مؤشر ترابط يتم فيه معالجة العميل الحالي xchg eax, ebx استدعاء CreateThread, NULL, NULL, ADDR المقبسThread, ebx, NULL, ADDR ThreadId ; نترك لانتظار العملاء jmp @B .endif .endif استدعاء Closesocket، hServSock .endif استدعاء ExitProcess، 0 WinMain Endp
هذا هو الإجراء الأول الذي نقوم به، لقد حاولت التعليق على الكود قدر الإمكان حتى تتمكن من اكتشافه، ولكن إذا كان هناك شيء لا يزال غير واضح، فيرجى الاتصال بي أو بـ MSDN. تتم كتابة كافة التعليمات البرمجية بشكل أساسي باستخدام بناء جملة MASM وWinAPI. يجب أن تكون نتيجة الوظيفة المذكورة أعلاه عبارة عن مقبس عمل على أحد عناوين الشبكة الخاصة بجهازك (عنوان محلي، أو عنوان خارجي إذا كان لديك IP حقيقي) + بناءً على اتصال العميل، تقوم الوظيفة بإنشاء خيط منفصل يستخدم للعمل مع العميل الوارد. والآن دعنا ننتقل...

المرحلة الثانية: تحليل طلب العميل

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

المقبسThread Proc sock:DWORD LOCAL lpMem, _csock, ThreadId, dAmount:DWORD LOCAL Remote:sockaddr_in LOCAL wrFds, rdFds:fd_set LOCAL hResp:RESPONSE_SOCK4 ; الاستعداد لقراءة البيانات من مأخذ التوصيل استدعاء FdZero، ADDR rdFds استدعاء FdSet، sock، ADDR rdFds استدعاء Select، NULL، ADDR rdFds، NULL، NULL، NULL ؛ نحصل على حجم البيانات التي تنتظر القراءة باستدعاء ioctlsocket, sock, FIONREAD, ADDR dAmount ؛ نحن نحتفظ بالذاكرة للبيانات mov lpMem, @Result(LocalAlloc, LMEM_FIXED أو LMEM_ZEROINIT, dAmount) ؛ قراءة بيانات الطلب من مأخذ التوصيل استدعاء recv, sock, lpMem, dAmount, 0 ; جاء الطلب lea edi, hResp mov esi, lpMem ; يحتوي Esi على طلب مستخدم. نحن نتعامل (هنا) فقط مع إصدار SOCKS4؛ يمكن، من حيث المبدأ، معالجة SOCKS5 هنا، لكن ذلك سيأتي لاحقًا... افترض Esi: Ptr CONNECT_SOCK4 افترض Edi: Ptr RESPONSE_SOCK4 .if .VN == 4 ; تنفيذ بروتوكول SOX 4 .if .CD == 1 استدعاء المقبس، AF_INET، SOCK_STREAM، 0 .if eax != INVALID_SOCKET mov _csock، eax ; نحن نأخذ بيانات المضيف البعيد الذي يريد العميل الاتصال به mov Remote.sin_family، AF_INET mov ax، .DSTPORT mov Remote.sin_port، ax mov eax، .DSTIP mov Remote.sin_addr، eax mov cx، .DSTPORT mov edx .DSTIP ; يحتوي Edi على إجابة المستخدم mov .VN, 0 mov .DSTPORT, cx mov .DSTIP, edx ; نحن نحاول التواصل مع السيرفر المتحكماستدعاء الاتصال، _csock، ADDR Remote، SIZEOF Remote .if !eax ; نحن نقوم بإعداد الرد الذي قمنا بتوصيله mov .CD, 90 ; نرسل للعميل استجابة تحتوي على نتيجة محاولة الاتصال استدعاء إرسال، سوك، ADDR hResp، SIZEOF RESPONSE_SOCK4، 0؛ نقوم بتشكيل هيكل يحتوي على معلومات حول الخادم و؛ مآخذ العميل المتصلة؛ - بالخادم هنا أقصد المقبس المتصل بالعميل؛ من أرسل الطلب؛ - أعني بالعميل مأخذ توصيل متصل بالخادم؛ الذي طلب العميل بياناته mov ebx, @Result(LocalAlloc, LMEM_FIXED أو LMEM_ZEROINIT, SIZEOF THREAD_DATA) افترض Ebx: Ptr THREAD_DATA mov eax, _csock mov .Server, eax mov eax, sock mov .Client, eax افترض Ebx: لا شيء ؛ نبدأ مؤشر ترابط معالجة المقبس (القراءة من العميل والإرسال إلى مقبس الخادم) باستدعاء CreateThread, NULL, NULL, ADDR ClientSock, ebx, NULL, ADDR ThreadId .else ؛ إذا فشل الاتصال، قم بإغلاق مأخذ توصيل العميل واستدعاء Closesocket, _csock ؛ نقول أنه حدث خطأ في الاتصال mov , 91 ; نرسل للعميل استجابة تحتوي على نتيجة محاولة الاتصال، استدعاء إرسال، سوك، ADDR hResp، SIZEOF RESPONSE_SOCK4، 0 .endif .endif .endif .endif افتراض Edi: لا شيء يفترض Esi: لا شيء؛ تحرير الذاكرة المخصصة للطلب، استدعاء LocalFree، lpMem ret مأخذ التوصيلThread Endp
نتيجة هذا الإجراء هي مأخذ توصيل متصل، بالإضافة إلى مؤشر ترابط تم إنشاؤه ينفذ تبادل البيانات بين مآخذ توصيل. انه سهل. على المرء فقط أن يوضح أنه يتم استخدام العديد من نقاط العنونة هنا ضمن الهياكل التي تم تقديمها في MASM لتسهيل حياة المبرمج. النقطة الأولى، الماكرو "الافتراض".
يخبر السطر Assume Esi: Ptr CONNECT_SOCK4 المترجم أن هذا السجل (Esi) يحتوي على عنوان بنية CONNECT_SOCK4، مما يزيد من تبسيط الوصول إلى المتغيرات داخل هذه البنية. افترض Esi: لا شيء يلغي الارتباط. لفهم ذلك بشكل أفضل، قد يكون من الأسهل إذا قمت بإدراج بعض خيارات المعالجة:
افترض Esi:Ptr CONNECT_SOCK4 mov al, .VN ; نضع في AL قيمة البايت من بنية VN المتغيرة mov al, .CD ; ضع فأس القرص المضغوط المتغير في AL. .DSTPORT. ضع متغير DSTPORT في AX افترض Esi:Nothing
أو
موف آل، . ضع قيمة البايت من متغير VN في AL mov al, ; ضع الفأس المتغير CD mov، ; ضع المتغير DSTPORT في AX
أو
موف آل، بايت بتر؛ ضع المتغير VN في AL mov al, byte ptr ; ضع متغير القرص المضغوط في AL mov ax, word ptr ; ضع المتغير DSTPORT في AX

أعتقد أنه من الواضح بالنسبة لك، تمامًا كما هو الحال بالنسبة لي، أنه من الأسرع والأكثر ملاءمة والأكثر وضوحًا استخدام الخيار الأول. على الرغم من أنه إذا كان من الضروري الإشارة إلى متغير واحد من البنية، فإن الخيار الثاني له الحق في الوجود. أعتقد أنه من الأفضل استخدام الخيار الثالث في الحالات التي تكون فيها البيانات الموجودة على العنوان غير منظمة. ولكن، كما تعلمون، كل ذئب تامبوف له طعمه ولونه الخاص. استخدم الطريقة الأكثر ملاءمة لك.
نقطة أخرى تستحق التوضيح. النتيجة الكلية. تمت كتابة هذا الماكرو بحيث يمكنك استدعاء وظيفة WinAPI في سطر واحد وكتابة نتيجة التنفيذ إلى السجل أو الذاكرة. لذلك الخط:
mov lpMem, @Result(LocalAlloc, LMEM_FIXED أو LMEM_ZEROINIT, dAmount)
يقوم أولاً بإجراء مكالمة مثل هذا:
استدعاء LocalAlloc أو LMEM_FIXED أو LMEM_ZEROINIT أو dAmount
وبعد التنفيذ هذه المكالمةيتم تخزين نتيجة التنفيذ (Eax) في متغير lpMem. في هذا حالة محددة، سيتم تخصيص الذاكرة، وسيتم كتابة العنوان الذي توجد به المنطقة المخصصة لنا إلى المتغير.

المرحلة الثالثة، نقل البيانات

وبذلك تكون قد اكتملت المرحلتان الأكثر صعوبة. وصل العميل، وقمنا بتوصيله بالخادم البعيد، وحان الوقت لأبسط عمل "قرد". نقل البيانات بين مآخذين. دعونا نفعل ذلك بسرعة وسهولة:
; دفق يقرأ من مقبس العميل ويرسله إلى مقبس الخادم.... ClientSock Proc Param:DWORD LOCAL sserver, sclient:DWORD LOCAL rdFds:fd_set LOCAL dAmount, lpBuf: DWORD ; في Param لدينا معلومات حول مآخذ الخادم والعميل؛ النقل إلى المتغيرات المحلية mov ebx، Param Assume Ebx: Ptr THREAD_DATA mov eax، .Server mov sserver، eax mov eax، .Client mov sclient، eax Assume Ebx: Nothing ؛ لا تنس تحرير الذاكرة، استدعاء LocalFree، Param @@: استدعاء FdZero، ADDR rdFds استدعاء FdSet، sserver، ADDR rdFds استدعاء FdSet، sclient، ADDR rdFds استدعاء حدد، NULL، ADDR rdFds، NULL، NULL، NULL ؛ تحقق مما إذا كانت هناك بيانات للقراءة. إذا eax == SOCKET_ERROR || إيكس == 0 ; لا توجد بيانات - قم بالخروج من jmp @F .endif ; هل هناك بيانات من الخادم يجب تمريرها إلى العميل؟ استدعاء FdIsSet، sserver، ADDR rdFds .if eax ؛ نحصل على حجم البيانات التي تنتظر القراءة باستدعاء ioctlsocket, sserver, FIONREAD, ADDR dAmount ؛ الذاكرة الاحتياطية للبيانات mov lpBuf, @Result(LocalAlloc, LMEM_FIXED أو LMEM_ZEROINIT, dAmount) استدعاء recv, sserver, lpBuf, dAmount, 0 .if eax == SOCKET_ERROR || eax == 0 jmp @F .endif استدعاء إرسال, sclient, lpBuf, eax, 0 استدعاء LocalFree, lpBuf .endif ; هل هناك بيانات من العميل لإرسالها؟ مقبس الخادم؟ استدعاء FdIsSet، sclient، ADDR rdFds .if eax ؛ نحصل على حجم البيانات التي تنتظر القراءة باستدعاء ioctlsocket, sclient, FIONREAD, ADDR dAmount ؛ الذاكرة الاحتياطية للبيانات mov lpBuf, @Result(LocalAlloc, LMEM_FIXED أو LMEM_ZEROINIT, dAmount) استدعاء recv, sclient, lpBuf, dAmount, 0 .if eax == SOCKET_ERROR || eax == 0 jmp @F .endif استدعاء إرسال, خادم, lpBuf, eax, 0 استدعاء LocalFree, lpBuf .endif ; لننتقل إلى دورة جديدة jmp @B @@: ; قم بإغلاق المقابس واستدعاء Closesocket واستدعاء الخادم Closesocket وsclient ؛ قم بالخروج من مؤشر ترابط الاستدعاء ExitThread، 0 ClientSock Endp
في البداية، يقوم هذا الإجراء بتهيئة المتغيرات الداخلية من البنية التي تم تمريرها إلى الدفق لجعلها أكثر ملاءمة للاستخدام. بعد ذلك، في الحلقة، يتم إجراء فحص لمعرفة ما إذا كانت هناك بيانات يمكن قراءتها من المقابس، ثم في قطعتين من التعليمات البرمجية (في الواقع نسخ ولصق، هنا لم أزعج نفسي بإزالة الوظيفة وتحسينها لأنها أكثر وضوحًا ) اقرأ من مأخذ واحد وأرسله إلى الثاني.
هذا كل شيء، يا هلا! دعونا نجمع ونحاول. من حيث المبدأ، فإن الخيار الأفضل هو فايرفوكس. في إعدادات الاتصال، نحدد أنك بحاجة إلى استخدام خادم وكيل SOCKS4. نشير إلى عنوانه والميناء الذي يقع عليه. بعد ذلك نحفظ الإعدادات ونستمتع بالإنترنت الذي يمر عبر الوكيل الخاص بنا بحجم 3.5 كيلو بايت))) نعم سأوضح ذلك. للتجميع من الضروري تثبيت الحزمة

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

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

وصف عام ومفصل للجوارب

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

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

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

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

خاتمة

هذا كل شيء. آمل الآن أن تفهم تقريبًا على الأقل ما هو عليه بشكل عام ولماذا قد يكون ضروريًا بشكل عام.

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

كما هو الحال دائمًا، إذا كانت لديك أي أسئلة أو أفكار أو إضافات وما إلى ذلك، فنحن نرحب بك للتعليق على هذه المادة.