האם VPN יכול להחליף את שולחן העבודה המרוחק? מה כל אחד עושה

נפתח חלון, מבקש פרטי התחברות, ואז נשאר ריק או נופל, והמשתמש מדווח שה-VPN שבר את הגישה מרחוק. לפעמים המנהרה תקינה וההפעלה מעולם לא החלה. הידיעה היכן האפליקציה באמת פועלת היא מה שמפריד בין המקרים האלה, כי מנהרה והפעלת שולחן עבודה מספקות דברים שונים ונכשלות במקומות שונים.

מנהרה נותנת למכשיר שלכם נתיב אל תוך רשת. הפעלת שולחן עבודה נותנת לכם מסך ומקלדת המחוברים למכונה אחרת.

התסמין תלוי במקום שבו האפליקציה פועלת

בגישה ישירה דרך מנהרה, האפליקציה פועלת על המכשיר שלכם והבקשות שלה חוצות את המסלול הפרטי המורשה אל שיתוף קבצים או אתר פנימי. אם האפליקציה הזו נכשלת, אתם מסתכלים על בעיית פתרון שמות או ניתוב, והתוכנית המקומית מתנהגת אחרת כרגיל.

בהפעלה מרחוק, האפליקציה פועלת על המכונה המרוחקת והמכשיר שלכם מקבל תמונה שלה. זה משנה את רשימת התקלות כליל: מארח ההפעלה חייב להיות זמין, השירות שמקבל חיבורים חייב להאזין, והחשבון שלכם חייב להיות מורשה גם במנהרה וגם במארח. חלון ריק לאחר התחברות מוצלחת למנהרה בדרך כלל אומר שהאימות השני מעולם לא הצליח.

שתי התצורות יכולות להתקיים זו לצד זו עבור אותו משתמש. סידור נפוץ דורש קודם את המנהרה ואחר כך הפעלת שולחן עבודה בתוכה, ולכן כל כך קל לקרוא הצלחה חלקית כתכונה אחת שבורה.

הביצועים הולכים אחרי עומס העבודה, לא אחרי התווית

פתיחת קובץ גדול ישירות דרך מנהרה מעבירה את הקובץ ברשת, וההשהיה הנראית לעין עוקבת אחרי ההעברה ולא אחרי הלחיצה. בהפעלה מרחוק הקובץ אולי לעולם לא יעזוב את מרכז הנתונים, מה שמסיר את ההעברה ומחליף אותה ברענון מסך ובהשהיית קלט. אף אחת משתי התצורות אינה מהירה יותר באופן כללי, כי הן מעבירות דברים שונים. שאלו אחרי איזו כמות המשתמש באמת ממתין לפני שתבחרו מדד.

ההבדל הזה חשוב כשמישהו מדווח על איטיות. הפעלה מרחוק שמרגישה איטית בזמן הקלדה רגישה להשהיית הלוך ושוב, ואילו פתיחת קובץ ישירות דרך אותה מנהרה רגישה לתפוקה. מדדו את המשימה ולא מספר מהירות כללי, ובדקו בדיוק את הפעולה שעליה המשתמש מתלונן.

עבודה אינטראקטיבית על נתיב בעל השהיה גבוהה נעשית גרועה יותר ככל שיותר מהמסך משתנה, ולכן גלילה במסמך מרגישה אחרת מצפייה בחלון סטטי. אם התלונה היא על היענות ולא על זמן השלמה, מיקום עומס העבודה הוא המשתנה ששווה לשנות.

בדקו כל שכבה בנפרד כשהיא נכשלת

עבדו מבחוץ פנימה ותעדו מה כל שלב מחזיר, כי אתחול הכול בבת אחת הורס את הראיות. ודאו שהמנהרה פעילה, אחר כך שהמסלול הפרטי נפתר, אחר כך שמארח ההפעלה מקבל חיבורים, אחר כך שהחשבון שלכם מורשה בו.

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

מסלול שעונה ופורט שמסרב הם תוצאות שונות, ופורט שעונה בזמן שפרטי ההתחברות שלכם נדחים הוא תוצאה שלישית. היכן שהפריסה משתמשת בשער גישה מנוהל במקום במנהרה אל המשרד, לכו אחרי הארכיטקטורה הזו ולא אחרי חשיפת שירות שולחן עבודה לאינטרנט מפני שמסלול פרטי נכשל.

הצפנה והרשאה הן גם משימות נפרדות. המנהרה מצפינה את הנתיב, ואילו פרוטוקול ההפעלה מאמת אתכם מול מארח והאפליקציה עשויה לאמת אתכם שוב. מעבר הבדיקה הראשונה לא אומר דבר על השלישית, וההנחיות להגעה למחשב מרוחק מחוץ לרשת מתארות את החלקים שפריסה עובדת זקוקה להם.

החליטו מה חייב להישאר בתוך הארגון

ההנחה שהפעלה מרחוק משאירה כל מסמך במרכז הנתונים אינה בטוחה. שיתוף לוח גזירים, כוננים מופנים והדפסה יכולים להעביר מידע בין שתי הסביבות בכל פעם שהמדיניות מתירה זאת, ומנהרה אינה מגבילה אילו קבצים משתמש מורשה מעתיק משיתוף נגיש. אם הבידוד הוא הדרישה, עברו על בקרות ההעברה בפועל של ההפעלה ולא אחרי תרשים הארכיטקטורה. שאלו את בעל ההפעלה אילו הפניות מופעלות לפני שתבטיחו משהו בשמו.

משך החיים של ההפעלה הוא ההפתעה האחרת. סגירת החלון יכולה להשאיר את ההפעלה פועלת במארח, כך שאובדן המנהרה אולי רק הופך אותה לבלתי נגישה זמנית. למדו את הדרך המאושרת לסיים עבודה במכונה משותפת, ובדקו את המארח לאחר מכן במקום להניח שההתנתקות קרתה.

רשמו איזו שכבה נכשלה, מה שיניתם ומה המשתמש צריך לבדוק שוב. התיעוד הזה שווה יותר מפתרון שאף אחד לא יכול לשחזר.