آیا نام میزبان دروازه 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 به‌سادگی از اجاره‌نامه پیروی می‌کند. چیزی لازم نیست هدف متحرکی را ردیابی کند، چون هدف حرکت نمی‌کند.

به‌روزرسان پایش‌شده الگوی مشروع دیگری است، و به یک مالک نیاز دارد.

نشانی را سنجاق کنید یا به‌روزرسان را خودتان اجرا کنید

برای یک LAN کوچک، رزرو روی سرور 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 باید بداند چگونه به زیرشبکه کارخواه برسد، و دیوار آتش آن باید ترافیک تونل را مجاز کند. مسیر پیش‌فرضی که برای پوشاندن ناسازگاری افزوده شود معمولاً شکاف واقعی را پنهان می‌کند و یک هفته بعد چیز دیگری را می‌شکند.