Windows میں VPN 255.255.255.255 دکھا رہا ہے: کیا ماسک غلط ہے؟
پوائنٹ ٹو پوائنٹ ٹنل میں ہوسٹ ماسک معمول ہے۔ انٹرفیس ماڈل کی تصدیق کریں، ناکام ہوسٹ کا روٹ پڑھیں اور DNS کو سروس تک رسائی سے الگ کریں۔
ٹنل جڑ جاتا ہے، آپ اڈاپٹر کی تفصیلات کھولتے ہیں اور ماسک 255.255.255.255 دکھاتا ہے۔ دفتر کے LAN کے 255.255.255.0 کے مقابلے میں یہ خراب لگتا ہے اور غلطی عموماً یہیں شروع ہوتی ہے۔ پوائنٹ ٹو پوائنٹ لنک پر ہوسٹ ماسک مقامی سرے کی درست وضاحت ہے، اور دور دراز نیٹ ورکس منسلک سب نیٹ کے بجائے روٹس کے طور پر آتے ہیں۔ نیچے دیا گیا طریقہ دونوں سوالات کو الگ کرتا ہے تاکہ آپ صرف دکھائی دینے والی قدر درست کرنے کے لیے کام کرنے والا DHCP دائرہ دوبارہ نہ بنائیں۔
پوائنٹ ٹو پوائنٹ لنک Ethernet کا قطعہ نہیں
Ethernet انٹرفیس کو سب نیٹ ماسک درکار ہے کیونکہ اس رینج کا ہر پتہ اسی کیبل پر ممکنہ طور پر قابل رسائی ہے۔ PPP طرز کے ٹنل کا دوسرے سرے پر بالکل ایک ساتھی ہوتا ہے۔ یہاں کوئی براڈکاسٹ ڈومین نہیں، کوئی ARP نہیں اور کوئی وجہ نہیں کہ مقامی پتہ کسی رینج کی وضاحت کرے۔
اس ماڈل کے لیے پتوں کی گفت و شنید RFC 1332 میں بیان کی گئی ہے، جو بتاتی ہے کہ دونوں سرے اپنے پتوں پر کیسے متفق ہوتے ہیں۔ جو یہ نہیں کرتی وہ یہ ہے کہ کلائنٹ کو دفتر کا LAN براہ راست منسلک نیٹ ورک کے طور پر دے۔ کلائنٹ یہ سیکھتا ہے کہ دفتر کہاں ہے لنک کے ذریعے روٹس نصب کر کے، اور یہی روٹس درحقیقت رسائی کا تعین کرتے ہیں۔
اس کا مطلب یہ نہیں کہ آپ کو نظر آنے والا ہر ماسک درست ہے۔ غلط ترتیب شدہ کلائنٹ بھی عجیب ایڈریسنگ پیدا کر سکتا ہے۔ نکتہ تنگ ہے: اس قسم کے اڈاپٹر پر ہوسٹ ماسک متوقع ہے، اس لیے بذات خود خرابی کا ثبوت نہیں۔
مرحلہ 1: انٹرفیس ماڈل کی تصدیق کریں
یہ فیصلہ کرنے سے پہلے کہ یہ کیا کہتا ہے، دیکھیں کہ اڈاپٹر کیا ہے۔ تفصیل کا سلسلہ ڈرائیور کی نشاندہی کرتا ہے، اور تفویض شدہ پتے پر سابقہ کی لمبائی تصدیق کرتی ہے کہ کلائنٹ نے کس بات پر اتفاق کیا:
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtuتیسری ہدایت وہ ہے جو زیادہ تر بحثیں ختم کرتی ہے۔ کم سے کم زیادہ سے زیادہ ترسیلی اکائی encapsulated لنک کی خصوصیت ہے، جبکہ Ethernet جیسی قدر مختلف مجازی اڈاپٹر ماڈل کی طرف اشارہ کرتی ہے۔ اگر تفصیل PPP یا RAS ڈرائیور کا نام لے اور سابقہ 32 ہو، تو آپ بالکل وہی ڈیزائن دیکھ رہے ہیں جو اوپر بیان ہوا اور ماسک کی فکر چھوڑ سکتے ہیں۔
| Observation | What it means | Reasonable next step |
|---|---|---|
| /32 on a PPP or RAS adapter | Point-to-point endpoint addressing | Look at routes, not the mask |
| /32 on an Ethernet-like adapter | Client chose host addressing deliberately | Confirm against the server's push policy |
| Mask differs from the office LAN | Usually irrelevant to reachability | Test the destination instead |
مرحلہ 2: ناکام منزل کا روٹ پڑھیں
رسائی کا تعین ہر منزل کے لیے ہوتا ہے، اور ایک منسلک انٹرفیس اس بارے میں کچھ نہیں بتاتا۔ روٹ ٹیبل سے براہ راست وہ پتہ پوچھیں جس تک صارف واقعی پہنچنے کی کوشش کر رہا ہے:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute براہ راست جواب ہے: یہ وہ انٹرفیس اور ماخذ پتہ بتاتا ہے جو نظام اس منزل کے لیے استعمال کرے گا۔ اگر یہ ٹنل واپس کرے تو اس ہوسٹ کی ٹریفک ٹنل سے گزرتی ہے اور ماسک کبھی مسئلہ نہیں تھا۔
اگر یہ فزیکل اڈاپٹر واپس کرے تو دو ممکنہ روٹس اور ان کے پیمانے موازنہ کریں۔ زیادہ مخصوص مقامی روٹ، دوسرے کلائنٹ سے بچا ہوا اندراج یا فزیکل راستے پر کم پیمانہ سب وسیع ٹنل روٹ پر غالب آتے ہیں۔ نظر آنے والا نتیجہ ایسا وسیلہ ہے جس تک رسائی نہیں جبکہ باقی سب کچھ کام کر رہا ہو۔ لمبے سابقے ہمیشہ جیتتے ہیں، اس لیے جیتنے والا اکثر وہ ہوسٹ روٹ ہوتا ہے جو کسی نے مہینوں پہلے شامل کیا اور بھول گیا۔
یہاں دونوں سمتوں کی بھی جانچ کریں۔ سرور کی طرف روٹ ضروری ہے مگر کافی نہیں، کیونکہ جواب بھی ٹنل سے واپس آنا چاہیے۔ جب ایک اندرونی ہوسٹ کام کرے اور دوسرا نہ کرے، فرق عموماً اسی ٹیبل میں ہوتا ہے نہ کہ اڈاپٹر کی ترتیب میں۔
مرحلہ 3: نام کی حل کو سروس تک رسائی سے الگ کریں
وہ ایپلیکیشن جو شیئر نہیں کھول پاتی، دو بہت مختلف مراحل میں سے کسی ایک پر ناکام ہو سکتی ہے۔ نام حل کریں، پھر پتے تک پہنچیں۔ اگر پہلا ناکام ہو اور دوسرا کام کرے تو ٹنل ٹھیک ہے اور حل کنندہ نہیں:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445کامیاب پتہ ٹیسٹ کے ساتھ ناکام نام ٹیسٹ مسئلے کو حل کرنے میں مقامی کرتا ہے، اور دوسری ہدایت دکھاتی ہے کہ ٹنل انٹرفیس کو سرور ملا بھی یا نہیں۔ بہت سے کلائنٹ DNS کو ٹنل ترتیب کے حصے کے طور پر دھکیلتے ہیں، اور وہ پروفائل جو ان دھکیلے گئے اختیارات کو نظر انداز کرے مشین کو ایسے حل کنندہ کے ساتھ چھوڑ دے گا جو نجی زون نہیں دیکھتا۔
کام کرنے والے پتے کو مستقل حل نہ سمجھیں۔ پتے کے ذریعے جڑنا نام کی حل کو نظر انداز کرتا ہے اور سرور کی شناخت کی جانچ کو کمزور کر سکتا ہے جو ایپلیکیشن بصورت دیگر کرتی۔ یہ حفاظتی پس قدم ہے جو عارضی حل کا روپ دھارتا ہے۔ اسے خرابی کی نشاندہی کے لیے استعمال کریں، پھر حل درست کریں۔
واپسی: دکھائی دینے والی قدر کی خاطر DHCP دوبارہ نہ بنائیں
اگر آپ ایڈریسنگ سروس بدلنا شروع کر چکے ہیں تو رکیں اور دیکھیں کہ آپ نے جو کچھ بدلا اس میں سے کوئی چیز بوجھ اٹھانے والی ہے یا نہیں۔ دائرہ دوبارہ بنانا، لیز دوبارہ جاری کرنا یا پول منتقل کرنا ایسی حالت بدلتا ہے جس پر دوسرے کلائنٹ انحصار کرتے ہیں، اور ان میں سے کوئی چیز پوائنٹ ٹو پوائنٹ اڈاپٹر پر ہوسٹ ماسک سے جائز نہیں ٹھہرتی۔
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445یہ تینوں کسی بھی ہدف شدہ تبدیلی کے بعد چلائیں اور پچھلی اجرا سے موازنہ کریں۔ مفید نتیجہ وسیلے تک دستاویزی راستہ ہے، نہ کہ ایسا اڈاپٹر جس کا ماسک دفتر کے LAN جیسا لگے۔
پھر لکھیں کہ ماسک کا واقعی کیا مطلب تھا، کیونکہ اگلا شخص وہی مکالمہ کھولے گا اور وہی غلط نتیجہ اخذ کرے گا۔ پروفائل نوٹس میں ایک جملہ، کہ ٹنل پوائنٹ ٹو پوائنٹ ہے اور دور دراز سب نیٹ روٹس کے طور پر آتے ہیں، اگلی بار پوری تفتیش بچا دیتا ہے۔