لماذا يعمل ملف OpenVPN الشخصي في المنزل ويفشل في الفندق

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

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

أربع حقائق شبكية تتغير بين المواقع

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

الثانية هي دقة الأسماء. البوابة التي تعترض DNS تجيب كل استعلام بعنوانها الخاص، فيُحلّ اسم مضيف VPN إلى البوابة ويحاول العميل بناء نفق إلى صفحة ويب.

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

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

دقة الأسماء وبوابة الدخول

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

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

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

ترشيح النقل: UDP أولًا، وTCP 443 كبديل

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

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

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

تعارض العناوين والوصلات الصاعدة بلا IPv4

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

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

تضيف الوصلات الصاعدة المتنقلة اختلافين. NAT من فئة المشغل يعني أن الاتصالات الواردة لا تصل، وهذا يهم إذا كنت تستضيف خادمًا لكن ليس لعميل صادر. وAPN مُعدّ ليعمل بـ IPv6 فقط مع ترجمة NAT64 قد يُفشل عميلًا يصر على مسار IPv4 حقيقي، والعلاج المعتاد هو تغيير بروتوكول APN إلى IPv4 أو مكدس مزدوج.

الأعراض بعد قيام النفق

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

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