المصادقة لدى الوكيل: قائمة IP المسموح بها أم اسم المستخدم وكلمة المرور؟

قاعدة معارف ProxyCompass

المصادقة لدى الوكيل: قائمة IP المسموح بها أم اسم المستخدم وكلمة المرور؟

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

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

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

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

كيف تعمل طريقتا المصادقة؟

المصادقة عبر IP: إذن لمصدر اتصال

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

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

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

اسم المستخدم وكلمة المرور: إذن يقدمه التطبيق

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

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

تخص بيانات الاعتماد الاتصال بالوكيل. وليست تلقائيًا كلمة مرور لوحة تحكم المزود، ولا تسجلك في موقع الوجهة. فالموقع يظل يطبق قواعد دخوله ووصوله الخاصة. ويتناول دليل المصادقة باسم المستخدم وكلمة المرور حقول الاتصال وبرامج العميل المدعومة وصيغ بيانات الاعتماد.

المصادقة عبر IP مقابل اسم المستخدم وكلمة المرور

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

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

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

كيف تختار لتطبيقك وشبكتك؟

تحقق أولًا من قدرة التطبيق على استخدام الطريقة المعروضة

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

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

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

لذلك ينبغي أن يكون الفحص المفيد قبل الشراء محددًا: هل يستطيع هذا التطبيق استخدام بروتوكول الوكيل هذا مع طريقة المصادقة هذه؟ والنجاح في متصفح آخر أو أداة سطر أوامر لا يحسم هذا السؤال.

ثم انظر إلى ما يتغير عادة في إعدادك

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

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

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

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

إذا عملت الطريقتان، فاختر الترتيب الأسهل إدارة

يمكن لمسؤول الشبكة إدارة قائمة IP المصدر المسموح بها، ويمكن للمطور إدارة بيانات اعتماد الوكيل في إعدادات التطبيقات. اختر الأسهل لسير عملك.

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

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

المصادقة المجمعة: IP وكلمة مرور

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

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

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

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

أي طريقة تمنح تحكمًا أفضل في الوصول؟

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

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

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

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

هل تجعل المصادقة عبر IP الوكيل أسرع؟

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

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

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

هل يمكن أن تكشف المصادقة أن عنوانًا يشغّل وكيلًا؟

نعم. قد تمنع كلمة المرور الاستخدام غير المصرح به، لكنها تظل تتيح لنظام خارجي التعرف على الخدمة. مثلًا، تستطيع أداة فحص الاتصال بعنوان وكيل HTTP ومنفذه دون بيانات اعتماد صحيحة. وتبين استجابة 407 Proxy Authentication Required مع رأس Proxy-Authenticate صراحة وجود متطلب مصادقة لدى الوكيل. ولا تحتاج أداة الفحص إلى معرفة كلمة المرور لتلقي هذا الدليل.

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

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

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

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

العودة إلى قاعدة المعرفة