פרופיל חיבור SoftEther: בדקו שישה שדות לפני הייבוא

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

בדיקה 1: שם המארח והפורט

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

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

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

בדיקה 2: הפרוטוקול קובע את הלקוח

שרת שמציע כמה שיטות גישה לא הופך קובץ מיוצא אחד לפרופיל שכל לקוח יכול לפתוח. Each method has its own format, its own client and its own failure mode, וערבובן יוצר שגיאות שנשמעות כמו בעיות אישורים. החליטו איזו שיטה הקובץ מצהיר עליה לפני שאתם מחליטים איזה לקוח פותח אותו.

הטבלה שלהלן מפרטת את הפורטים המקובלים ואת מה שכל שיטה באמת דורשת. הפורטים הם בחירה של המפעיל, ולכן התייחסו אליהם כברירות מחדל ולא כעובדות על שרת מסוים. פרופיל SoftEther מקורי מיובא על ידי לקוח SoftEther, חבילת ovpn שייכת ל-OpenVPN, ופרופילי SSTP או L2TP מעובדים על ידי מערכת ההפעלה עצמה. התקנת לקוח שני כדי לפתוח קובץ שהראשון דוחה הופכת בדרך כלל שגיאה ברורה למבלבלת.

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

בדיקה 3: הרכזת, המשתמש ותפקיד המנהל

לגישה מקורית הפרופיל מציין Virtual Hub ומשתמש בתוכו. A hub is a logical VPN server instance with its own users and its own settings, והמשתמש הוא חבר ברכזת הזו עם אימות משלו. אף אחד מהם אינו ניהול השרת, ששולט במאזינים, ברכזות ובכל משתמש בפריסה. פרופיל לקוח לא אמור להגיע לעולם עם השליטה הזו מחוברת אליו. כשמישהו שולח לכם אישורי מנהל כדי שלקוח יעבוד, הסידור שגוי בין אם הוא מתחבר ובין אם לא.

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

בדיקה 4: הקובץ רגיש כמו מה שהוא נושא

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

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

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

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

בדיקה 5: בדקו את היישום, לא את נורית המצב

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

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

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