هل يحدّث اسم مضيف بوابة Pi المسارات الثابتة من تلقاء نفسه؟

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

إجابة DNS والمسار كائنان مختلفان

لنقل إن Pi الخاصة بك تستجيب لـ vpn-gw.lan وتمرّر 10.44.0.0/16 إلى نفق. تصل إليها العملاء على 192.168.30.0/24 عبر مسار ثابت. عندما انتقل عنوان Pi من 192.168.30.4 إلى 192.168.30.11، تبع السجل خلال مدة TTL ولم تتبع المسارات.

تختلف الرؤيتان بطريقة يسهل تفويتها، لأن كلتيهما تبدوان معقولتين عندما تستعلم عنهما منفصلتين:

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

السطر الأول وحده هو ما يقرّر أين تذهب الحزم. السطر الثاني يجيب عن سؤال لم تسأله النواة قط. كما أن سجلًا يحمل عدة سجلات A لا يصبح سياسة تجاوز فشل، لأن كل عنوان يجب أن يظل قفزة تالية صالحة على ذلك المقطع.

ما يبقى في الجدول بعد خروج الأمر

يسجّل مسار Linux أمرين مهمّين هنا: القفزة التالية كعنوان بروتوكول، وواجهة الخروج كرقم فهرس. إن سمات مسار rtnetlink تسمّي ذلك الحقل الأول RTA_GATEWAY، وهو يحمل بايتات. وبمجرد أن يصبح المدخل في مكانه، لا تُرفق به أي مدة TTL ولا يحدّثه أي بحث في الخلفية.

لهذا قد يبدو ip route add 10.44.0.0/16 via vpn-gw.lan وكأنه يعمل. يحلّ الأداة الاسم أثناء تشغيل الأمر، ويكتب العنوان الناتج، وينسى الاسم تمامًا. شغّل ip route show 10.44.0.0/16 بعد ذلك فتحصل على عنوان حرفي.

هذا السلوك يستحق المعرفة قبل أن تلوم النفق.

أدوات تحلّ الاسم بدلًا منك، ومتى

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

تميل الإعدادات المُدارة إلى تقسيم المهمة. يحتفظ حجز DHCP أو استئجار ثابت بـ Pi على عنوان واحد، ويتبع سجل DNS الاستئجار ببساطة. لا شيء يحتاج إلى تتبّع هدف متحرّك لأن الهدف لا يتحرّك.

المحدّث المراقَب هو النمط المشروع الآخر، وهو يحتاج إلى مالك.

ثبّت العنوان أو شغّل المحدّث بنفسك

بالنسبة لشبكة محلية صغيرة، الحجز على خادم DHCP هو أرخص حل. اختر عنوانًا خارج المجموعة الديناميكية، واربطه بعنوان MAC الخاص بـ Pi، وأكّده بـ ip -4 addr show dev eth0 بعد تجديد الاستئجار التالي. ثم وجّه القفزة التالية للعملاء إلى ذلك العنوان مرة واحدة. لديك الآن بوابة مستقرة وسجل يصفها، وهذا هو الترتيب الذي تعمل به العلاقة فعلًا.

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

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

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

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