نقطة وصول VPN واحدة عبر Squid: استثناء ضيّق لـ CONNECT

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

كيف يحسم Squid طلب CONNECT

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

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

تأكد أن الوسيط هو المكوّن الذي يرفض الطلب. رمز 403 الذي يولّده Squid لا يشبه أبدًا تحذير TLS من خادم VPN، ودمج الاثنين في مشكلة واحدة يكلّف الساعة الأولى. افحص سطر سجل الوصول الخاص بالطلب، لأنه يسجّل الفعل والقاعدة التي أنتجته معًا.

ابنِ مطابقة واحدة مركّبة بدل ثلاث قوائم ACL منفصلة

ابنِ الاستثناء من ثلاث حقائق: نطاق مصدر معتمد، وعنوان وجهة معتمد واحد، والمنفذ الوحيد الذي تستمع عليه نقطة الوصول. قائمتا ACL منفصلتان ومطابقة مركّبة واحدة تنتجان سياسة مختلفة جدًا، لأن التركيبة هي ما يُقيَّم. سمِّ القائمة المركّبة بما تسمح به لا بالطريقة التي تحملها.

الشكل أدناه يستخدم نطاقات توثيق يجب استبدالها بقيم مراجَعة. لا يحتفظ Squid بأي من هذه الأسماء، لذا فهي لك لتختارها ولك لتبقيها متسقة. هذه الوصفة مقتصرة على Squid 6 و7، إذ يدعم إعدادهما الموثّق مجموعة all-of. تشير المراجع الحالية إلى أن تلك التوجيهات غير متاحة في Squid 8، لذا تعامل مع هذا كوصفة مرتبطة بإصدار لا كمسار ترحيل، وتحقق من التوجيه مقابل مرجع إصدارك قبل تطبيقه.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

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

اثنِ حواجز المنافذ دون إزالتها

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

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

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

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

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

أين يجب ألا يوضع الاستثناء

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

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

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

افحص الحدود بالمحلّل وبطلب حقيقي

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

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

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

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