اتصال VPN ناجح في المنزل لكنه يتوقف بمهلة في واي فاي الفندق
الحاسوب نفسه والحساب نفسه، لكن الشبكة مختلفة. اقرأ رمز الخطأ كمرحلة، وتحقق من الاسم، ثم التقط الحزمة الخارجية قبل تغيير أي إعداد.
ينضم الحاسوب إلى شبكة واي فاي المنزل، ويتصل العميل في ثلاث ثوانٍ، ثم يفشل الملف نفسه في الفندق بعد ساعة. لم يُحدَّث أي شيء في الأثناء. إن مراجعة هذا مع عميل أمامك تتعلق في الأساس بمعرفة أي خطأ ينتمي إلى أي مرحلة، لأن المعلومة المفيدة في الرمز الذي يطبعه العميل، لا في مجرد فشله. اتبع الخطوات الأربع أدناه بالترتيب وستعرف هل رفضك اسم أو حزمة أو منفذ أو سياسة.
اقرأ رمز الخطأ كمرحلة لا كحكم نهائي
يبلغ العميل ثلاث محطات منفصلة قبل أن يوجد النفق. يحل اسم الخادم، ويحصل على جواب من شيء ما على الشبكة، ويتفاوض على ارتباط أمني. لكل محطة رسالة فشل خاصة بها، وWindows خاصة كريم في منح رموز متمايزة بمجرد أن تعرف إلى أي مرحلة تنتمي.
| What the client says | Stage that failed | First thing to run |
|---|---|---|
| 868, name did not resolve | DNS, before any packet leaves for the server | Resolve-DnsName vpn.example.net |
| 721 or 806, remote computer did not respond | Outer protocol filtered, typically GRE or UDP | A capture on the local interface |
| 809, server not responding | A device in the path is dropping the outer flow | The same capture, from a second network |
| 789, security layer error | The security exchange started and was rejected | Certificate and proposal settings on both ends |
اثنان من تلك الرموز يعنيان أن الشبكة بريئة. الرمز 789 يعني أن الحزم كانت تتدفق وأن الطرفين اختلفا حول التشفير، وهذه مشكلة إعداد يمكنك إصلاحها في المنزل. والرمز 868 يعني أنه لم تكن هناك حاجة لخروج أي حزمة، لذا تصميم النفق غير ذي صلة حتى يُحل الاسم. إن تصنيف الرمز في مرحلته الصحيحة يوفر وقتًا أكثر من أي التقاط، لأنه يخبرك أي الخطوات الثلاث التالية تتخطى.
تحوّط بما يناسب إن لم يكن العميل على Windows. عملاء الطرف الثالث يختزلون معظم هذه الرسائل في "فشل الاتصال"، ولهذا لا تعتمد الخطوتان التاليتان على الرسالة إطلاقًا.
تحقق من الاسم قبل أن تلوم النفق
شبكات الفنادق والمطارات تعترض DNS باستمرار، والمحلل الذي يجيب بعنوان بوابة يُنتج فشلًا يبدو تمامًا كخادم ميت. قارن ما يقوله المحلل المحلي بما يقوله محلل عام:
Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"إن اختلف الجوابان فأنت تُوجَّه، وبقية التشخيص مهدورة حتى يُحل ذلك. وبشكل خاص، عنوان البوابة سيقبل اتصال TCP بسرور ثم يتوقف، ولهذا قد يبدو كحجب من جدار ناري عندما تختبر بمتصفح.
الآن تأكد أن العنوان الذي تنوي الوصول إليه هو المستخدم فعلًا. بعض العملاء يخزنون التحليل السابق طوال عمر الملف، لذا إعادة الاتصال بعد تغيير DNS تذهب إلى العنوان القديم. أغلق العميل تمامًا قبل إعادة الاختبار، بدلًا من الضغط على قطع الاتصال ثم الاتصال في النافذة نفسها.
اعرف أي حزمة خارجية تختفي
للنفق تدفق خارجي ينتمي بالكامل إلى المسار بينك وبين الخادم، وهذا التدفق هو ما تصنفه الصناديق الوسيطة وتُسقطه. التقطه على العميل، ثم قارن شبكة عاملة بالشبكة الفاشلة. على Windows يكفي الالتقاط المدمج لنظرة أولى:
pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etlما تريد رؤيته هو هل تغادر حزمك أصلًا، وهل يعود أي شيء. حزم تخرج ولا يعود شيء تعني أن المسار أو الطرف البعيد يُسقطها؛ ولا شيء يخرج أصلًا يعني أن العميل لم يصل إلى الإرسال، وهذا يعيدك إلى حل الاسم أو إلى سياسة جدار ناري محلي.
أعد الاختبار نفسه على نقطة اتصال هاتف. هذه أكثر مقارنة مفيدة متاحة لك، لأنها تزيل كل صندوق في الفندق من المسار مع إبقاء الحاسوب والعميل وبيانات الاعتماد كما هي. إن ظهر النفق على نقطة الاتصال فتوقف عن النظر إلى الخادم. وإن فشل هناك أيضًا فلديك مشكلة عميل أو حساب لم تكن الشبكة سببها قط.
غيّر ناقلًا واحدًا وأعد الاختبار
بمجرد أن تعرف أن التدفق الخارجي يُسقط، يصبح السؤال العملي هو أي تدفق تسمح به الشبكة. معظم الشبكات المقيّدة تسمح بـ TCP 443 الصادر لأنها لا تستطيع العمل بدونه، لذا نقل المستمع إلى هناك هو الجواب المعتاد. على OpenVPN يكون ذلك مفتاحًا في جهة العميل حتى يُغيَّر الخادم:
openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4عملاء IPsec لديهم مفتاح مكافئ في لوحات إعداداتهم، يوصف عادةً بأنه IPsec عبر TCP أو تجاوز NAT. تغييره تشخيص أيضًا: إن ظهر النفق عبر TCP ومات عبر UDP فقد أثبتت أن الشبكة تصفي UDP، وقد وجدت أيضًا الإعداد الذي ستحتاجه في كل مرة تزور فيها ذلك الموقع.
قاوم إغراء تعطيل ميزات الموجه من المحاولة الأولى. تعطيل الفحص ذي الحالة أو الحماية من الفيضان على شبكة فندق غير متاح لك أصلًا، وعلى عتادك الخاص يقايض حماية حقيقية بحاسوب واحد. سجّل أي إعداد غيّر النتيجة، ثم أعده وابحث عن ناقل تسمح به الشبكة بالفعل.
تحقق من الملف نفسه على الشبكة الثانية
قبل إغلاق التذكرة، أثبت أن التغيير صمد بعد مغادرة المبنى. أعد الاتصال على الشبكة الأصلية بالإعدادات الأصلية، والتقط الثلاثين ثانية الأولى، وتأكد أن العميل يبلغ الحالة نفسها التي بلغها على نقطة الاتصال:
pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddressالتمييز الذي يكشفه الأمر الأخير يستحق الاحتفاظ به: يمكن للملف أن يبلّغ عن نفق متصل بينما التوجيه داخله خاطئ، وهذا ينتج "VPN متصل لكن لا شيء يعمل"، وهو مقال آخر. إن تغيّر نوع النفق بعد تعديلك فالملف ليس الذي اختبرته.
ثم اكتب النتيجة حيث سينظر الشخص التالي. "ملف الشركة يحتاج TCP 443 في هذا الموقع؛ وUDP 500 تصفيه شبكة الفندق" جملة يمكن لزميل أن يتصرف بناءً عليها. أما "VPN متقلب في الفنادق" فليست كذلك، وتضمن أن تُنفق الساعة نفسها مرة أخرى الشهر القادم.