VPN يحجب شبكة LAN المحلية على Windows: مشكلة مسار أم سياسة عميل؟
ينقطع الوصول إلى شبكة LAN المحلية على Windows لسببين مختلفين: مسار مفقود، أو سياسة بوابة تُسقط الشبكة الفرعية. ثلاثة فحوص تحدّد أيّهما.
تتوقف الطابعة أو وحدة NAS أو جهاز التطوير على مكتبك عن الاستجابة لحظة اتصال VPN الخاص بالعمل. أحيانًا يصلح أمر مسار واحد المشكلة في ثوانٍ؛ وأحيانًا يكون المسار نفسه صحيحًا ومع ذلك تختفي الحزم، ما يعني أنك تنظر إلى مشكلة مختلفة بعَرَض مشابه. يعود القرار إلى ثلاثة أسئلة، وطرحها بترتيب خاطئ هو سبب إضاعة الناس أمسية كاملة في حذف المسارات وإعادة إضافتها.
ثلاثة أسئلة قبل أي أمر
أولًا: هل يوجد إدخال للبادئة المحلية، وهل يشير إلى المحوّل الفيزيائي؟ ثانيًا: هل يتلقى العميل إذنًا أو منعًا للوصول إلى الشبكة المحلية من البوابة عند الاتصال؟ ثالثًا: هل تحتاج إلى وصول صادر إلى LAN فقط، أم يجب أن يصل شيء على الإنترنت أيضًا إلى خدمة تعمل على جهازك؟
السؤال الأول يفصل عطل التوجيه عن عطل التصفية. والثاني يخبرك ما إذا كان إصلاح التوجيه مسموحًا له بالعمل أصلًا. والثالث يغيّر طريقة الإصلاح: المسار يصلح حركة المرور الصادرة، بينما الخدمة الواردة غير القابلة للوصول هي عادةً مشكلة ربط المستمع ومسار العودة، والمسار يزيدها سوءًا.
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
السؤال الأول: مسار أم تصفية أم اسم
اقرأ الجدول قبل أن تضيف إليه أي شيء. فهرس الواجهة مهم، لأن كل أمر مسار أدناه مرتبط به:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricتحتفظ الشبكة الفرعية المتصلة مباشرة عادةً بمسار على الوصلة حتى مع ارتفاع النفق، لذا قد يوجد إدخال ومع ذلك تفشل الحركة. هذا المزيج هو بصمة مرشّح يعمل بعد التوجيه، وهي الحالة التي لا يغيّر فيها مسار ثانٍ أكثر تحديدًا شيئًا على الإطلاق.
اختبر بالعنوان وبالاسم بشكل منفصل. إذا استجاب ping 192.168.1.50 ولم يستجب net view 192.168.1.50، فجدول التوجيه لم يكن المشكلة قط: النفق غيّر محلّل الأسماء ولم يعد الاسم المحلي يُحلّ. وإضافة مسار لذلك عمل مهدور.
السؤال الثاني: هل تسمح البوابة بالوصول إلى LAN المحلية؟
العميل التجاري يثبّت أكثر من مسارات. إنه يتلقى سياسة عند الاتصال، وقد تتضمن تلك السياسة إذنًا صريحًا بالوصول إلى الشبكة المحلية. في نشر Cisco IPsec تحمل سياسة المجموعة إعداد النفق المنقسم وعلمًا منفصلًا للوصول إلى LAN المحلية؛ ومربع الاختيار في العميل طلب قد ترفضه البوابة. في AnyConnect يتحكم الملف الشخصي في قائمتي التضمين والاستبعاد وفي الإذن نفسه. وعلى Windows RRAS فإن المكافئ هو خيار البوابة الافتراضية في الملف الشخصي إضافةً إلى المسارات الثابتة التي يعيّنها الخادم.
عندما يكون العلم مغلقًا، فالسلوك الموثّق هو أن العميل يحجب الحركة إلى الشبكة الفرعية المتصلة مباشرة رغم وجود مسار صالح أكثر تحديدًا. ولهذا أيضًا قد تختفي مسارات لا يملكها العميل بعد ثوانٍ من إضافتها: العميل يعيد بناء الحالة التي أُمِر ببنائها، لا يصارعك.
يسجّل سجل العميل القرار عند الاتصال، وقراءته أسرع من أي تجربة على الجهاز. إذا قال السجل إن الوصول المحلي محجوب، فتوقف: لا ينجو أي إصلاح من سطر الأوامر من ذلك، والمسارات المتبقية هي تغيير السياسة، أو الوصول إلى المورد عبر النفق، أو حصر العميل في جهاز افتراضي وترك المضيف على الشبكة المحلية.
السؤال الثالث: أي اتجاه تحتاج؟
حركة المرور الصادرة إلى جهاز قريب مسألة توجيه. وجّه بادئة LAN إلى البوابة المحلية بمعيار منخفض بما يكفي للتغلب على المسار الافتراضي للنفق:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -pالصيغة الثانية تثبّت جهازًا واحدًا، وهذا ما تريده عندما يكون عنوان واحد هو كل المتطلبات. والمكافئ netsh يسجّل القرار نفسه باسم الواجهة بدل الفهرس:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentتفشل أوامر المسار مع المعلمة غير صحيحة عندما يتعارض العنوان مع القناع، مثل عنوان مضيف بقناع /24. استخدم عنوان الشبكة لمسار شبكة فرعية وقناع مضيف لمضيف واحد.
الوارد مختلف. يصبح خادم VNC أو SSH على الجهاز نفسه غير قابل للوصول عندما تغادر ردود الاتصال الوارد عبر بوابة VPN ولا تعود أبدًا. تحقق مما يستمع عليه الخدمة قبل لمس المسارات:
netstat -ano | findstr :5900المستمع المرتبط بعنوان واحد محدد لن يستجيب على الواجهة الأخرى. وربطه بجميع الواجهات قرار متعمد، يُتخذ مع قاعدة جدار حماية مقيّدة بالشبكة التي تثق بها. وبعد ذلك فقط يعيد إصلاح المسار مسار العودة.
طبّق أصغر تغيير مطابق
الخطوة الشائعة الأخرى هي إلغاء تحديد “استخدام البوابة الافتراضية على الشبكة البعيدة” في خصائص IPv4 المتقدمة. يبقي حركة الإنترنت محلية، لكنه يفعل شيئين في آن واحد: يتوقف VPN عن كونه المسار الافتراضي، ويتوقف العميل عن تلقي مسارات الشبكة البعيدة، بما في ذلك multicast. ألغِ تحديده وتختفي LAN البعيدة ما لم يدفع الخادم البادئات البعيدة المحددة التي يحتاجها كل عميل.
هذا التفاوت يحدد ترتيب العمل. إذا كان يجب أن يبقى الجانب البعيد متاحًا بالكامل، فادفع الشبكات الفرعية البعيدة من الخادم واترك الافتراضي المحلي كما هو. وإذا لم تستطع تغيير الخادم، فأضف مسارًا دائمًا إلى البادئة البعيدة عبر العنوان الذي خصصه النفق، وتحقق باستخدام route print من أن البادئة تشير إلى واجهة VPN بينما لا يزال الافتراضي يشير إلى البوابة الفيزيائية.
ثم أكّد أن الإصلاح يبقى بعد إعادة الاتصال، لأن المسارات غير الدائمة تموت مع المحوّل، والسكربت الذي يعمل بعد كل اتصال هو المكان الصادق لها. اختبر جهازًا محليًا وموردًا بعيدًا في الجلسة نفسها، ثم افصل وأعد الاتصال واختبر مرة أخرى. إذا ظل الجهاز المحلي يفشل بينما يبدو المسار صحيحًا، فعد إلى السؤال الثاني: العميل يصفّي، والجواب تغيير في السياسة لا مسار ثانٍ منافس.