OpenVPN או IKEv2: ארבע בדיקות לפני בחירת פרוטוקול

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

לקוח חסר מסיים את הדיון

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

ב-Windows פקודה אחת מפרטת את הפרופילים שכבר קיימים ומראה מאיזה סוג כל אחד. השם שהיא מדפיסה הוא השם שהבדיקות המאוחרות משתמשות בו.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

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

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

IKEv2 יכול להשתמש ב-MOBIKE כששני הקצוות תומכים ומפעילים אותו, מה שמאפשר ללקוח לשמור על המנהרה שלו בזמן שהכתובת שלו משתנה. RFC 4555 מגדיר את ההרחבה, והניסוח המותנה חשוב: שרת שמתעלם מהיכולת מנהל משא ומתן מחדש במקום. התוצאה יכולה להיראות זהה להעברת קובץ ושונה מאוד לשיחה חיה.

בדקו את המעבר שכלל חשוב לכם, עם משהו שרץ שאתם יכולים לראות. השאירו ping -t <internal-host> פועל ב-Windows, או ping רגיל במקום אחר, ואז עברו מ-Wi-Fi לסלולר וצפו בהפסקות. כשל MOBIKE מופיע כאימות מחדש מלא ביומן הלקוח ולא כעדכון כתובת שקט. מה שאתם מודדים הוא אם המנהרה שורדת את השינוי, לא אם הפרוטוקול מפרסם תמיכה.

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

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

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

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

openssl x509 -in client.crt -noout -subject -issuer -dates

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

בדקו מה המנהרה מנתבת בפועל

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

שתי פקודות מכסות את המסלול ואת חיפוש השם ב-Windows. המקבילות ב-Linux הן ip route show default ו-resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

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

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

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

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