systemd-networkd کے ساتھ دوبارہ جڑنے کے بعد بھی ip rule کو برقرار رکھیں

ip rule سے پالیسی قاعدہ شامل کریں، یہ لنک کے جانے تک کام کرتا ہے؛ اس لمحے یہ محض موجود نہیں۔ کچھ بھی بلند آواز میں ناکام نہیں ہوا: کرنل کی حالت بدل گئی، اور کسی کنفیگریشن مالک کو معلوم نہیں تھا کہ قاعدہ ہونا چاہیے۔ قائم رہنے والے اور نہ رہنے والے قاعدے میں پورا فرق یہی ہے۔ systemd-networkd والے ہوسٹ پر حل یہ ہے کہ قاعدے کو مالک دیں، نہ یہ کہ ہر دوبارہ جڑنے کے بعد حکم دوبارہ چلائیں۔

قاعدہ تبھی ہوتا ہے جب کوئی اس کا مالک ہو

کرنل کی روٹنگ پالیسی حالت ہے، کنفیگریشن نہیں۔ یہ چلتے نظام میں رہتی ہے، اور جو بھی اس انٹرفیس کو ڈھا دیتا ہے جس پر یہ منحصر ہے، اسے ساتھ لے جا سکتا ہے۔ شیل کا حکم وہ حالت بدلتا ہے اور نیت کا کوئی ریکارڈ نہیں چھوڑتا۔

نیٹ ورک مینیجر الٹے طریقے سے کام کرتے ہیں: وہ کنفیگریشن پڑھتے ہیں، لاگو کرتے ہیں، اور جب لنک کا واقعہ پچھلی حالت کو باطل کر دے تو دوبارہ لاگو کرتے ہیں۔ ان کی کنفیگریشن میں اعلان کردہ قاعدہ دوبارہ بنتا ہے، جبکہ ان کے پہلو میں شامل قاعدہ بغیر مالک کے بیرونی شے ہے۔

اس فرق کا networkd میں ایک نام ہے، اور کچھ بھی فعال کرنے سے پہلے اسے پڑھنا چاہیے۔ حالیہ ورژنوں میں بیرونی قواعد بطور طے شدہ ہٹا دیے جاتے ہیں، جو ان لوگوں کو حیران کرتا ہے جنہیں توقع تھی کہ ان کے ہاتھ سے لکھے اندراج رہیں گے۔

کسی ترتیب پر بھروسہ کرنے سے پہلے ورژن پڑھیں

ملکیت کا رویہ networkd.conf کی ایک ترتیب سے کنٹرول ہوتا ہے، اور وہ ترتیب پرانے systemd ورژنوں میں نہیں ہے۔ اس کے گرد ڈیزائن کرنے سے پہلے نصب شدہ ورژن جانچیں، کیونکہ پرانا ہوسٹ ان دستاویزات سے مختلف برتاؤ کرتا ہے جو آپ پڑھ رہے ہیں۔

دو اقدار اہم ہیں۔ ایک طے کرتی ہے کہ networkd کنفیگریشن میں اعلان نہ کیے گئے قواعد ہٹائے جائیں یا نہیں، اور دوسری راستوں کے لیے وہی کرتی ہے۔ دونوں پالیسی کے مواد کے بجائے ملکیت سے متعلق ہیں، اور دونوں موجودہ ورژنوں میں بطور طے شدہ سخت رویہ چنتی ہیں۔ انہیں عالمی طور پر بند کرنے سے ہر بیرونی قاعدہ زندہ رہتا ہے، جو ایک مطلوبہ VPN پالیسی کے اعلان سے کہیں بڑا فیصلہ ہے۔

systemctl --version | head -1
networkctl --version | head -1
grep -R "ManageForeign" /etc/systemd/ /usr/lib/systemd/ 2>/dev/null

وہ grep آپ کو بتاتا ہے کہ مقامی طور پر کیا مقرر ہے اور وینڈر کا طے شدہ کیا ہے۔ عدم موجودگی بھی معلومات ہے، کیونکہ اس کا مطلب ہے کہ مرتب شدہ طے شدہ لاگو ہے۔ طے شدہ کو اپنے نوٹس میں لکھیں تاکہ اگلے شخص کو اسے دوبارہ دریافت نہ کرنا پڑے۔

قاعدہ اور وہ جدول اعلان کریں جس کی طرف یہ اشارہ کرتا ہے

