DNS الجغرافي و الأنيكاست: فحص نقطة دخول VPN التي تحصل عليها

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

تحقق من الموقع الذي يبلغ عنه المحلل فعلا

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

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

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

تحقق مما قررته توجيهات الأنيكاست

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

تحقق من موقع الخدمة من جهة الخدمة، أو من جواب يسميه، لا من جواب DNS وحده. يعرض traceroute -n 198.51.100.20 المسار الذي سلكته ولا يسمي المضيف في نهايته، فاقرأه كمسار لا كجواب.

تحقق من أن الجلسة تصمد أمام تغير العقدة

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

راقب التحول بدل افتراضه. يعرض sudo tcpdump -ni any -c 20 esp الحزم الخارجية أثناء تغير المسار، والتغير المفاجئ في عنوان النظير هو التحول نفسه. عرف السلوك المقصود صراحة للتنفيذ الذي تشغله، ثم اختبره بفرض تغيير في المسار. وإذا كان التصميم يفترض تكرار الجلسة، فسم الآلية وسم الفشل الذي لا تغطيه.

تحقق من أن الهوية ما زالت مطابقة

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

افحص ذلك من عميل وصل إلى عقدة غير معتادة، لأنها الحالة التي تصبح فيها شهادة كل عقدة مرئية. يطبع openssl s_client -connect vpn.example.com:443 -servername vpn.example.com السلسلة والأسماء، وهو بالضبط ما يقارنه العميل. ثم قرر ما إذا كان يجب تضييق ملف التعريف أو تغيير نموذج الشهادة.

تحقق من السجل، لا من الجواب الأول فقط

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

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

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