چوڑا VPN راستہ چند عوامی سائٹس کو کیوں توڑ دیتا ہے
چند سائٹس ناکام ہوتی ہیں جبکہ باقی لوڈ ہوتی ہیں، کیونکہ ایک چوڑا سابقہ ان کے پتے پکڑ لیتا ہے۔ راستے کو حل شدہ پتے سے ملائیں، پھر جانیں کہ اسے کون نصب کرتا ہے۔
زیادہ تر صفحات لوڈ ہوتے ہیں، دو یا تین وقت سے گزر جاتے ہیں، اور براؤزر کنکشن کو قصوروار ٹھہراتا ہے۔ ناکام ہونے والی سائٹس میں وہ بات مشترک ہے جو کام کرنے والیوں میں نہیں: ان کے حل شدہ پتے VPN کے نصب کردہ سابقے کے اندر آتے ہیں۔ کافی چوڑا راستہ عوامی رینج کو ڈھانپتا ہے تو ایسی ٹریفک پکڑ لیتا ہے جو سرنگ نے کبھی اٹھانی نہیں تھی، اور علامت روٹنگ کے فیصلے کی بجائے ویب سائٹ کے مسئلے جیسی لگتی ہے۔
ناکام ہونے والا نام حل کریں، پھر براؤزر کی بجائے روٹنگ جدول دیکھیں۔
سائٹ کا نام نہیں، پتہ موازنہ کریں
وہ پتہ تلاش کریں جو کلائنٹ نے واقعی آزمایا، پھر دیکھیں کون سا راستہ اس سے میل کھاتا ہے۔ 45.61.20.10 کے اندر منزل 45.0.0.0/8 کے تحت آتی ہے اگر وہ سابقہ موجود ہو، چاہے سائٹ کا خود سرنگ سے کوئی تعلق نہ ہو۔ ناکام پتے کا نصب شدہ سابقوں سے موازنہ کرنا تفریق کا مسئلہ ہے، اندازہ نہیں۔
Windows دونوں حصوں کا براہ راست جواب دے سکتا ہے، اور تلاش دکھاتی ہے کہ کون سا انٹرفیس اور اگلا ہاپ انتخاب جیتے۔ اگر سائٹ کئی پتے واپس کرے تو نام دو بار حل کریں۔ ہر ایک کو ملنے والے راستے کے ساتھ لکھیں۔ مختلف پتے مختلف جواب دے سکتے ہیں، اور ان میں سے صرف ایک ہی ناکام کیس ہو سکتا ہے۔
Resolve-DnsName www.example.org Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric Find-NetRoute -RemoteIPAddress 45.61.20.10 Get-VpnConnection | Format-List Name,SplitTunneling,Routes
سب سے مخصوص ملتا سابقہ پڑھیں، پہلی ایسی سطر نہیں جو مانوس لگے۔ جدول میں موجود راستہ یہ ثابت نہیں کرتا کہ اس نے تلاش جیتی؛ سب سے طویل مطابقت یہ کرتی ہے۔ دو سابقے ایک پتے سے مل سکتے ہیں، اور ان میں سے صرف ایک ہی پیکٹ وصول کرتا ہے۔ ہارنے والا جدول میں رہتا ہے اور فہرست میں اتنا ہی حقیقی لگتا ہے۔
سابقہ، اس کا انٹرفیس اور حل شدہ پتہ لکھیں۔ وہ تین اقدار ہی پوری تشخیص ہیں۔
جانیں کہ راستہ کس نے نصب کیا
راستے چار جگہوں سے آتے ہیں: مقامی VPN پروفائل، انتظامی پالیسی، کنکشن اسکرپٹ یا بالکل دوسرا کلائنٹ۔ فعال اندراج کو مٹانا اس کی مطابقت کی تصدیق کر سکتا ہے، لیکن اگلا کنکشن اسے محفوظ ترتیب سے دوبارہ بناتا ہے، اس لیے ماخذ ہی بدلنا ہوگا۔
پہلے پروفائل کی راستوں کی فہرست دیکھیں، پھر انتظامی پالیسی، پھر کنیکٹ ہونے پر چلنے والی کوئی بھی اسکرپٹ۔ یہ ترتیب اس بات سے میل کھاتی ہے کہ ہر ایک کتنی بار ذمہ دار نکلتا ہے۔ یہ تبدیلی کو تین کی بجائے ایک پرت میں بھی رکھتی ہے۔
مقامی طبقہ بنیاد رویے کو غور سے پڑھیں
مقامی Windows پروفائلز میں ایک دستاویزی ترتیب ہے، NativeProfile/DisableClassBasedDefaultRoute، جو انٹرفیس پتے سے اخذ کردہ خودکار راستے کو کنٹرول کرتی ہے۔ 45 سے شروع ہونے والا پروفائل پتہ اس رویے کے تحت 45.0.0.0/8 اندراج پیدا کر سکتا ہے، اور اسی طرح ایک عوامی پتہ پوری کلاس A رینج پکڑ لیتا ہے۔
خاصیت کا نام غلط پڑھنے کی دعوت دیتا ہے: اسے true پر رکھنا اخذ کرنا بند کرتا ہے، اور false اسے چالو کرتا ہے۔ یہ ڈیفالٹ راستے جیسی وہی شے بھی نہیں، اور اپنے سابقے نصب کرنے والے فریق ثالث کلائنٹس کو یہ کنٹرول نہیں کرتا۔
اگر اخذ کرنا ثابت شدہ وجہ ہے تو پروفائل کو اس کے انتظامی مالک کے ذریعے درست کریں اور مطلوبہ نجی سابقے واضح طور پر دیں۔ اگر اسکرپٹ نے اندراج شامل کیا تو اسکرپٹ درست کریں۔ ایک غیر واضح چوڑے راستے کو دوسرے سے بدلنا علامت بدلتا ہے، سوال کا جواب نہیں دیتا۔
ماخذ درست کریں، پھر دونوں راستے دوبارہ جانچیں
تبدیلی کے بعد دوبارہ جڑیں اور ناکام عوامی سائٹ اور سرنگ استعمال کرنے والے وسیلے کے لیے تلاش دہرائیں۔ پہلا اب جسمانی انٹرفیس پر حل ہونا چاہیے، اور دوسرا اب بھی VPN منتخب کرنا چاہیے۔ پہلی کامیابی پر نہ رکیں؛ جو درستی نجی رسائی بھی توڑ دے وہ ایک خرابی کو دوسری سے بدل چکی ہے۔
اسی وقت سرور کے پتوں کا منصوبہ جائزہ لیں۔ عوامی فضا سے اوورلیپ ہوتا پول اس قسم کا مسئلہ بار بار پیدا کرتا ہے۔ وہ رینج جو آپریٹر نے جان بوجھ کر چنی ہو وہ خودکار دوبارہ نمبرکاری کی بجائے کسی اور گفتگو کی مستحق ہے۔
MTU بڑھانا یا DNS خالی کرنا اس سابقے کو درست نہیں کرے گا جو اب بھی اس پتے کو سرنگ میں بھیجتا ہے۔ پہلے انتخاب جانچیں، پھر راستہ۔