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

ثلاث وجهات تحتاج إلى نواقل مختلفة

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

Destination classView that names the carrierCommand that proves itSymptom when the wrong carrier wins
Outer peer, 198.51.100.10the main table, by destinationip route get 198.51.100.10the outer handshake never completes
Inner peer, 203.0.113.7the main table once the outer tunnel is upip route get 203.0.113.7the inner handshake leaves over the physical link
Application destination, 172.30.9.1the table the inner client's traffic is selected intoip route get 172.30.9.1 from 10.8.0.2the exit address looks right and the traffic never crossed the outer hop
Parallel tunnels, one per source groupone policy per group, not the main tableip rule show beside a marked test connectionboth tunnels are up and one steals the other's traffic

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

للعناوين أدوار، لا عدد

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

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

ip -4 addr show
ip -4 route show table all
ip rule show

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

ترتيب التنشيط يتغلب على انتظار ثابت

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

يمنح النواة أسماء مثل tun0 و tun1 بترتيب الإنشاء، وهذا الترتيب قد يتغير بين عمليات إعادة التشغيل أو إعادة الاتصال. اربط الإعداد بهوية توفرها الأدوات، أو باسم تعينه عمدًا. الاسم الذي تختاره عقد؛ والاسم الذي تختاره النواة حادث عرضي.

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

ماذا يحدث عندما تموت القفزة الخارجية

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

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

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

اختبر كل طبقة بالترتيب الذي بنيتها به

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

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

مقالات ذات صلة