قفزتا VPN على جهاز Pi واحد: أي مسار يحمل أي نظير
عنوانان للنفق على جهاز Pi واحد ليسا عيبًا. كل وجهة تحتاج إلى ناقل خاص بها وإثبات خاص بها وبديل معلن عندما تموت القفزة الخارجية.
يبدو وجود عنوانين للنفق على لوحة صغيرة واحدة كخطأ، والغريزة تدفع إلى حذف أحدهما. تلك الغريزة تكسر الشيء الذي كان يُفترض أن ترتبه. المضيف الذي يحمل قفزتين يحتفظ بعنوان واحد لكل ارتباط، ويُختار كل عنوان عبر مسار مختلف. السؤال الجدير بالطرح هو أي مسار يختار أي ناقل لأي وجهة، لا كم عدد العناوين الموجودة.
ثلاث وجهات تحتاج إلى نواقل مختلفة
سلسلة القفزتين هي ثلاث فئات من الوجهات متراكبة، وكل واحدة منها يحملها ارتباط مختلف. يجب الوصول إلى النظير الخارجي عبر الرابط الفيزيائي. ويجب الوصول إلى النظير الداخلي عبر النفق الخارجي. أما وجهة التطبيق المغطى فيجب الوصول إليها عبر النفق الداخلي، الذي يحمل النفق الخارجي نقلَه الخاص.
| Destination class | View that names the carrier | Command that proves it | Symptom when the wrong carrier wins |
|---|---|---|---|
| Outer peer, 198.51.100.10 | the main table, by destination | ip route get 198.51.100.10 | the outer handshake never completes |
| Inner peer, 203.0.113.7 | the main table once the outer tunnel is up | ip route get 203.0.113.7 | the inner handshake leaves over the physical link |
| Application destination, 172.30.9.1 | the table the inner client's traffic is selected into | ip route get 172.30.9.1 from 10.8.0.2 | the exit address looks right and the traffic never crossed the outer hop |
| Parallel tunnels, one per source group | one policy per group, not the main table | ip rule show beside a marked test connection | both 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 العامة أبدًا. احفظ مسارات النظير والعناوين التي يستخدمها وتلك النتيجة بجانب الإعداد، لأن المسار السعيد ليس الجزء الذي يُسأل عنه لاحقًا.