כיצד לבחור לקוח VPN ל-Mac עבור השער שכבר יש לכם

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

התחילו מהשער, לא מחנות היישומונים

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

לפני התקנה או החלפה של משהו, השיגו ארבע תשובות ממי שמפעיל את השירות:

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

• משפחת שער וגרסה נתמכת: המוצר, השירות המופעל וגרסת לקוח שעדיין תומכת בגרסת ה-macOS ובחומרת ה-Mac שלכם.

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

• בעלות: מקור ההורדה או הניהול המהימן, הפרופיל המיועד ומי תומך בו כשהוא נשבר.

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

SSL VPN הוא תווית של משפחה, לא פרוטוקול

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

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

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

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

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

שתי שורות ראויות לאזהרה. הלקוח המובנה ב-macOS הוא מימוש IKEv2 אמיתי, לא לקוח SSL VPN כללי: שירות שנבנה עבורו זקוק לפרופיל הנכון, לזהות שרת מצופה ולפרטי כניסה, ובמכונה מנוהלת הפרופיל הזה עשוי להיות נעול. OpenConnect מכסה כמה פרוטוקולי ספקים מקובץ הפעלה אחד, אבל הפרויקט שלו אינו טוען לתמיכת ספק; סריקת מארח, כללי מנהרה מפוצלת שנדחפים מהשער או זרימת SSO מסוימת עשויים להתקיים רק בלקוח הספק.

ל-WireGuard יש אותה צורה. השירות מספק עמיתים, הלקוח מספק את המנהרה, ופרופיל OpenVPN אינו תחליף. קמט אחד ב-macOS: לקוח ה-App Store מחזיק את המנהרות שלו בתוך הרחבת רשת, ולכן wg show מכלי Homebrew יכול לא להראות דבר בזמן שהממשק פעיל. אמתו באמצעות מסלולים ותעבורה במקום.

הגדירו, ואז אמתו בסדר קבוע

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

scutil --nc list
networksetup -listallnetworkservices
netstat -rn | grep -E "^default|utun"
scutil --dns

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

לשירות OpenVPN, Tunnelblick הוא לקוח סביר ללא עלות, והמדריך שלו עצמו גלוי לגבי החצי החסר: הוא אינו מספק שירות VPN. לחצו פעמיים על ה-.ovpn שקיבלתם, תנו ל-Tunnelblick להתקין אותו, ובדקו את הגרסה מול גרסת ה-macOS שלכם לפני שתסתמכו עליה.

לשער של ספק אני מרבה לבדוק עם OpenConnect משורת הפקודה:

brew install openconnect
sudo openconnect --protocol=anyconnect --user=you vpn.example.com

הכלי מדפיס את התעודה שקיבל וממתין לפני שהוא סומך על שרשרת לא מוכרת; ההנחיה הזו היא תכונה, ונעיצה עם --servercert pin-sha256:... עדיפה על קבלת אזהרה שלא קראתם. Ctrl-C מפרק את המנהרה, כי ל-openconnect בחזית אין מתג הרג ואין היגיון התחברות מחדש. זה בסדר לסשן אבחון וברירת מחדל גרועה לעבודה יומיומית.

כשאין שער להתאים לו

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

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

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

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

רשימת בדיקה קצרה לפני ההפעלה האמיתית הראשונה

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

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