مشاركة SMB تفشل عبر VPN فقط: توقيع أم تعارض شبكات فرعية؟
قد تفشل المشاركة التي تعمل على الشبكة المحلية عبر النفق فقط. افصل بين رفض التوقيع وشبكة فرعية متداخلة وجلسة 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. محول VPN بلا خادم DNS داخلي، أو بخادم غير قابل للوصول عبر النفق، يترك الأسماء القصيرة تذهب إلى محلل عام. اقرأ إدخالات 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 الخاملة وفق مؤقت Autodisconnect تحت LanmanServer\Parameters، وهو افتراضيًا 15 دقيقة، بينما لدى العميل SessTimeout الخاص به تحت LanmanWorkstation\Parameters. انقطاع أطول من هذه القيم يترك كل طرف بفكرة مختلفة عن الجلسة.
أعد إنتاج ذلك بترتيب ثابت ليكون للنتيجة معنى: وصّل النفق، وافتح المشاركة، واقطع النفق دقيقتين، ثم أعد توصيله، وحاول بعدها قراءة ملف. إذا تعافت نقطة الوصل من تلقاء نفسها، فاترك المؤقتات. إذا توقفت حتى تعيد الوصل، أعد توصيل المشاركة بعد أن يكون النفق قائمًا بدلًا من وصلها قبل وجوده، وتحقق مما إذا كان مساعد الوصل يعيد المحاولة.
رفع المهلات خطوة أخيرة معقولة لرابط غير مستقر، لكنه يعالج العَرَض. العميل الذي ينتظر مدة أطول جلسة نسيها الخادم لا يزال ينتظر.
أنهِ الأمر بقراءة ملف واحد عبر نقطة الوصل، ثم قطع النفق وإعادته مرة أخرى. يغطي اختبار القبول هذا الطبقات الثلاث دفعة واحدة، وهو الاختبار الوحيد الذي يطابق ما يفعله المستخدم حقًا.