SSTP מול OpenVPN: אותו פורט 443, פרוטוקול אחר

שתי האפשרויות יכולות לשבת מאחורי TCP 443, ולכן אנשים מניחים שהן נקודות קצה ניתנות להחלפה. הן לא: SSTP שרת מדבר PPP בתוך HTTPS, בעוד ששרת OpenVPN מדבר בפרוטוקול שלו מעל TLS או דרך זרם UDP גולמי. הפניית לקוח אחד לפורט של השני יוצרת חיבור שלעולם לא מגיע להנחיית התחברות. הבחירה עוסקת ב איזה לקוח ואיזו תעבורה אתה יכול לתמוך בהם, לא במספר.

פורט משותף אינו יוצר פרוטוקול משותף

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

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

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

SSTP מנהר PPP בתוך HTTPS

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

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

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

OpenVPN מביא לקוח משלו ובחירת תעבורה

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

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

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

בחר לפי לקוח, תעבורה ותמיכה

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

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

לאחר מכן אשר איזה מהם באמת הקמת לפני שאתה מאתר תקלות בכל דבר אחר:

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

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

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