هل يمكن للـ VPN أن يحل محل سطح المكتب البعيد؟ ما الذي يقدمه كل منهما

تُفتح نافذة، وتطلب بيانات الاعتماد، ثم تبقى فارغة أو تنقطع، فيبلّغ المستخدم أن الـ VPN أفسد الوصول البعيد. أحياناً يكون النفق سليماً ولم تبدأ الجلسة أبداً. معرفة أين يعمل التطبيق فعلياً هي ما يفصل بين الحالتين، لأن النفق وجلسة سطح المكتب يقدّمان أشياء مختلفة ويفشلان في مواضع مختلفة.

النفق يمنح جهازك مساراً إلى شبكة ما. أما جلسة سطح المكتب فتمنحك شاشة ولوحة مفاتيح موصولتين بجهاز آخر.

الأعراض تتوقف على المكان الذي يعمل فيه التطبيق

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

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

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

الأداء يتبع طبيعة العمل لا التسمية

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

هذا الفرق يهم عندما يبلّغ أحدهم عن بطء. فالجلسة البعيدة التي تبدو متلكئة أثناء الكتابة تتأثر بزمن الذهاب والإياب، بينما فتح ملف مباشرة عبر النفق نفسه يتأثر بمعدل النقل. قِس المهمة بدل رقم سرعة عام، واختبر العملية المحددة التي يشكو منها المستخدم.

العمل التفاعلي عبر مسار عالي التأخير يسوء كلما تغيّر جزء أكبر من الشاشة، ولهذا يختلف الإحساس بتمرير مستند عن النظر إلى نافذة ساكنة. وإذا كانت الشكوى عن الاستجابة لا عن زمن الإنجاز، فإن موقع عبء العمل هو المتغير الذي يستحق التغيير.

افحص كل طبقة على حدة عند الفشل

اعمل من الخارج إلى الداخل وسجّل ما تعيده كل خطوة، لأن إعادة تشغيل كل شيء دفعة واحدة تهدر الدليل. تأكد من أن النفق قائم، ثم تأكد من أن المسار الخاص يُحلّ، ثم تأكد من أن مضيف الجلسة يقبل الاتصالات، ثم تأكد من أن حسابك مسموح عليه.

Test-NetConnection -ComputerName 172.20.8.30 -Port 3389
Resolve-DnsName workstation-14.corp.example
qwinsta /server:172.20.8.30

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

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

حدّد ما يجب أن يبقى داخل المؤسسة

افتراض أن الجلسة البعيدة تُبقي كل مستند في مركز البيانات غير آمن. فمشاركة الحافظة والأقراص المعاد توجيهها والطباعة يمكنها نقل المعلومات بين البيئتين كلما سمحت السياسة بذلك، والنفق لا يقيّد الملفات التي ينسخها مستخدم مصرّح له من مشاركة يمكن الوصول إليها. وإذا كان الحصر هو المطلوب، فراجع ضوابط النقل الفعلية للجلسة بدل الثقة بمخطط البنية. اسأل مالك الجلسة عن إعادة التوجيه المفعّلة قبل أن تعِد بشيء نيابة عنه.

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

سجّل أي طبقة فشلت، وما غيّرته، وما ينبغي للمستخدم إعادة اختباره. ذلك السجل أثمن من حل لا يستطيع أحد إعادة إنتاجه.