کیا 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 سرور پر ریزرویشن سب سے سستا حل ہے۔ متحرک پول سے باہر پتہ منتخب کریں، اسے Pi کے MAC پتے سے باندھیں، اور اگلی لیز تجدید کے بعد 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 کو جاننا ہوگا کہ کلائنٹ سب نیٹ تک کیسے پہنچنا ہے، اور اس کی فائر وال کو سرنگ کی ٹریفک کی اجازت دینی ہوگی۔ عدم مطابقت ڈھانپنے کے لیے شامل کیا گیا ڈیفالٹ راستہ عام طور پر اصل خلا چھپا دیتا ہے اور ایک ہفتے بعد کچھ اور توڑ دیتا ہے۔