RemoteEnable אינו כניסת VPN: תיחום ניהול SoftEther
RemoteEnable מעניק ניהול מרחוק של שירות לקוח SoftEther. זו אינה כניסת VPN ואינה בדיקת זהות שרת. הפרידו בין השלושה.
המדריך אומר להריץ RemoteEnable ואז להתחבר, וזה נקרא כאילו שני השלבים הם אותו סוג של דבר. הם לא. RemoteEnable נותן למכונה אחרת הרשאה לנהל את שירות לקוח SoftEther VPN שרץ במחשב הזה. חיבור הוא חשבון VPN שמאמת את עצמו מול שרת, ואין בו כלל הרשאת ניהול.
המיתוס: RemoteEnable מדליק את ה-VPN
הבלבול נובע מסמיכות. מדריך מפעיל ניהול מרחוק, מפעיל מחדש את שירות הלקוח, ואז מתחבר, והחיבור עובד לאחר מכן, כך ששני השלבים נראים קשורים סיבתית. מה שבאמת השתנה הוא מי רשאי לדבר עם השירות, ולא אם השירות יכול להגיע לשרת. השביתו ניהול מרחוק בלקוח שהוגדר כראוי והחיבור ל-VPN עדיין עולה.
עזרת הפקודה במקור המקורי מפורשת לגבי ההיקף: ניהול מרחוק דרך VPN Client Manager או vpncmd מחוץ ל-localhost. שום דבר בתיאור הזה אינו מזכיר מנהרה, חשבון או מסלול. ההרשאה הניתנת היא טווח ניהולי, והנושא שלה הוא שירות הלקוח ולא החיבור.
שלוש זהויות שחולקות את המילה סיסמה
מדריכים ישנים משתמשים במילה אחת לשלושה אמצעי אימות לא קשורים, וכך פריסות מגיעות עם סוד שהודבק בשדה הלא נכון.
סיסמת הניהול של שירות הלקוח מגנה על הניהול של לקוח SoftEther המקומי. סיסמת חשבון ה-VPN מאמתת את עצמה מול שרת לפי המדיניות של אותו שרת. תעודת השרת אינה סיסמה כלל, אבל היא עונה איזו נקודת קצה הלקוח צריך לקבל. שינוי של אחד מהם אינו משנה את האחרים, והעתקת ערך ביניהם יוצרת תצורה אחרת ולא פשוטה יותר.
האפשרות מרחוק בלבד בסיסמת הניהול ראויה למבט שני, כי היא קובעת אם דרישת הסיסמה חלה גם על ניהול מהמכונה המקומית. צמצום ההיקף הזה הוא בחירה מכוונת למחשב נייד של משתמש יחיד, לא קיצור דרך לסיסמה שאיש לא תיעד.
מה הפעלת ניהול מרחוק באמת משנה
שתי השלכות תפעוליות נובעות מכך, ושתיהן קלות לפספוס במדריך העתק-הדבק. סיסמת ניהול הופכת לחובה ברגע שהניהול מרחוק מופעל, והזמינות החדשה נכנסת לתוקף רק לאחר שהשירות מופעל מחדש.
ההפעלה מחדש הזו היא הפרעה אמיתית לכל מה שמשתמש בלקוח, לכן תכננו אותה עם מי שמחזיק במכונה. הפעלת התכונה גם אינה פותחת מסלול בחומת האש מעצמה: השירות חייב עדיין להיות נגיש מתחנת הניהול, וחומת אש של המארח או ACL במעלה הזרם יכולים להשאירו בלתי נגיש. שירות בלתי נגיש אינו הוכחה שההרשאה תוחמה נכון, אלא שרק משהו אחר חוסם אותה.
כתבו את נתיב הניהול המיועד בהערות הפריסה, כולל הפורט וטווח הכתובות שמורשה להשתמש בו. אותה הערה היא גם המקום לתעד מי ביקש את היכולת ומתי יש לבטל אותה.
החליטו מי רשאי לנהל את הלקוח הזה
במחשב נייד בבעלותכם, השאירו את הניהול בקונסולה המקומית אלא אם תוכלו לנקוב במכונה שזקוקה לגישה מרחוק ולומר מדוע. במכשיר המנוהל באופן מרכזי, נקבו במנהל, בנתיב הניהול ובאחראי השחזור לפני הפעלת משהו. השאלה אינה אם התכונה נוחה, אלא מי אחראי לתצורה שהיא חושפת.
הריצו את הפקודות מול השירות המקומי כדי שהשינוי ייכנס להיסטוריית ה-shell שלכם ולא לצילום מסך: vpncmd localhost /client /cmd RemoteDisable מכבה את היכולת, ואותה פקודה עם RemoteEnable מדליקה אותה. הפעילו מחדש את השירות לאחר מכן, אחרת ההגדרה לא תהיה בתוקף.
אם מדריך מפעיל אותה כשלב מקדים בלי הסבר, התייחסו לכך כאל שאלה לא פתורה ולא כאל הוראה לביצוע. שאלו איזו תחנת ניהול אמורה להשתמש בה, ואם אין תשובה, השאירו את היכולת מושבתת.
אמתו גישת ניהול וקישוריות בנפרד
שני מבחנים עונים על שתי שאלות שונות, והרצת רק אחד מהם היא הדרך שבה פריסה מסתיימת בניהול מרחוק שאיש לא התכוון אליו.
vpncmd localhost /client /cmd RemoteDisable
systemctl restart vpnclient
vpncmd localhost /client /cmd AccountList
vpncmd localhost /client /cmd NicList
שתי השורות הראשונות מחזירות את הלקוח לניהול מקומי ומחילות את השינוי. שתי השורות האחרונות מאשרות שחשבונות ה-VPN והמתאמים הווירטואליים עדיין מוגדרים, כפי שהם אמורים להיות, כי היקף הניהול ומצב החיבור הם הגדרות בלתי תלויות. אם רשימת החשבונות חוזרת ריקה לאחר ההפעלה מחדש, משהו אחר נשבר והגדרת הניהול מרחוק אינה ההסבר.
לאחר מכן בדקו את החיבור עצמו מהלקוח ואשרו שהמתאם מחזיק בכתובת ובמסלולים הצפויים. הפעלת vpncmd מוצלחת מוכיחה יחסי שליטה ואינה אומרת דבר על האם התעבורה יוצאת דרך המנהרה.