دو مالک، ایک پتہ: TAP برج پر دہرائے گئے IP

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

برج کو چھونے سے پہلے تصادم کے شواہد پڑھیں

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

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

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

حصے پر ہر دعوے کی فہرست بنائیں

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

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

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

پول اور DHCP رینج وہ دو مالک ہیں جنہیں لوگ بھول جاتے ہیں۔ دونوں رینج ایک ساتھ چھاپیں اور کچھ اور کرنے سے پہلے اوورلیپ تلاش کریں۔ ہاتھ سے دیا گیا برج پتہ اور وہی قدر دینے والا پول دیر یا سویر ٹکرائیں گے، اور جب تک دونوں رینج ساتھ ساتھ نہ چھپیں تصادم بےترتیب لگتا ہے۔

برجوں کو صرف وہیں نمبر دیں جہاں شناخت درکار ہو

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

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

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

اصلاح کو ری بوٹ میں قائم رکھیں

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

اس ترتیب کا مالک تلاش کریں: نیٹ ورک مینیجر پروفائل، فی انٹرفیس فائل، کنٹینر یا VM کی تعریف، یا cloud-init کا ٹکڑا۔ اسے وہیں بدلیں، پھر نئی قدر ہی لوٹتی ہے اس کی تصدیق کے لیے جان بوجھ کر ایک متاثرہ میزبان ری بوٹ کریں۔ ری بوٹ ہی واحد امتحان ہے جو استقلال ثابت کرتا ہے۔

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

ہر کلائنٹ کے آن لائن ہونے پر اسے ثابت کریں

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

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

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

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