ری اسٹارٹ کے بعد حذف شدہ WireGuard peer واپس کیوں آتا ہے

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

اس فہرست کو دو حالتیں تھامے رکھتی ہیں۔ منسوخی تبھی حقیقی ہوتی ہے جب دونوں اسے کھو دیں۔

wg set اصل میں کیا بدلتا ہے

حکم wg set wg0 peer <public-key> remove کرنل کے اندر چلتی ہوئی انٹرفیس میں ترمیم کرتا ہے۔ یہ ڈسک پر کچھ نہیں لکھتا۔ تشکیل کی فائل، NetworkManager پروفائل یا راؤٹر کی محفوظ حالت اچھوتی رہتی ہے۔ یہ ڈیزائن ہے، خرابی نہیں۔

یہ علیحدگی جان بوجھ کر ہے، کیونکہ اوزار کو معلوم ہی نہیں کہ انٹرفیس کا مالک کون ہے۔ رن ٹائم حکم کو کسی اور کے زیرِ انتظام انٹرفیس پر محفوظ ہونا چاہیے۔ یہ اندازہ نہیں لگا سکتا کہ پائیدار نقل کہاں رہتی ہے۔ نتیجہ آسانی سے کہا جا سکتا ہے: رن ٹائم میں ہٹانا اپنی ساخت کے اعتبار سے عارضی ہے۔

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

فائل میں ترمیم سے پہلے لکھنے والے کو ڈھونڈیں

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

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

wg show wg0 peers
wg show wg0 allowed-ips
systemctl status wg-quick@wg0 --no-pager
ls -l /etc/wireguard

جس زندہ انٹرفیس کی peer فہرست اور فائل کا مواد مطابقت نہیں رکھتے، وہی پوری تشخیص ہے۔ بوٹ پر محفوظ تشکیل جیتتی ہے اور رن ٹائم کی حالت ہارتی ہے۔ دونوں میں سے کوئی بھی بدلنے سے پہلے ان کا موازنہ کریں۔

SaveConfig کا جال

wg-quick ایک ایسا موڑ جوڑتا ہے جو ہاتھ سے فائلیں ترمیم کرنے والوں کو پکڑتا ہے۔ جب SaveConfig فعال ہو، اس کا درج شدہ بند ہونے کا رویہ موجودہ رن ٹائم حالت کو تشکیل کی فائل پر لکھ دیتا ہے۔

یہ پائیداری کی معمول کی سمت الٹ دیتا ہے۔ آپ فائل سے ایک peer ہٹاتے ہیں، پھر سروس رک جاتی ہے۔ چلتی ہوئی حالت آپ کی ترمیم کے اوپر لکھ دی جاتی ہے اور ابھی حذف کیا ہوا peer بحال کر دیتی ہے۔

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

دونوں حالتیں بدلیں، پھر دوبارہ لوڈ کریں

رن ٹائم میں کنجی کے ذریعے peer ہٹائیں۔ محفوظ تشکیل میں وہی بلاک مالک کی معاون کارروائی کے ذریعے ہٹائیں، اس کے گرد ترمیم کر کے نہیں۔

پھر دیکھیں کہ peer کیا اٹھائے ہوئے تھا۔ منسوخ شدہ شناخت کا روٹ شدہ نیٹ ورک جان بوجھ کر دوبارہ تفویض یا ہٹایا جانا چاہیے، نہ کہ اگلے ترمیم ہونے والے peer کی طرف سے خاموشی سے وراثت میں ملے۔

اگر گیٹ وے آپ کی انتظامی رسائی بھی اٹھائے ہوئے ہو تو بحالی کا راستہ کھلا رکھیں۔ غلط peer ہٹانے والا ری اسٹارٹ خود ساختہ رکاوٹ ہے۔ غلط روٹ ہٹانے والے ری اسٹارٹ پر بھی یہی لاگو ہے۔

کامیاب امتحان کیسی صورت میں ہوتا ہے

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

wg show wg0 peers
wg show wg0 allowed-ips
sudo wg-quick down wg0 && sudo wg-quick up wg0
wg show wg0 peers

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

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