VPN متصل بلا إنترنت؟ افحص الطبقات الأربع

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

ابدأ من الشبكة التي جئت منها

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

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

حدد ما إذا كان الفشل في تحليل الأسماء

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

nslookup example.com

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

نفق كامل أم شبكات فرعية للشركة فقط

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

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

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

حين لا يعيد الخادم توجيه أي شيء

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

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

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

افحص طبقة واحدة في كل مرة

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

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

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