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 সার্ভারে রিজার্ভেশনই সবচেয়ে সস্তা সমাধান। ডাইনামিক পুলের বাইরে একটি ঠিকানা বেছে নিন, সেটি 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-কে জানতে হবে কীভাবে ক্লায়েন্ট সাবনেটে পৌঁছাতে হয়, আর তার ফায়ারওয়ালকে টানেল ট্রাফিক অনুমোদন করতে হবে। অসঙ্গতি ঢাকতে যোগ করা একটি ডিফল্ট রুট সাধারণত আসল ফাঁকটাই লুকায় এবং এক সপ্তাহ পরে অন্য কিছু ভেঙে দেয়।