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

البحث يحدث قبل إعادة كتابة المصدر

بالنسبة إلى حزمة تُمرَّر من عميل VPN، ينفّذ النواة تسلسلاً ثابتاً. تصل الحزمة على واجهة النفق، وتمرّ في prerouting حيث يقيم conntrack وDNAT، ثم يُتخذ قرار التوجيه، ثم التمرير، ثم postrouting حيث يُطبَّق SNAT أخيراً. قاعدة من نوع from تُستشار أثناء قرار التوجيه ذلك، أي أنها ترى عنوان العميل الأصلي لا العنوان المترجَم.

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

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

StageSource the kernel seesWhat it means for your rule
PreroutingClient address, 172.31.7.42Where marks and DNAT are applied
Routing decisionStill 172.31.7.42This is where from rules match
PostroutingBecomes 198.51.100.9What the far end and its return route see

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

اختبار من البوابة ليس اختباراً للمجموعة

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

حاكِ العميل بدلاً من تقريبه. يمكن سؤال قرار التوجيه مباشرةً، مع تزويده بمصدر وواجهة دخول:

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

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

الأولوية، لا الموضع في الملف

تُقيَّم القواعد بترتيب الأولوية تصاعدياً، والرقم هو المهم لا ترتيب كتابتك لها. جدول local في الأولوية 0، وجدول main في 32766، والقاعدة الافتراضية في 32767، ولهذا تهبط قاعدة أُضيفت بالأولوية الافتراضية قرب نهاية القائمة وتخسر أمام كل شيء تقريباً.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

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

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

مسار العودة يجب أن يوجد أيضاً

سياسة المصدر تختار مخرجاً. وهي لا تنشئ مسار عودة. إن غادرت المجموعة الثانية عبر نفق شريك، فعلى الشريك أن يعرف كيف يصل إلى 172.31.8.0/24، إما بمسار عودة إلى البوابة أو باستلام عناوين مترجَمة يعرفها مسبقاً.

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

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

لا تلتقط نفق البوابة نفسه في السياسة

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

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

توثّق صفحة دليل ip-rule دلالات المحدِّد والأولوية. اجمعها مع اختبار بحث لكل مجموعة فيصبح التصميم قابلاً للفحص، وهذا هو الفرق بين توجيه سياسي يصمد سنة وتوجيه سياسي يخاف الجميع من لمسه.

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