VPN محظور على شبكة تسمح بالويب فقط؟ عالج الطبقات واحدة تلو الأخرى

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

أثبت أي طبقة ترفض الاتصال

لا تبدأ بعميل VPN. ابدأ بطلب HTTPS عادي إلى المضيف نفسه واقرأ أطوار التوقيت، لأن الطور الذي يفشل يخبرك أي جهاز هو المسؤول:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

لا استجابة ولا زمن connect يعني أن TCP لم يكتمل أبدًا، لذا هناك جدار ناري أو شرط وكيل أو وجهة خاطئة في اللعب. زمن connect بدون زمن tls يعني أن شيئًا في المنتصف قبل الاتصال ثم عطّل المصافحة، وهذا ما يبدو عليه وكيل فاحص من جهة العميل.

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

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

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

العميل المدرك للوكيل يغيّر الحزمة الأولى، لا السياسة

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

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

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

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

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

المنفذ 443 يمكن الوصول إليه، لا يُسمح به

تغليف نفق في TLS على 443 يحل الوصول ولا شيء آخر. المرشح الذي يفحص المنفذ سيمرره؛ والمرشح الذي يأخذ بصمة المصافحة لن يفعل، وترحيب العميل المشفر لا يخفي اسم الخادم إلا عندما يدعمه الطرفان. شغّل الاختبار واكتشف نوع المرشح الذي أنت خلفه بدلًا من الأمل.

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

UDP عادة أول الضحايا، ويستحق التأكيد بدلًا من الاستنتاج. إذا لم يكمل WireGuard أو OpenVPN الافتراضي مصافحة أبدًا بينما يعمل TCP 443، فالشبكة تُسقط UDP، ولا مقدار من إعادة توليد المفاتيح سيغيّر ذلك:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

طابع زمني فارغ للمصافحة بجانب نظير كان يعمل أمس هو إجابة UDP. استعلاما DNS يجيبان سؤالًا آخر: إذا اختلف المُحلِّل المحلي ومُحلِّل عام حول عنوان نقطة النهاية، فأنت تُوجَّه وحجة النقل هي الخاطئة.

تحقق مما غادر الجهاز فعليًا

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

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

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

قائمة المقابس تلتقط حالة أدق: نفق ثانٍ يحتفظ بالفعل بالمسار الافتراضي. عميلان يتقاتلان على جدول التوجيه ينتجان أعطالًا متقطعة تبدو تمامًا كشبكة محظورة، وسيظهر الالتقاط حركة تغادر عبر واجهة لم تتوقعها.

التراجع، والملاحظة التي تستحق الحفظ

ألغِ التغييرات بالترتيب العكسي الذي أجريتها به. أزل متغيرات الوكيل، وأوقف العميل الذي بدأته يدويًا، وأزل أي تجاوز للمسار أو المُحلِّل أضفته:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

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

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