SMB شیئر صرف VPN پر ناکام ہوتا ہے: دستخط یا سب نیٹ ٹکراؤ؟
جو شیئر LAN پر چلتا ہے وہ صرف ٹنل سے ناکام ہو سکتا ہے۔ دستخط کی مستردگی، متوازی سب نیٹ اور پرانا SMB سیشن الگ کریں۔
ایک میپ شدہ ڈرائیو جو دفتر میں چلتی ہے اور گھر پر وقت ختم کر دیتی ہے، بذات خود تقریباً کوئی کارآمد معلومات نہیں دیتی۔ ٹنل واضح طور پر پیکٹ منتقل کر رہا ہے، ورنہ سرور تک کچھ نہ پہنچتا۔ جو ناکام ہوا وہ تین تہوں میں سے ایک ہے: نام غلط پتے پر حل ہوا، کلائنٹ نے سیشن پر دستخط کرنے سے انکار کیا، یا پرانا سیشن اس کنکشن سے زیادہ زندہ رہا جس نے اسے اٹھایا تھا۔ ہر ایک کی مرمت مختلف ہے، اور تین میں سے دو کلائنٹ کی طرف ہیں۔
تین خرابیاں ایک ہی غلطی پہنتی ہیں
ڈرائیو کا حرف نہیں بتاتا کہ کون سی تہ ٹوٹی، اور غلطی کا متن عام طور پر اتنا عام ہوتا ہے کہ تینوں پر لاگو ہو۔ انہیں دو تیز سوالوں سے الگ کریں: کیا سرور اپنے IP پتے پر جواب دیتا ہے، اور کیا پورٹ 445 کنکشن قبول کرتا ہے؟
یہ جوابات اندازے کے بجائے فیصلے کا جدول بناتے ہیں۔ اگر IP چلتا ہے اور نام نہیں، تو یہ نام کے حل کی طرف اشارہ ہے۔ اگر دونوں چلتے ہیں اور لاگ اِن مسترد ہوتا ہے، تو یہ دستخط کی طرف اشارہ ہے۔ اگر دونوں چلتے ہیں اور ٹنل بندش کے بعد فائل پڑھنا رک جاتا ہے، تو یہ پرانے سیشن کی طرف اشارہ ہے۔
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session state and timers |
انہیں اسی ترتیب سے نبٹیں، کیونکہ غلط ہوسٹ پر حل ہونے والا نام ہر بعد کا ٹیسٹ بے معنی کر دیتا ہے۔
شیئر کو چھونے سے پہلے نام حل کریں
اگر سرور اپنے پتے پر جواب دیتا ہے اور شیئر کا نام وقت ختم کر دیتا ہے، تو ٹنل اپنا کام کر رہا ہے اور کلائنٹ غلط جگہ دیکھ رہا ہے۔ ریموٹ رسائی میں اس کی زیادہ تر وجہ دو چیزیں ہیں۔
پہلی پتوں کا ٹکراؤ ہے۔ جب دفتر 192.168.70.0/24 استعمال کرتا ہے اور گھر کا راؤٹر وہی رینج دیتا ہے، تو ایسا ہوسٹ نام جو 192.168.70.20 پر حل ہوتا ہے ٹنل کے پیچھے والے سرور کے بجائے مقامی ڈیوائس کی طرف اشارہ کر سکتا ہے۔ Windows پھر درخواست مقامی طور پر بھیج سکتا ہے، روٹ مسترد کر سکتا ہے، یا ایسی پرنٹر پر حل کر سکتا ہے جس کے پاس اتفاقاً وہ پتہ ہو۔ مرمت ایک طرف کو دوبارہ نمبر دینا ہے، نہ کہ ایک اور روٹ شامل کرنا۔
دوسری DNS کا دائرہ ہے۔ بغیر اندرونی DNS سرور والا VPN اڈاپٹر، یا ایسا سرور جو ٹنل سے ناقابل رسائی ہو، مختصر ناموں کو عوامی حل کنندہ تک جانے دیتا ہے۔ اڈاپٹر کے DNS اندراجات پڑھیں اور شیئر کو چھونے سے پہلے اندرونی نام سے براہِ راست پوچھیں:
> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15اگر یہ استفسار متوقع پتہ واپس کرے، تو نام کا حل طے ہو گیا اور مسئلہ اسٹیک میں اوپر ہے۔
دونوں سروں پر دستخط کی شرط پڑھیں
قابل رسائی سرور جو ہر لاگ اِن مسترد کرتا ہے، نیٹ ورک کی خرابی نہیں بلکہ پالیسی کی عدم مطابقت کی علامت ہے۔ Windows کلائنٹ پر SMB دستخط لازمی کر سکتا ہے، اور بغیر دستخط کرنے والا سرور یا NAS سیشن مکمل نہیں کر سکتا، چاہے ٹنل کتنا ہی صحت مند ہو۔
آپ کلائنٹ کی ترتیب پالیسی ایڈیٹر میں تلاش کیے بغیر پڑھ سکتے ہیں:
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionسرور کی طرف کا متعلقہ ویلیو سرور کی SMB کنفیگریشن میں ہے، اور دونوں کو متفق ہونا چاہیے۔ ایک رپورٹ شدہ کیس میں کلائنٹ پر شرط مقامی پالیسی سے فعال تھی جبکہ سرور بالکل دستخط نہیں کر رہا تھا؛ اسے غیر فعال کرنے اور gpupdate /force چلانے نے شیئر فوراً بحال کر دیا۔ یہ وجہ کی تصدیق کے لیے تشخیصی قدم ہے، مستقل حل نہیں۔
جہاں سرور معاونت کرتا ہو وہاں دونوں سروں پر دستخط فعال کرنے کو ترجیح دیں۔ شیئر کے کام کرنے کے لیے سیکیورٹی کی ترتیب بدلنے کو اس کی پچھلی ویلیو اور وجہ کے ساتھ ریکارڈ کرنا چاہیے، تاکہ اگلے آڈٹ میں کسی کو اسے دوبارہ دریافت نہ کرنا پڑے۔
ٹائمر ایڈجسٹ کرنے سے پہلے پرانا سیشن صاف کریں
وہ شیئر جو صرف VPN گرنے اور دوبارہ جڑنے کے بعد رکتا ہے، عام طور پر ایسا سیشن رکھتا ہے جسے سرور پہلے ہی رد کر چکا ہوتا ہے۔ سرور غیر فعال SMB سیشنز کو LanmanServer\Parameters کے تحت Autodisconnect ٹائمر پر بند کرتا ہے، جو بطور ڈیفالٹ 15 منٹ ہے، جبکہ کلائنٹ کا اپنا SessTimeout LanmanWorkstation\Parameters کے تحت ہے۔ ان ویلیوز سے طویل بندش ہر سر کو سیشن کے بارے میں مختلف تصور دے جاتی ہے۔
اسے مقررہ ترتیب میں دہرائیں تاکہ نتیجہ کچھ معنی رکھے: ٹنل جوڑیں، شیئر کھولیں، ٹنل دو منٹ کے لیے بند کریں، اسے بحال کریں، پھر فائل پڑھنے کی کوشش کریں۔ اگر ماؤنٹ خود بحال ہو جائے تو ٹائمر چھوڑ دیں۔ اگر دوبارہ ماؤنٹ کرنے تک رکا رہے تو ٹنل کھڑا ہونے کے بعد شیئر دوبارہ جوڑیں، اسے وجود سے پہلے جوڑنے کے بجائے، اور دیکھیں کہ ماؤنٹ مددگار دوبارہ کوشش کرتا ہے یا نہیں۔
ٹائم آؤٹ بڑھانا غیر مستحکم لنک کے لیے معقول آخری قدم ہے، لیکن یہ علامت کا علاج ہے۔ ایسا کلائنٹ جو سرور کے بھولے ہوئے سیشن کا زیادہ دیر انتظار کرے وہ پھر بھی انتظار کرتا ہے۔
اختتام ماؤنٹ کے ذریعے ایک فائل پڑھنے اور پھر ایک بار مزید ٹنل بند کر کے بحال کرنے پر کریں۔ یہ قبولیت ٹیسٹ تینوں تہوں کو ایک ساتھ ڈھانپتا ہے، اور یہ واحد ٹیسٹ ہے جو صارف کے حقیقی عمل سے مطابقت رکھتا ہے۔