RRAS کے VPN کلائنٹس کو اپنا IPv4 پول اور واپسی کا راستہ درکار ہے

VPN کلائنٹ جڑتا ہے اور پتہ وصول کرتا ہے، لیکن جس LAN میزبان کی اسے ضرورت ہے وہ اب بھی جواب نہیں دے سکتا۔ Windows Routing and Remote Access میں VPN کلائنٹس کا اندرونی پتہ سرور کے LAN اڈاپٹر سے الگ ترتیب دیے گئے پول سے آتا ہے، اور LAN طرف کو اس پول تک واپسی کا راستہ درکار ہے۔ دو تبدیلیاں، ایک نہیں، اور وہ مختلف طریقوں سے ناکام ہوتی ہیں۔ پرانے رینجز ہٹانے سے پہلے پتہ منصوبہ اور واپسی کا راستہ ثابت ہونے کے لیے انہیں ترتیب سے کریں۔

کنسول کھولنے سے پہلے رینج مختص کریں

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

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

سرور کا LAN اڈاپٹر اس پول کی تعریف نہیں کرتا۔ عوامی سامع کو بدلنا یا LAN میں اڈاپٹر شامل کرنا بالکل اور کام کرتا ہے۔ اسی وجہ سے کلائنٹ جڑ سکتے ہیں اور پھر بھی غلط جگہ سے پتہ لے سکتے ہیں۔ پول سرور کی IPv4 خصوصیات میں رہتا ہے، اڈاپٹر فہرست میں نہیں۔

طریقہ بدلنا رینج شامل کرنا نہیں ہے

RRAS میں ایک تفویض طریقہ اور رینجز کا مجموعہ ہے۔ DHCP سے مستقل پول کی طرف جانا طریقہ کی تبدیلی ہے۔ مستقل پول پہلے سے فعال ہونے پر دوسرا بلاک شامل کرنا رینج کی تبدیلی ہے۔

کسی ایک کو چلانے سے پہلے دونوں کارروائیوں کا پیش منظر دیکھیں، اور پڑھیں کہ کون سی سرور کی موجودہ حالت سے میل کھاتی ہے:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

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

Get-VpnIPAddressRange

خالی رینج فہرست والا DHCP طریقہ یعنی پہلا پیش منظر لاگو ہوتا ہے۔ موجودہ رینج والا مستقل پتہ پول یعنی دوسرا لاگو ہوتا ہے۔

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

LAN کو واپسی کا راستہ درکار ہے

فرض کریں LAN 10.60.0.0/24 ہے اور RRAS سرور اس پر 10.60.0.10 ہے۔ اس LAN کا میزبان جو 10.250.50.0/24 کے کلائنٹ کو جواب دیتا ہے اسے RRAS سرور کے ذریعے پول تک راستہ درکار ہے۔ اس راستے کے بغیر درخواست پہنچتی ہے اور جواب مر جاتا ہے۔

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

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

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

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

ناموں کا حل اپنی جانچ کا حقدار ہے: IP سے رسائی کام کر سکتی ہے جبکہ کلائنٹ کا DNS اب بھی ایسے حل کنندہ کی طرف اشارہ کرتا ہے جہاں وہ نہیں پہنچ سکتا۔ LAN پر DNS سرور تک رسائی صرف اس وقت ہے جب کلائنٹ کا وہاں راستہ ہو اور سرور نئی رینج سے سوالات قبول کرے۔ پول کے منتقل ہونے پر دونوں عام کوتاہیاں ہیں۔

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

تین مشاہدوں سے نتیجہ جانچیں

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

کلائنٹ سے، پتہ اور ایک LAN میزبان تک راستہ تصدیق کریں:

ipconfig | findstr /i "IPv4"
route print -4

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