VPN اور گھر کا LAN ایک ہی سب نیٹ پر: پہلے راستہ دیکھیں
دونوں اڈاپٹر 192.168.1.0/24 کا دعویٰ کرتے ہیں اور صرف ایک راستہ جیتتا ہے۔ دوبارہ نمبر دینے یا DNS کو قصوروار ٹھہرانے سے پہلے اڈاپٹر فہرست، جیتنے والا راستہ اور واپسی کا راستہ دیکھیں۔
آپ دفتر کے VPN سے جڑتے ہیں، ٹرے کا نشان سبز ہو جاتا ہے، انٹرانیٹ لوڈ ہوتا ہے، اور دو میٹر دور پرنٹر جواب دینا بند کر دیتا ہے۔ صبح چلنے والی شیئرنگ اسی مشین پر وقت سے گزر جاتی ہے، اور کسی لاگ میں پرنٹر کا ذکر نہیں۔ پہلا ردِعمل DNS ہے، کیونکہ جو نام حل نہ ہو وہ غیر موجود نام جیسا لگتا ہے، لیکن مسئلہ پتے میں ہے: دو اڈاپٹر اب 192.168.1.0/24 کا دعویٰ کرتے ہیں اور یہ سابقہ صرف ایک راستہ جیت سکتا ہے۔ اسی ترتیب سے دیکھیں اور کچھ بدلنے سے پہلے پتہ چل جائے گا کہ کون سے اڈاپٹر نے یہ لیا۔
علامت سے شروع کریں، ٹنل سے نہیں
اشارہ دائرہ ہے۔ اگر انٹرانیٹ چلتا ہے اور ہر مقامی ڈیوائس ناکام ہوتی ہے، تو ٹنل درست ہے اور مقامی راستہ نہیں۔ اگر مقامی ڈیوائسز چلتی ہیں اور انٹرانیٹ ناکام ہوتا ہے، تو اُلٹ۔ اگر ایک ہوسٹ کے سوا سب چلتا ہے، تو آپ ایک ایسے پتے کو دیکھ رہے ہیں جو دونوں طرف موجود ہے۔
کوئی بھی سیٹنگ چھونے سے پہلے ایک مقامی اور ایک دور کا پتہ لکھ لیں۔ “پرنٹر” جانچا نہیں جا سکتا؛ 192.168.1.40 جا سکتا ہے۔ یہی ایک قدم اس مسئلے میں سب سے زیادہ ضائع ہونے والا گھنٹہ روکتا ہے، یعنی راؤٹنگ فیصلے کے لیے DNS سیٹنگ دوبارہ لکھنا۔
مرحلہ 1: سابقے کا دعویٰ کرتے دونوں اڈاپٹر دیکھیں
نیٹ ورک کنکشنز (ncpa.cpl) کھول کر دونوں اڈاپٹر ساتھ ساتھ پڑھیں۔ Ethernet اڈاپٹر 192.168.1.50/24 دکھاتا ہے، گیٹ وے 192.168.1.1۔ VPN اڈاپٹر سرور کا بھیجا ہوا 192.168.1.201/24 دکھاتا ہے۔ دونوں جائز ہیں، دونوں مانتے ہیں کہ سابقہ on-link ہے، اور اسٹیک اس کے لیے ایک ہی راستہ رکھے گا۔
Get-NetIPAddress -AddressFamily IPv4 پتے گنواتا ہے، اور Get-NetIPInterface | Sort-Object InterfaceMetric وہ ترتیب دکھاتا ہے جس میں اسٹیک انہیں استعمال کرے گا۔ وہی میٹرک کالم وہ فیصلہ ہے جو آپ ابھی پڑھنے والے ہیں، اس لیے یاد رکھنے کی بجائے اعداد لکھ لیں۔
DNS نظریے کو سستے میں غلط ثابت کریں: Resolve-DnsName printer.office.lan وہی پتہ لوٹاتا ہے جو کل لوٹایا تھا۔ نام حل ہو گیا؛ پھر پیکٹ غلط اڈاپٹر سے باہر گیا۔ یہاں دو منٹ resolver سیٹنگز میں ایک دوپہر بچاتے ہیں۔
مرحلہ 2: وہ راستہ پڑھیں جو واقعی جیتا
Find-NetRoute -RemoteIPAddress 192.168.1.40 اس پتے کے لیے اسٹیک کا استعمال کردہ انٹرفیس، اگلا ہاپ اور ماخذ چھاپتا ہے۔ اس آؤٹ پٹ کو اشارہ نہیں، جواب سمجھیں۔ کون سا اندراج کتنا ہارا، یہ دیکھنے کے لیے route print -4 پوری جدول دیتا ہے۔
خصوصیت ارادے کو ہرا دیتی ہے۔ بھیجا گیا 192.168.0.0/25 مقامی 192.168.0.0/24 کو ہراتا ہے کیونکہ سابقہ لمبا ہے، اس لیے 192.168.0.0 سے 192.168.0.127 تک ٹنل سے باہر جاتے ہیں جبکہ اوپری آدھا مقامی رہتا ہے۔ بغیر کسی غلطی پیغام کے آدھا LAN غائب ہونا اس جدول کے لیے درست رویہ ہے۔
tracert -d 192.168.1.40 جدول سے باہر سے اس کی تصدیق کرتا ہے: اگر پہلا ہاپ آپ کے اپنے راؤٹر کی بجائے ٹنل کا پتہ ہو، تو راستہ ہی پوری کہانی ہے۔ Linux پر وہی سوال ip route get 192.168.1.40 ہے، جو ماخذ پتہ اور ڈیوائس ایک سطر میں چھاپتا ہے۔ جب جواب tun0 بتائے، تو براؤزر دیکھنا چھوڑ دیں۔
مرحلہ 3: کلائنٹ کو قصوروار ٹھہرانے سے پہلے واپسی کا راستہ جانچیں
درست آگے کا راستہ بھی ناکام ہوتا ہے اگر دور والا فریق جواب نہ دے سکے۔ جب کلائنٹ کے LAN تک ٹنل سے پہنچا جاتا ہے، تو اس LAN کے گیٹ وے کو معلوم ہونا چاہیے کہ ٹنل کا تالاب کہاں ہے: اس راؤٹر پر ip route add 10.8.0.0/24 via 192.168.1.12، اور کلائنٹس واپسی کا راستہ جانیں اس لیے سرور سے push “route 192.168.1.0 255.255.255.0”۔
پہلے اندراج کے بغیر جواب ہدف کو چھوڑ کر اپنے ڈیفالٹ گیٹ وے کی طرف جاتا ہے، جو نجی پتہ ISP کو بھیج کر گرا دیتا ہے۔ علامت یک طرفہ ہے اور غلط پڑھنا آسان: درخواستیں tun0 پر نظر آتی ہیں، جواب کبھی نہیں۔
VPN ہوسٹ پر masquerade قاعدہ اس مستقل راستے کی ضرورت ختم کرتا ہے: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE۔ یہ اصل ماخذ پتے بھی چھپاتا ہے، جس سے بعد کا ہر لاگ سوال مشکل ہو جاتا ہے۔ غلط ڈیفالٹ گیٹ وے والا ہدف ہوسٹ بھی وہی خاموشی پیدا کرتا ہے، بہترین صورت میں ICMP ری ڈائریکٹ اور عام صورت میں کالا سوراخ، اسی لیے کیپچر دونوں سروں پر چاہیے۔
مرحلہ 4: ایسی مرمت چنیں جس کے ساتھ آپ گزارا کر سکیں
اس کے لیے پانچ مرمتں استعمال ہوتی ہیں اور وہ ایک دوسرے کی جگہ نہیں لے سکتیں۔ یہ دیکھ کر چنیں کہ ایک ہی وقت میں کیا قابلِ رسائی رہنا چاہیے، نہ یہ کہ کون سی کمانڈ مختصر ہے۔
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
میٹرک سستا انتخاب ہے اور وہی جس پر لوگ پہلے ہاتھ رکھتے ہیں۔ تبدیلی انٹرفیس پر لاگو ہوتی ہے، اس لیے ٹنل اوپر رہنے تک کام کرتی ہے، اور اس کی جگہ کلائنٹ کے پاس اسکرپٹ میں ہے، اس شیل میں نہیں جو آپ بھول جائیں گے۔ یہ دو نیٹ ورکس پر ایک ہی پتے تک بیک وقت رسائی نہیں دے سکتا، اور یہی حد باقی سب کو جدول میں نیچے بھیجتی ہے۔
گھر کے LAN کو دوبارہ نمبر دینا 10.10.0.0/24 پر صاف حل ہے: ایک DHCP لیز کی تجدید کے ساتھ پرانی رینج کا ذکر کرنے والے ریزرویشن، پرنٹر قطاریں اور ہارڈ کوڈ شدہ پتے۔ دفتر کی طرف دوبارہ نمبر دینا عام طور پر آپ کا فیصلہ نہیں۔ اگر دونوں نیٹ ورکس میں ہو تو IPv6 ٹکراؤ مکمل ختم کرتا ہے، یاد رکھنے والی کسی چیز کی جگہ fd00::/8 سے منفرد مقامی سابقہ استعمال کرتے ہوئے، لیکن ایپلیکیشن TCP پر جانچیں، ping پر نہیں، کیونکہ ICMP چل سکتا ہے جبکہ سروس نہ چلے۔
OpenVPN کا اپنا ترجمہ آپشن آخری راستہ ہے، سرور سے کلائنٹ مخصوص ڈائریکٹری اندراج میں بھیجا جاتا ہے۔ یہ آپشن کے نام کے بعد چار پیرامیٹر لیتا ہے — سمت، نیٹ ورک، نیٹ ماسک اور عرف — اور عرف اختیاری نہیں: push "route 192.168.2.0 255.255.255.0" اور push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0"۔ نیٹ ورک اور ماسک وہ رینج ہے جو کلائنٹ دیکھتا ہے (192.168.2.0/24)، عرف سرور کی طرف اصل دفتر کی رینج ہے (192.168.1.0/24)، اور بھیجا گیا راستہ اسی نظر آنے والی رینج کو قابلِ رسائی بناتا ہے۔ پھر دفتر اس کلائنٹ کو 192.168.2.x کے تحت نظر آتا ہے۔ پروفائل میں میپنگ دستاویز کریں، ورنہ اگلا شخص اسے راؤٹنگ خرابی سمجھ کر ڈی بگ کرے گا۔
صرف ایک سروس شائع کرنا ترجمے کی تنگ صورت ہے اور اسے OpenVPN آپشن کی ضرورت ہی نہیں۔ VPN ہوسٹ پر DNAT قاعدہ ایک پورٹ دوبارہ شائع کرتا ہے، اس لیے LAN اپنے پتے رکھتا ہے اور اسی ہوسٹ پتے پر سروس تک پہنچتا ہے جو اسے پہلے سے معلوم ہے۔ قیمت عام ہے: سروس VPN ہوسٹ کو ماخذ سمجھتی ہے، اس لیے فی کلائنٹ لاگ اور معکوس تلاش بے معنی ہو جاتے ہیں۔ یہ ایک پرنٹر قطار یا ایک ایڈمن صفحہ ڈھکتا ہے، دونوں طرف کے ہوسٹ کا ایک دوسرے تک پہنچنا نہیں۔
اور کیا کام نہیں کرے گا، اور کیا درج کرنا ہے
نشریات راؤٹڈ ٹنل سے نہیں گزرتیں۔ DLNA، UPnP، NetBIOS براؤزنگ اور Wake-on-LAN ایسی نشریات یا ملٹی کاسٹ پر منحصر ہیں جو tun ڈیوائس نہیں اٹھاتی، اس لیے کوئی راستہ دریافت درست نہیں کرتا۔ dev tap کے ساتھ بریجنگ حصے کو بڑھاتی ہے، اور اس کے ساتھ DHCP نشریات، ARP اور ہر دوسرا دریافت پیکٹ؛ دور کے راؤٹر کے LAN طرف پتے کے لیے route 192.168.2.1 255.255.255.255 جیسا یونیکاسٹ ہوسٹ راستہ ترجیح دیں۔
ایک ہی راستے پر دونوں 192.168.1.1 استعمال کرنے والے دو راؤٹر ایک ہی مسئلہ خاندان کے ہیں: مقامی پتہ ہمیشہ جیتتا ہے، اس لیے ایک LAN کے ہٹنے تک دور کے راؤٹر کا صفحہ ناقابلِ رسائی رہتا ہے۔ دوسرا اڈاپٹر شامل کرنا دونوں صورتوں میں کچھ نہیں بدلتا۔
کچھ بھی ترمیم کرنے سے پہلے شواہد لکھ لیں: ip route get یا Find-NetRoute، متعلقہ پتے پر ping -c 3، ایک traceroute، اور کلائنٹ پر tcpdump -ni tun0 icmp، پھر سرور پر راؤٹنگ جدول اور NAT کاؤنٹر۔ جو ping ایک طرف چلتا ہے اور دوسری طرف مر جاتا ہے وہ ٹنل کی نہیں، واپسی کے راستے کی طرف اشارہ کرتا ہے، اور یہی ایک فرق طے کرتا ہے کہ اوپر کی کون سی مرمت آپ کو واقعی چاہیے۔