محول VPN يعرض /32: هذا لا يعني وجهة واحدة

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

الأسطورة: قناع مضيف يعني مضيفًا واحدًا يمكن الوصول إليه

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

للارتباك جذر حقيقي: على إيثرنت، قناع المضيف كان سيعني فعلًا عنوانًا واحدًا على ذلك المقطع. النفق ليس مقطع إيثرنت، وجدول التوجيه لدى العميل، لا القناع، هو ما يقرر ما يمر عبره. ولهذا يمكن أن يقف القناع نفسه /32 أمام مركز بيانات كامل.

اقرأ العنوان والمسارات ككائنين منفصلين

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

ip addr show tun0
ip route show
ip route get 10.60.5.10

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

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

توقف إذا أشار البحث إلى الواجهة الخطأ. هذه مشكلة توجيه على العميل، وتُصلح على العميل.

لماذا يجعل توسيع القناع الأمور أسوأ عادة

تغيير التعيين إلى /24 ليبدو مثل شبكة المكتب المحلية قد ينشئ بادئة على الرابط: يعتقد النواة الآن أن كامل /24 متصل مباشرة بواجهة النفق. حينها يُرسل المرور الخاص بعناوين يجب توجيهها عبر البوابة كما لو كان جار على الرابط. النتيجة ثقب أسود يشبه انقطاع الخادم.

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

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

حين يكون المسار صحيحًا ويظل التدفق فاشلًا

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

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

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

الأسطورة التي يجب إحالتها هي أن القناع حدّ لإمكانية الوصول. اقرأ العنوان والمسارات وسياسة البوابة كثلاث حقائق منفصلة، فيكفّ /32 عن أن يبدو قيدًا ويبدأ أن يبدو تعيين نفق عاديًّا.