.network فائل میں قاعدہ ایک جدول کا نام دیتا ہے، اور نام بس یہی کرتا ہے۔ یہ اس جدول کے اندر راستے نہیں بناتا اور یہ نہیں جانچتا کہ وہ معنی خیز ہیں۔ راستوں کے بغیر قاعدہ اعلان کرنے سے ایسی پالیسی بنتی ہے جو ٹریفک سے میل کھاتی ہے اور پھر اسے گرا دیتی ہے۔

راستے اسی فائل میں اعلان کریں، قابل رسائی اگلے ہاپ اور درست جدول کے ساتھ۔ اعلان کردہ قاعدے میں ترجیح رکھیں تاکہ ترتیب شدہ فہرست میں یہ وہاں پڑے جہاں آپ توقع کرتے ہیں۔ غلط جدول تک وقت سے پہلے پہنچنے والا قاعدہ اس خدمت سے زیادہ ٹریفک بدلتا ہے جسے آپ درست کرنا چاہتے تھے۔ نیچے دیے گئے ٹکڑے کو مکمل فائل نہیں بلکہ ایک شکل کے طور پر پڑھیں، کیونکہ انٹرفیس کی ملکیت اور کنکشن کا باقی حصہ اب بھی موجود ہونا چاہیے۔

[RoutingPolicyRule]
Family=ipv4
IPProtocol=tcp
SourcePort=443
Table=100
Priority=1000

[Route]
Destination=10.80.0.0/24
Gateway=10.80.0.1
Table=100

پھر دوبارہ لوڈ کریں اور فائل کے بجائے کرنل کی حالت پڑھیں۔ صاف طور پر پارس شدہ کنفیگریشن بھی ایسا قاعدہ بنا سکتی ہے جس کا آپ نے ارادہ نہیں کیا تھا، اور دونوں منظر تبھی میل کھاتے ہیں جب اعلان مکمل تھا۔

انٹرفیس کے لیے ایک ہی مالک چنیں

ایک ہی سرنگ پر دو مینیجر ایسی کشمکش پیدا کرتے ہیں جو دونوں میں بگ جیسی لگتی ہے۔ موجودہ wg-quick سیٹ اپ کو networkd میں درآمد کرنا اضافہ نہیں، منتقلی ہے، اور دونوں چلانے سے انٹرفیس اور اس کے قواعد دو مالکوں کے تحت رہ جاتے ہیں۔

منتقلی ایک ہی بار میں کریں: پرانی یونٹ روکیں، اسے غیر فعال کریں، networkd میں انٹرفیس اور اس کے راستے اعلان کریں، پھر دوبارہ لوڈ کریں۔ جانچیں کہ پرانی یونٹ بوٹ پر واپس نہیں آ سکتی۔ بچی ہوئی یونٹ جو ری بوٹ کے بعد دوبارہ فعال ہو، اس حالت پر لکھ دیتی ہے جو آپ نے ابھی اعلان کی تھی۔ پرانی کنفیگریشن فائل رکھیں جب تک نئی ایک دوبارہ جڑنے کو جھیل نہ لے، پھر اسے ریٹائر کریں۔

نشان کی ملکیت بھی اتنی ہی دیکھ بھال مانگتی ہے: اگر قاعدہ فائر وال نشان سے میل کھاتا ہے تو کسی کو وہ نشان مقرر کرنا ہوگا۔ ایسے نشان کا حوالہ دینے والا قاعدہ جسے کوئی مقرر نہیں کرتا، مردہ کنفیگریشن ہے جو جان بوجھ کر کیا ہوا لگتا ہے۔

زندگی کے چکر کے واقعات کی مشق کریں

کنفیگریشن واقعات کے دوران اپنے برتاؤ جتنی ہی اچھی ہوتی ہے۔ لنک نیچے اتاریں، اوپر لائیں، خدمت دوبارہ شروع کریں اور پتہ تجدید کریں۔ ہر ایک کے بعد قواعد کی فہرست اور جدول کا مواد پڑھیں۔

sudo networkctl reload
ip rule show
ip route show table 100
sudo systemctl restart systemd-networkd

مطلوبہ نتیجہ یہ ہے کہ وہی ملکیت والی پالیسی دوبارہ بنے اور پرانی حالت ریٹائر ہو، جو ہر دوبارہ جڑنے کے بعد شیل قاعدہ دوبارہ شامل کرنے سے زیادہ پائیدار ہے۔ تبدیلی کے ریکارڈ میں ایک سطر رکھیں جو قاعدے کی مالک فائل اور اسے سہارا دینے والا ورژن بتائے۔ تب اگلا انجینئر شیل کی تاریخ کھودے بغیر پالیسی ڈھونڈ سکے گا۔ جس قاعدے کا کوئی مالک نہیں وہ دوبارہ گم ہونے والا قاعدہ ہے۔