VPN سے جڑنے کے بعد مقامی IP پتے کا تصادم ٹھیک کریں

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

ایک ہی غلطی پیغام بانٹنے والی تین خرابیاں

نقل کا مطلب ہے کہ ایک ہی سیگمنٹ کی دو مشینیں ایک ہی پتے کا دعویٰ کرتی ہیں۔ کرنل اسے محسوس کرتا ہے کیونکہ اس کی اپنی پروب کا جواب دوسرے MAC سے آتا ہے، اور آگے کیا ہوتا ہے یہ اسٹیک پر منحصر ہے: Linux اسے لاگ کرتا ہے، Windows انٹرفیس بند کر کے سسٹم لاگ میں اندراج لکھتا ہے، اور DHCP کلائنٹ پیشکش مسترد کر سکتا ہے۔

اوورلیپ کسی بھی پتے کی نقل نہیں کرتا۔ آپ کی LAN 192.168.1.0/24 ہے، دفتر کا نیٹ ورک بھی 192.168.1.0/24 ہے، اور اب دفتر کا راستہ ایسے پتوں کی طرف اشارہ کرتا ہے جو آپ کا پرنٹر اور NAS بھی ہیں۔ ARP کے معنی میں کچھ بھی متصادم نہیں؛ پیکٹ صرف دو نیٹ ورکس میں سے ایک پر غلط ڈیوائس کی طرف جاتا ہے۔

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

ٹیسٹ 1: کیا نقل آپ کے اپنے سیگمنٹ میں ہے؟

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

ip -br addr
ip neigh
ip route show table all | grep -E 'wg|tun|ppp'

Windows میں یہی معلومات ipconfig /all اور Get-NetIPAddress سے آتی ہیں، پڑوسی کیش arp -a میں ہے۔ اگر متنازع پتہ فزیکل اڈاپٹر پر ہے اور شکایت VPN چلائے بغیر بھی ظاہر ہوتی ہے، تو VPN صرف تماشائی ہے اور آپ کو اسے حل کرنا چھوڑ دینا چاہیے۔

اندازہ لگانے کے بجائے نقل کو ثابت کرنے کے لیے، پتے کی جانچ ایسی ڈیوائس سے کریں جو اس کی مالک نہ ہو۔ arping -D پروب صفر ماخذ پتے کے ساتھ بھیجتا ہے، اس لیے غیر متوقع MAC سے آنے والا جواب ثابت کرتا ہے کہ کوئی دوسرا ہوسٹ پہلے ہی اس پتے کا جواب دے رہا ہے۔

sudo arping -D -I eth0 -c 3 192.168.1.50

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

ٹیسٹ 2: کیا دونوں نیٹ ورک اوورلیپ کرتے ہیں؟

ٹنل جو سابقہ آپ کو دیتا ہے اس کا موازنہ اپنے انٹرفیسز کے سابقوں سے کریں۔ اگر دور دراز رینج آپ کی LAN کے برابر ہو یا اسے شامل کرے، تو خرابی اوورلیپ ہے، اور اسے ظاہر کرنے والی بات یہ ہے کہ VPN کے بغیر قابل رسائی ہوسٹ اندھیرا ہو جاتا ہے، یا آپ کا اپنا پرنٹر دفتری پتے پر جواب دیتا ہے۔

ip route get 192.168.1.10
ip -br addr show

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

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

دفتری نیٹ ورک کو دوبارہ نمبر دینا شاذ و نادر ہی آپ کا فیصلہ ہوتا ہے۔ ٹکراؤ سے بچنے کے لیے اپنی LAN کو دوبارہ نمبر دینا اس سے بڑی تبدیلی ہے جتنی زیادہ تر لوگ توقع کرتے ہیں جب پرنٹرز، کیمرے اور جامد ہوسٹ شامل ہوں۔

ٹیسٹ 3: کیا ٹنل نے ایک پتہ دو بار دیا؟

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

wg show all allowed-ips
wg show wg0 latest-handshakes
wg show wg0 transfer

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

OpenVPN کے پاس پول ہے، اور عام ٹکراؤ مشترکہ کلائنٹ پروفائل ہے جس میں مقررہ --ifconfig لائن دوسری مشین پر نقل کی گئی ہو۔ پھر دونوں کلائنٹس ایک ہی ٹنل پتہ مانگتے ہیں، اور سرور وہ سیشن قبول کرتا ہے جسے پہلے پروسیس کرتا ہے۔ --duplicate-cn کے ساتھ پول کا ختم ہونا بھی ایسا ہی نتیجہ دیتا ہے جب ایک سرٹیفکیٹ کے کئی سیشن ایک اندراج کے لیے مقابلہ کریں۔

اس کے لیے کلائنٹ لاگ کے بجائے سرور لاگ پڑھیں۔ سرور جانتا ہے کہ کس سیشن نے کون سا پتہ لیا، اور وہاں دہرائے گئے پتے ایسی وارننگز کے طور پر نظر آتے ہیں جو کلائنٹ تک کبھی نہیں پہنچتیں۔

اصل جگہ پر مرمت کریں، پھر دونوں ڈیوائسز دوبارہ جانچیں

ترتیب اہم ہے۔ پہلے LAN کی نقل ٹھیک کریں، کیونکہ جو کلائنٹ پتہ نہ رکھ سکے وہ ٹنل بھی نہیں رکھ سکتا۔ پھر VPN طرف کی فراہمی ٹھیک کریں، کیونکہ کلائنٹ پر پول کی تقسیم میں کی گئی تبدیلی اگلے کنکشن پر کالعدم ہو جاتی ہے۔ آخر میں نقل شدہ شناختیں سنبھالیں: WireGuard پر الگ کلید جوڑیاں، OpenVPN پر الگ سرٹیفکیٹس یا کم از کم الگ پروفائلز۔

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

sudo dhclient -r eth0 && sudo dhclient eth0
ipconfig /release && ipconfig /renew

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

راستے میں کیا نہ کریں

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

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