قرص مُعين عبر VPN بين المواقع: DNS وSMB ومسار UNC
لا يعبر اكتشاف الشبكة رابطًا موجّهًا، لكن مسار UNC المسمّى يعبره. وجّه DNS إلى الخادم، وافتح SMB في الاتجاهين، ثم عيّن القرص.
تعرض صفحة الشبكة في المستكشف الأجهزة التي أعلنت عن نفسها في المقطع المحلي، ولا ينقل النفق الموجّه أيًا من هذه الإعلانات. لهذا قد يكون الخادم متاحًا تمامًا بينما تبقى النافذة أمام المستخدم فارغة. لا يعتمد مسار UNC المسمّى على الاكتشاف إطلاقًا، والحل هو جعل الاسم يُحلّ والمنفذ يجيب. النافذة الفارغة عرض للطبقة الخاطئة، لا لمشاركة معطلة.
الاكتشاف ليس هو نفسه الوصول
يعثر Windows على الأجهزة القريبة عبر بروتوكولات مصممة لنطاق بثّ، ثم يعرض ما وجده كقائمة للراحة. لا شيء في تلك القائمة مطلوب للوصول إلى الملفات عبر SMB. العميل الذي يعرف اسم الخادم ويصل إلى TCP 445 سيفتح المشاركة، سواء ظهر الجهاز يومًا ما ضمن الشبكة أم لا.
تفشل الطبقتان بشكل مستقل، ولهذا يستحق «لا أراه» و«لا أستطيع فتحه» اختبارين مختلفين. النظر إلى القائمة يخبر عن الاكتشاف، وفتح المسار يخبر عن الخدمة.
سمّ الخادم قبل أن تعيّن المشاركة
انشر خادم الملفات في DNS بالعنوان الذي يملكه في الجهة الأخرى، ووجّه موقع العميل إلى مُحلّل قادر على الإجابة عن تلك المنطقة. الاسم المؤهل بالكامل يتجنب الاعتماد على قائمة لاحقات بحث محلية، وهي السبب المعتاد في نجاح اسم قصير في موقع وفشله في آخر.
إذا كانت البيئة تستخدم Active Directory، فإن حل الأسماء جزء من المصادقة أيضًا: يحتاج العميل إلى الوصول إلى وحدة تحكم بالمجال من أجل Kerberos، والساعة المنحرفة كثيرًا ستُفشل تبادل التذاكر. هذه مشكلة مختلفة عن الوصول إلى SMB وتبدو كخطأ في بيانات الاعتماد. اختبر وحدة تحكم المجال قبل إعادة كتابة كلمة المرور.
| Layer | What it needs | Symptom when missing |
|---|---|---|
| Name resolution | A DNS answer for the server name | Path cannot be found, ping by IP still works |
| Transport | TCP 445 open in both directions | Connection times out or is refused |
| Authentication | A reachable domain controller and correct clock | Access is denied after the port connects |
| Authorization | Share permission and filesystem permission | The share opens but the folder is inaccessible |
التوجيه والتصفية في الاتجاهين
يحتاج النفق بين الموقعين إلى البادئة البعيدة في جدول التوجيه المحلي، وإلى البادئة المحلية في الجدول البعيد، ويجب أن تسمح الجدار الناري على كل جهة بالمرور الوارد. الإعداد أحادي الاتجاه ينتج اتصالًا يُفتح ولا يجيب أبدًا، وهو ما يصفه المستخدمون ببطء المشاركة. افحص أولًا عدادات النفق نفسه. إذا خرجت الحزم ولم يرجع شيء، فابحث عن مسار العودة أو المرشّح البعيد.
مع WireGuard، يجب أن تتوافق عناوين IP المسموح بها للنظير ومسارات نظام التشغيل مع ذلك التصميم. النفق ينقل الحزم؛ وهو لا يوفر سجلات DNS ولا أذونات المشاركة على أي من الجهتين.
ابنِ قاعدة الجدار الناري على شبكة المصدر الفعلية التي ستتصل، واكتب الاستثناء. إذا كان التصميم يترجم العناوين في مكان ما على المسار، فيجب أن تستخدم القاعدة المصدر المترجم، ولم يعد عنوان العميل الأصلي ظاهرًا في السجلات.
صادق أولًا، ثم عيّن القرص
انزل عبر الطبقات بالأوامر بدلًا من نافذة المستكشف:
Resolve-DnsName -Name files.corp.example -Type A
Test-NetConnection -ComputerName files.corp.example -Port 445
net use Z: \\files.corp.example\Projects /persistent:noالأمر الثاني يثبت مسار TCP، لا حق قراءة أي شيء. الأمر الثالث هو حيث تُمارس المصادقة والتفويض، والفشل هناك يجب أن يوجّهك إلى أذونات المشاركة ونظام الملفات، لا إلى الموجّه.
أبقِ توقيع SMB وسياسة المصادقة الحالية سليمة. إعادة تفعيل SMB1 أو تمرير بثّ الاكتشاف عبر النفق ليس مطلوبًا لمسار صريح، ويجب أن يبقى TCP 445 على المسار الخاص لا على تمرير متجه إلى الإنترنت. امنح المستخدمين اختصارًا مُدارًا أو قرصًا معينًا إلى الاسم المعتمد، وعندها تتوقف صفحة الشبكة الفارغة عن الأهمية.