أنت داخل نافذة RDP، وسطح المكتب معروض على الشاشة، وتضغط Connect في عميل VPN العامل على ذلك الجهاز البعيد. بعد ثوانٍ يتجمّد العرض ثم يُغلق. لقد قام النفق، وهذا بالضبط ما سيسجله سجل VPN، وهو أقل حقيقة مفيدة في الحادثة كلها. ماتت الجلسة لأن الجهاز الذي كنت تتحدث إليه غيّر طريقة رده عليك، فاقرأ مسار العودة قبل أن تلمس النفق.

سجّل نقطة النهاية التي تستخدمها جلستك فعليًا

العنوان المكتوب في عميل RDP ليس بالضرورة العنوان الذي يردّ عليه الحاسوب البعيد. قد يعيد NAT أو بوابة RD أو موازن تحميل أمام المضيف كتابته، ويُحدَّد مسار العودة بالعنوان المصدري الذي يراه الجهاز البعيد على الاتصال القائم. والخطأ في ذلك يدفعك للبحث عن مسار لم يكن معنيًا أصلًا.

على الحاسوب البعيد، قبل توصيل VPN، اسرد الجلسات القائمة واقرأ عنوان النظير من الجدول. ثم اكتبه في مكان خارج ذلك الجهاز، لأنك لن تستطيع قراءته بعد سقوط الجلسة.

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

اعتبر ذلك العنوان هو الشيء الذي يجب أن يبقى قابلًا للوصول. فإن كان عنوانًا خاصًا على VLAN إدارية، فعلى النفق أن يترك ذلك المسار وشأنه. وإن كان عنوانًا عامًا، فعلى الرد أن يخرج عبر الواجهة نفسها التي حملت الطلب إلى الداخل.

اقرأ المسار الذي يردّ على تلك النقطة

يختار Windows واجهة لكل وجهة، و Find-NetRoute يوضح القرار الذي سيتخذه الآن. شغّله على عنوان النظير قبل التوصيل، ثم مرة أخرى والنفق قائم، وقارن فهرس الواجهة والخطوة التالية في الإجابتين. تغيّر الواجهة هو العطل كله في سطر واحد من المخرجات.

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

يثبّت ملف النفق الكامل مسارًا افتراضيًا عبر النفق، كما يوضّح دليل توجيه VPN في Windows، فيخرج كل رد الآن عبر VPN ويعتمد على توجيه الطرف الآخر عائدًا إلى عميلك. ملف النفق المنقسم أكثر أمانًا افتراضيًا لكنه ليس محصّنًا، لأن مسارًا محددًا يغطي عنوان النظير قد يتغلب على المسار الافتراضي الفعلي. وفي الحالتين السؤال واحد: بعد قيام النفق، هل ما زال عنوان النظير يُحلّ إلى الواجهة التي حملت الجلسة إلى الداخل؟

إن لم يكن كذلك، فالإصلاح مكانه الملف أو مسار استثناء صريح يوافق عليه مالك سياسة VPN. وتحرير جدول التوجيه يدويًا على مضيف إنتاج أثناء حادثة هو كيف يتحول حل مؤقت إلى إعداد غير موثّق.

راقب تغيّر ملف جدار الحماية

تُصنَّف الواجهة الجديدة عند ظهورها، والتصنيف يحدد ملف جدار الحماية الذي يُحكم به على حركتها. محوّل نفق يقع في فئة Public قد يوقف RDP الوارد بصمت حتى لو بدا جدول التوجيه سليمًا تمامًا. هذا هو نمط العطل الثاني، وهو ينتج عرضًا مختلفًا: المسار صحيح، والحزم تصل، والمضيف يرفض الاتصال.

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

قارن الملف المرتبط بواجهة النفق بالملفات التي تستهدفها قواعد Remote Desktop. قاعدة مفعّلة لـ Domain وPrivate فقط لا تفعل شيئًا لواجهة مصنّفة Public، ولا يغيّر ذلك أي قدر من تصحيح المسار. بعض عملاء VPN يقيّدون أيضًا الوصول إلى الشبكة الفرعية المحلية بحكم التصميم، وهذا ينتج الشكل نفسه من الفشل من ضابط مختلف.

اختبر الانتقال من مكان يمكنك الاستعادة منه

نفّذ التسلسل كله من طرفية خارج النطاق أو مسار إدارة ثانٍ، بهذا الترتيب: أكّد الجلسة القائمة، وصّل VPN، افتح جلسة جديدة، ثم افصل VPN وافتح أخرى. كل خطوة تختبر انتقالًا مختلفًا، وأول خطوة تفشل تخبرك أي ضابط هو المسؤول.

جدول الرجوع قبل أن تبدأ، مثلًا مهمة مجدولة تشغّل rasdial "Work VPN" /disconnect بعد فترة محددة. هذا يحوّل جلسة مفقودة إلى انقطاع مدته خمس دقائق بدلًا من زيارة للموقع، وهو أرخص تأمين في الإجراء كله.

عد إلى الداخل حين تكون الجلسة قد ضاعت بالفعل

إن كان المضيف غير قابل للوصول أصلًا، فأوقف محاولة اتصالات RDP جديدة من العميل نفسه واستخدم قناة الاستعادة التي يملكها البيئة أصلًا: بوابة RD أو طرفية محاكي أو واجهة إدارة خارج النطاق. اطلب من صاحب صلاحية الطرفية تنفيذ الأمرين نفسيهما Find-NetRoute و Get-NetConnectionProfile حتى تبقى الأدلة بعد الاستعادة.

ثم قرّر الترتيب الدائم لا الأسرع. إما أن يحافظ ملف VPN على مسار الإدارة صراحةً، وإما أن تنتقل الإدارة إلى قناة لا تعتمد على المسار الافتراضي للمضيف. كلاهما قابل للدفاع؛ أما مسار مضيف مع بوابة مخمّنة فليس كذلك. اكتب أي الخيارين اخترت، وسجّل عنوان النظير الذي كان عليه أن يصمد.

مقالات ذات صلة