Windows پر VPN مقامی LAN کو روکتا ہے: روٹ یا کلائنٹ پالیسی؟
Windows پر مقامی LAN تک رسائی دو مختلف وجوہات سے ٹوٹتی ہے: غائب روٹ، یا گیٹ وے کی پالیسی جو سب نیٹ کو گرا دیتی ہے۔ تین جانچیں بتاتی ہیں کون سی۔
آپ کی اپنی میز پر رکھا پرنٹر، NAS یا ڈویلپمنٹ مشین کام والے VPN کے جڑنے کے لمحے جواب دینا بند کر دیتا ہے۔ کبھی ایک روٹ کمانڈ اسے سیکنڈوں میں ٹھیک کر دیتی ہے؛ کبھی وہی روٹ درست ہوتا ہے اور پیکٹ پھر بھی غائب ہو جاتے ہیں، جس کا مطلب ہے کہ آپ ملتی جلتی علامات والا کوئی اور مسئلہ دیکھ رہے ہیں۔ فیصلہ تین سوالوں پر آتا ہے، اور انہیں غلط ترتیب میں پوچھنا ہی وہ سبب ہے جس سے لوگ پوری شام روٹ مٹا کر دوبارہ جوڑتے رہتے ہیں۔
کسی بھی کمانڈ سے پہلے تین سوال
پہلا: کیا مقامی پریفکس کے لیے کوئی اندراج ہے، اور کیا وہ طبعی اڈاپٹر کی طرف اشارہ کرتا ہے؟ دوسرا: کیا جڑتے وقت کلائنٹ کو گیٹ وے سے مقامی نیٹ ورک کی اجازت یا ممانعت ملتی ہے؟ تیسرا: کیا آپ کو صرف LAN تک باہر جانے کی رسائی چاہیے، یا انٹرنیٹ کی کوئی چیز بھی آپ کی مشین پر چلنے والی سروس تک پہنچنی چاہیے؟
پہلا سوال روٹنگ کی خرابی کو فلٹرنگ کی خرابی سے الگ کرتا ہے۔ دوسرا بتاتا ہے کہ روٹ کی درستی کو بالکل کام کرنے کی اجازت ہے یا نہیں۔ تیسرا مرمت بدلتا ہے: روٹ باہر جانے والی ٹریفک درست کرتا ہے، جبکہ ناقابل رسائی اندر آنے والی سروس عام طور پر سننے والے کی بائنڈنگ اور واپسی راستے کا مسئلہ ہوتی ہے جسے روٹ مزید بگاڑ دیتا ہے۔
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
سوال ایک: روٹ، فلٹر یا نام
کچھ بھی شامل کرنے سے پہلے جدول پڑھیں۔ انٹرفیس انڈیکس اہم ہے، کیونکہ نیچے کی ہر روٹ کمانڈ اسی سے جڑی ہے:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricبراہ راست جڑا سب نیٹ ٹنل کے اوپر ہونے پر بھی عام طور پر آن لنک روٹ رکھتا ہے، اس لیے اندراج موجود ہو سکتا ہے اور ٹریفک پھر بھی ناکام ہو سکتی ہے۔ یہی امتزاج روٹنگ کے بعد چلنے والے فلٹر کا دستخط ہے، اور یہی وہ صورت ہے جس میں دوسرا، زیادہ مخصوص روٹ کچھ بھی نہیں بدلتا۔
پتے کے مطابق اور نام کے مطابق الگ الگ جانچیں۔ اگر ping 192.168.1.50 جواب دے اور net view 192.168.1.50 نہ دے، تو روٹنگ جدول کبھی مسئلہ نہیں تھا: ٹنل نے ریزولور بدل دیا اور مقامی نام اب حل نہیں ہوتا۔ اس کے لیے روٹ شامل کرنا بیکار کام ہے۔
سوال دو: کیا گیٹ وے مقامی LAN تک رسائی کی اجازت دیتا ہے؟
تجارتی کلائنٹ روٹوں سے زیادہ نصب کرتا ہے۔ جڑتے وقت اسے پالیسی ملتی ہے، اور اس پالیسی میں مقامی نیٹ ورک کی واضح اجازت ہو سکتی ہے۔ Cisco IPsec تعیناتیوں میں گروپ پالیسی split-tunneling کی ترتیب اور مقامی LAN رسائی کا الگ جھنڈا رکھتی ہے؛ کلائنٹ کا چیک باکس ایک درخواست ہے جسے گیٹ وے رد کر سکتا ہے۔ AnyConnect میں پروفائل split کی شمولیت اور اخراج کی فہرستوں اور وہی اجازت کنٹرول کرتا ہے۔ Windows RRAS پر مساوی چیزیں پروفائل میں ڈیفالٹ گیٹ وے کا اختیار اور سرور کے دیے گئے جامد روٹ ہیں۔
جب جھنڈا بند ہو، دستاویزی رویہ یہ ہے کہ کلائنٹ براہ راست جڑے سب نیٹ کی طرف ٹریفک روک دیتا ہے، اگرچہ درست، زیادہ مخصوص روٹ موجود ہو۔ اسی لیے کلائنٹ کی ملکیت سے باہر کے روٹ بھی شامل کرنے کے چند سیکنڈ بعد غائب ہو سکتے ہیں: کلائنٹ کو جس حالت کے بنانے کا کہا گیا تھا وہ دوبارہ بنا رہا ہے، آپ سے لڑ نہیں رہا۔
کلائنٹ لاگ جڑتے وقت فیصلہ درج کرتا ہے، اور اسے پڑھنا مشین پر کسی بھی تجربے سے تیز ہے۔ اگر لاگ کہے کہ مقامی رسائی بند ہے، تو رکیں: کوئی بھی کمانڈ لائن درستی اس پر قابو نہیں پا سکتی، اور بچنے والے راستے پالیسی کی تبدیلی، ٹنل کے ذریعے وسیلے تک پہنچنا، یا کلائنٹ کو ورچوئل مشین میں رکھ کر میزبان کو مقامی نیٹ ورک پر چھوڑ دینا ہیں۔
سوال تین: آپ کو کون سی سمت چاہیے؟
قریبی آلے کی طرف باہر جانے والی ٹریفک روٹنگ کا سوال ہے۔ LAN پریفکس کو مقامی گیٹ وے کی طرف اتنی کم میٹرک کے ساتھ بھیجیں کہ ٹنل کے ڈیفالٹ روٹ کو ہرا سکے:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -pدوسری شکل ایک ہی آلے کو پن کرتی ہے, اور جب ایک پتہ ہی پوری ضرورت ہو تو آپ یہی چاہتے ہیں۔ netsh کا مساوی وہی فیصلہ انڈیکس کے بجائے انٹرفیس نام سے درج کرتا ہے:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentپتہ اور ماسک نہ ملنے پر روٹ کمانڈیں پیرامیٹر غلط ہے کے ساتھ ناکام ہوتی ہیں، مثلاً /24 ماسک والا میزبان پتہ۔ سب نیٹ روٹ کے لیے نیٹ ورک پتہ اور ایک میزبان کے لیے میزبان ماسک استعمال کریں۔
اندر آنے والی مختلف ہے۔ اسی مشین کا VNC یا SSH سرور ناقابل رسائی ہو جاتا ہے جب اندر آنے والے کنکشن کے جوابات VPN گیٹ وے سے باہر چلے جائیں اور کبھی واپس نہ آئیں۔ روٹ چھونے سے پہلے دیکھیں کہ سروس کس پر سن رہی ہے:
netstat -ano | findstr :5900ایک مخصوص پتے سے بندھا سننے والا دوسرے انٹرفیس پر جواب نہیں دے گا۔ اسے تمام انٹرفیسوں سے باندھنا جان بوجھ کر لیا گیا فیصلہ ہے، جو اس نیٹ ورک تک محدود فائر وال قاعدے کے ساتھ لیا جاتا ہے جس پر آپ بھروسہ کرتے ہیں۔ اس کے بعد ہی روٹ کی مرمت واپسی راستہ بحال کرتی ہے۔
موزوں سب سے چھوٹی تبدیلی لگائیں
دوسرا عام قدم IPv4 کی جدید خصوصیات میں ”ریموٹ نیٹ ورک پر ڈیفالٹ گیٹ وے استعمال کریں“ کا نشان ہٹانا ہے۔ یہ انٹرنیٹ ٹریفک مقامی رکھتا ہے، لیکن بیک وقت دو کام کرتا ہے: VPN ڈیفالٹ راستہ نہیں رہتا، اور کلائنٹ ریموٹ نیٹ ورک کے روٹ، multicast سمیت، لینا چھوڑ دیتا ہے۔ نشان ہٹائیں تو ریموٹ LAN غائب ہو جاتا ہے، جب تک سرور ہر کلائنٹ کو درکار مخصوص ریموٹ پریفکس نہ دھکیلے۔
یہ عدم توازن کام کی ترتیب طے کرتا ہے۔ اگر ریموٹ طرف مکمل طور پر قابل رسائی رہنی چاہیے، تو سرور سے ریموٹ سب نیٹ دھکیلیں اور مقامی ڈیفالٹ کو چھوڑ دیں۔ اگر سرور نہیں بدل سکتے، تو ٹنل کے دیے گئے پتے کے ذریعے ریموٹ پریفکس پر مستقل روٹ شامل کریں، اور route print سے جانچیں کہ پریفکس VPN انٹرفیس کی طرف ہے جبکہ ڈیفالٹ اب بھی طبعی گیٹ وے کی طرف ہے۔
پھر تصدیق کریں کہ مرمت دوبارہ جڑنے پر قائم رہتی ہے، کیونکہ غیر مستقل روٹ اڈاپٹر کے ساتھ مر جاتے ہیں اور ہر کنکشن کے بعد چلنے والی اسکرپٹ ان کے لیے دیانتدار جگہ ہے۔ اسی سیشن میں ایک مقامی آلہ اور ایک ریموٹ وسیلہ جانچیں، منقطع کریں، دوبارہ جڑیں اور پھر جانچیں۔ اگر روٹ درست دکھنے کے باوجود مقامی آلہ ناکام رہے، تو سوال دو پر واپس جائیں: کلائنٹ فلٹر کر رہا ہے، اور جواب پالیسی کی تبدیلی ہے، دوسرا مقابل روٹ نہیں۔