المنافذ المحظورة
يمكن لمزود خدمة الخوادم الوكيلة منع الاتصالات بمنافذ شبكية معينة. فقد يسمح بتصفح الويب ويرفض الاتصالات بالمنافذ المستخدمة لإرسال البريد. ويظل الوكيل يقبل اتصال العميل، لكنه لا ينشئ الاتصال المطلوب بخادم البريد.
قيود المنافذ أحد حدود استخدام الوكلاء التي تحدد المهام التي تستطيع الخدمة معالجتها. ولفهم أثرها، يجب تمييز الاتصال بالوكيل من الاتصال الذي ينشئه الوكيل نيابةً عنك.
أي منفذ يُحظر؟
منفذ الشبكة رقم يُستخدم لتمييز الخدمات عند عنوان شبكي. ويمكن للخادم نفسه قبول اتصالات الويب على منفذ واتصالات تطبيق آخر على منفذ مختلف. ويحتاج التطبيق إلى عنوان الخادم والمنفذ المناسب وبروتوكول النقل المستخدم: TCP أو UDP.
لاتصال الوكيل وجهتان منفصلتان. أولًا، يتصل تطبيقك بالوكيل عند العنوان والمنفذ اللذين يقدمهما المزود. ثم يطلب من الوكيل الوصول إلى الخادم المستهدف عند عنوان ذلك الخادم ومنفذه. ويخص المنفذ في إعدادات وكيلك الخطوة الأولى، بينما ينطبق قيد منفذ الوجهة على الثانية.
فمثلًا، يمكن لبرنامج الاتصال بالعنوان proxy.example:1080 وطلب portal.example:443. ويمكن لنقطة دخول الوكيل نفسها استقبال طلب للوجهة mail.example:587 أيضًا. وإذا سمح المزود بمنفذ الوجهة الأول وحظر الثاني، فقد ينجح اتصال الويب ويُرفض اتصال البريد.
تخص هذه القيود الاتصالات الصادرة من الوكيل إلى خدمات خارجية. ولا يمنح السماح بهذا الاتصال تطبيقًا على حاسوبك منفذًا واردًا يستطيع مستخدمو الإنترنت الآخرون الوصول إليه. فتوجيه المنافذ الواردة قدرة منفصلة.
لماذا يقيّد المزودون المنافذ
أوضح سبب هو منع إساءة استخدام خدمة معينة. فقد يُستخدم الوصول المباشر إلى خوادم البريد لحملات رسائل مزعجة. وتؤثر الشكاوى وقوائم حظر المرسلين في عناوين IP الناقلة للبيانات، لذلك قد تمتد التبعات إلى غير العميل الذي أرسل الرسائل. ويمكن للمزود تقليل هذا الخطر برفض الاتصالات بمنافذ إرسال البريد قبل نقل أي رسالة.
قد تسري اعتبارات مشابهة على الإدارة عن بُعد أو مشاركة الملفات أو قواعد البيانات. وقد يقيّد المزود الوصول إلى منافذ مرتبطة بهذه الخدمات لتقليل محاولات الدخول غير المأذون والهجمات الأخرى. وينطبق القيد على الاتصال نفسه؛ فقد يتعذر أيضًا على مسؤول شرعي الوصول إلى خادمه عبر ذلك المنتج.
لا تنشأ القاعدة دائمًا لدى بائع الوكلاء. فقد تفرض شركة استضافة أو مشغل شبكة تصفية للاتصالات الصادرة من البنية التي يستخدمها الوكيل. ولا يستطيع إذن في برمجيات الوكيل نفسها تجاوز قيد مفروض في مرحلة لاحقة من المسار.
مرشح المنافذ إجراء واسع. فيمكنه إيقاف بيانات غير مرغوبة دون فحص كل رسالة أو تقرير مشروعية كل عملية منفردة، لكنه يحد أيضًا التطبيقات المفيدة التي تحتاج إلى المنفذ نفسه. وتوضح هذه الموازنة لماذا قد يبقي المزود منفذًا مغلقًا حتى لعميل يدفع مقابل الخدمة وله مهمة معقولة.
كيف تعمل قواعد الوصول إلى المنافذ
هناك نهجان أساسيان. تسمي قائمة الحظر المنافذ التي لا يستطيع العملاء استخدامها؛ وتُنظر الاتصالات الأخرى وفق بقية قواعد الخدمة. وتعمل قائمة السماح بالعكس: فيجيز المزود مجموعة منافذ محددة ويرفض الباقي. وفي النموذج الثاني، قد يكون تطبيق ويب عادي على منفذ غير قياسي غير متاح لمجرد أن منفذه خارج المجموعة المسموحة.
قد تشمل القاعدة منفذًا عند كل عنوان خارجي، أو تجمع المنفذ مع وجهة معينة. ويمكن للمزودين أيضًا تطبيق قواعد مختلفة على منتجات أو استخدامات معتمدة مختلفة. لذلك لا يثبت الوصول عبر شبكة أذونات منتج آخر تبيعه الشركة نفسها.
لا يحتاج الوكيل إلى فك تشفير بيانات التطبيق لفرض قاعدة منفذ وجهة. ففي طلب HTTP CONNECT، يقدم برنامج العميل المضيف والمنفذ المستهدفين. ويحمل SOCKS5 الوجهة المطلوبة في طلب اتصاله أيضًا. ويمكن للوكيل رفض ذلك الطلب قبل بدء جلسة محمية مع الخادم المستهدف.
يمكن السماح ببيانات TCP وUDP المستخدمة لرقم المنفذ نفسه أو حظرها بصورة منفصلة. ولا يثبت نجاح الاتصال بمنفذ TCP 443 إتاحة منفذ UDP 443. وهناك احتمال آخر: قد لا ينقل منتج الوكيل المختار UDP أصلًا. وفي هذه الحالة، يتعلق القيد ببروتوكول النقل، لا بمنفذ UDP بعينه.
كما لا يثبت رقم المنفذ وحده ما يفعله التطبيق. فقد تعمل الخدمات على منافذ غير قياسية، ولا يجعل الرقم المسموح كل استخدام له مقبولًا. ويمكن للمزودين جمع مرشحات المنافذ مع قيود الوجهات وقواعد النشاط نفسه.
ما الذي يتغير للتطبيقات
تستخدم التطبيقات الاتصالات لوظائف محددة. ويفحص اختبار المتصفح اتصال الويب الذي ينشئه، ولا يجرب كل اتصال قد يحتاجه برنامج آخر. وتوضح الأمثلة التالية كيف يؤثر قيد منفذ في خدمة تعمل في الجوانب الأخرى.
| الاتصال | المنافذ المستخدمة في المثال | أثر القيد |
|---|---|---|
| الوصول إلى الويب عبر TCP | 443 | لا يمكن جلب الصفحة عبر هذا الاتصال. |
| إرسال البريد | TCP 25 للتسليم بين الخوادم؛ وTCP 465 أو 587 للإرسال من تطبيق بريد | لا يتاح إرسال البريد المباشر عبر الاتصال المتأثر. |
| FTP بالوضع السلبي | TCP 21 للأوامر ومنفذ منفصل يعلنه الخادم للبيانات | قد ينجح الدخول بينما يفشل عرض المجلدات أو نقل الملفات. |
| تطبيق ويب على منفذ مخصص | مثلًا TCP 8443 | قد يتعذر الوصول إلى التطبيق حتى مع عمل مواقع على TCP 443. |
يوضح البريد الفرق جيدًا. يرسل تطبيق البريد الرسائل الصادرة إلى خادم بريد، عادةً على المنفذ 587 أو 465. ويبدأ المنفذ 465 بتشفير TLS، بينما يستخدم 587 عادةً STARTTLS لإنشاء التشفير. وقد يمنع قيد المنفذ أيًا من الاتصالين قبل إرسال الرسالة. ويحمي التشفير التبادل، لكنه لا يزيل قاعدة وصول المزود.
في واجهة بريد الويب، يتواصل المتصفح مع موقع عبر HTTPS، وتتولى خدمة البريد التسليم. ولا يطلب المتصفح من الوكيل إنشاء اتصال SMTP نفسه. لذلك قد يظل صندوق بريد الويب قابلًا للاستخدام مع حظر SMTP. واستقبال البريد في تطبيق منفصل اتصال آخر أيضًا؛ فيجب النظر إلى وصول IMAP أو POP بصورة منفصلة عن الإرسال.
يوضح FTP لماذا قد يفوت اختبار الدخول وحده مشكلة. ففي الوضع السلبي، يرسل برنامج العميل الأوامر أولًا عبر اتصال واحد، ثم يتصل بمنفذ يحدده الخادم لنقل البيانات. وإذا قُيد الاتصال الثاني، فقد تعمل المصادقة بينما تفشل قائمة الملفات أو عملية التنزيل. وقد تظهر إخفاقات جزئية مشابهة في التطبيقات ذات الاتصالات المنفصلة للدخول أو الصوت أو تبادل الملفات.
لماذا قد لا يفيد تغيير إعدادات الوكيل
يغير تبديل منفذ الدخول في إعدادات الوكيل مكان اتصال تطبيقك بالوكيل، ولا يغير منفذ الوجهة المطلوب للخدمة الخارجية. وإذا وفر المزود نقطة دخول على المنفذ 443، فإن الاتصال بها يُبقي طلب منفذ خادم البريد 587 خاضعًا لقيد منافذ البريد.
قد يحل الانتقال من وكيل HTTP إلى SOCKS5 مشكلة توافق عندما يحتاج التطبيق إلى قدرة تدعمها طريقة الاتصال الجديدة. لكنه لا يلغي قواعد المزود بحد ذاته. ويحدد SOCKS5 كيفية طلب اتصالات TCP وتمرير UDP؛ وتقرر الخدمة الطلبات التي ستقبلها.
كما يُبقي استبدال IP الخروج القيد المطبق على المنتج كله ساريًا. وقد يتصرف مسار مختلف بصورة مختلفة عندما تتسبب شبكة خارجية معينة في الإخفاق، لكن التدوير ليس وسيلة لإزالة قاعدة تشمل المنتج كله. ولا تغير زيادة IP أو حصة البيانات ذلك الإذن أيضًا.
كيف تحدد قيد المنفذ
أفيد الأدلة استجابة صريحة من المزود تنص على أن منفذ الوجهة المطلوب غير مسموح. ورسالة رفض وصول عامة أقل دقة. فمثلًا، يحدد رد SOCKS5 على طلب رفضته مجموعة القواعد أن الرفض بسبب السياسة، لكنه لا يخبرك بالقاعدة التي تسببت فيه. وانتهاء المهلة أو إعادة الضبط وحده دليل أضعف.
قد لا توجد خدمة تستمع على المنفذ في الخادم المستهدف، أو قد يقبل عناوين مصدر معينة فقط، أو يكون غير متاح مؤقتًا. وقد يستخدم التطبيق أيضًا بروتوكولًا خاطئًا أو يرسل بعض البيانات خارج الوكيل المضبوط. ولا يميز فحص طلب ويب ناجح واحد هذه الأسباب من قيد يؤثر في اتصال آخر.
لطلب دعم مفيد، قدم منتج الوكيل واسم مضيف الوجهة أو IP ومنفذه وTCP أو UDP والتطبيق والخطأ بنصه مع وقت المحاولة. وتتيح هذه التفاصيل للدعم فحص الاتصال المعني بدل مجرد تأكيد اتصال الوكيل بالشبكة. ولشراء مخطط له، تساعد المعلومات نفسها على تحديد دعم المنتج للمهمة.
حيث يسمح المزود باستثناءات، ينبغي أن تحدد الموافقة الوجهة والاستخدام المطلوبين. وتظل بعض القيود دائمة أو تأتي من بنية تحتية لا يتحكم بها المزود. والسؤال المفيد هو هل يمكن دعم الاتصال المحدد وفق قواعد الخدمة؛ أما طلب «فتح جميع المنافذ» فيترك المتطلب والحدود كليهما غير واضحين.
