شبكتان VPN ومُحلِّل واحد: مَن كتب آخرًا هو مَن يفوز

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

الأسطورة: أحدث VPN يملك DNS

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

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

اربط مساحات الأسماء بالمُحلِّلات

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

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

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

أبقِ مسارًا تمهيديًا

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

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

العناوين المتداخلة ليست مشكلة DNS

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

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

أثبته بتطبيقات حقيقية

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

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