האם התוספת הזו של NetworkManager יכולה להריץ שני VPN בו-זמנית?
שני פרופילים שמורים לא מוכיחים דבר. בדקו את מטא-נתוני השירות של התוספת לחיבורים מרובים, ואז תַּאמו מסלולים ו-DNS בין השניים.
ברשימת החיבורים יושבות שתי רשומות VPN, שתיהן מצהירות מחובר, ורק אחת מהן נושאת את התעבורה שציפיתם לה. או שהשנייה מסרבת לעלות כלל, ואיש אינו יכול לומר אם האשם הוא התוספת, הלקוח או מדיניות ששכחתם. טענות על מגבלה של VPN אחד מתארות מימושים מסוימים, והמימושים שונים. עברו קודם על היכולת, ואחר כך על התיאום.
ספרו פרופילים שמורים, ואחר כך הפעלות
פרופיל שמור הוא אובייקט תצורה, וחיבור פעיל הוא מופע שרץ. הרשימה ממזגת את שני המושגים חזותית, ולכן שני הדוחות נשמעים נכונים. התחילו בשמות המדויקים של האובייקטים עם ה-UUID שלהם, כי השם המוצג אינו ייחודי וייבוא ישן חולק לעתים קרובות תווית עם רשומה חדשה יותר. אחר כך בדקו את רשימת הפעילים בנפרד וראו אילו UUID מופיעים. רק אז תדעו אם אתם משווים שתי תצורות או שתי מנהרות חיות.
הפעלה כפולה של אותו UUID היא מקרה שלישי, והיא אינה מקביליות. זו הפעלה מחדש של מופע אחד.
קראו את המטא-נתונים של התוספת עצמה
כל תוספת VPN מספקת קובץ מטא-נתונים קטן שהמנהל קורא, וקבצים אלה יכולים להצהיר אם התוספת תומכת במספר חיבורים בו-זמנית. קראו את הקובץ המותקן במכונה הזו במקום לחזור על מה שפרויקט במעלה הזרם כותב כעת, כי חבילת ההפצה קובעת מה באמת יש לכם. אותה בדיקה חלה לכל פרוטוקול: תשובה עבור תוספת אחת אינה אומרת דבר על אחרת. רשמו את גרסת החבילה לצד התוצאה, כדי שהשוואה מאוחרת תאמר משהו.
עצות ישנות על מגבלה של VPN אחד תיארו אינטגרציות ישנות יותר. זה לא נכון לתמיד וגם לא בטוח להניח אותו כקבוע, והקובץ שלפניכם מכריע זאת מקומית.
מקבילי אינו מתואם
עלייה מוצלחת של שתי תוספות מוכיחה את היכולת, לא את התכנון. שתי מנהרות שמציעות מסלול ברירת מחדל תתחרינה, וזו שהתקינה את המסלול שלה אחרונה מנצחת בדרך כלל בלי להכריז על כך. טווחים פרטיים חופפים סובלים מאותה בעיה בצורה קטנה יותר.
החליטו אילו יעדים שייכים לאיזה פרופיל לפני שתפעילו משהו. שינוי שם של פרופיל אינו מבדיל בין היעדים.
DNS בוחר מנצח, בין אם תעשו זאת ובין אם לא
הגדרות הפותר הן לפי פרופיל, וכששניים פעילים סדר הפענוח נקבע לפי מדיניות וקדימות ולא לפי כוונה. הפרופיל שעלה אחרון יכול להחזיק בשקט בכל שם ארגוני.
הקצו כל מרחב שמות פרטי לפותר שאמור לענות עבורו, וקבעו את העדפת הניתוב במכוון במקום להסתמך על הסדר. אחר כך בדקו שם מכל מרחב כששתי המנהרות למעלה, ושוב כשאחת מהן מנותקת. פותר שעובד רק כל עוד שתי המנהרות למעלה הוא תכנון שיפתיע מישהו ברגע הגרוע ביותר.
פרסו בסדר קבוע ובדקו בין השלבים
הפעילו פרופיל אחד, בדקו את מצב המסלולים והפותר שלו, ואז הפעילו את השני ובדקו שוב. השוואת שני המצבים מספרת לכם מה השתנה ואיזה פרופיל מחזיק במה. אל תפעילו את שניהם ואז תאבחנו את התוצאה.
בדקו כל משאב נדרש דרך המנהרה שאמורה לשאת אותו, ואז נתקו פרופיל אחד וודאו שהאחר שומר על המסלולים, על ה-DNS ועל התנהגות הכשל המיועדת שלו. אם התוספת הפרוסה באמת אינה יכולה לעשות את הנדרש, בחרו בשדרוג נתמך או בחלופה מבודדת במפורש במקום להחיות פרוטוקול מיושן לצד המנהל. מנהרה שנייה ונפרדת שאיש אינו מנהל אינה בידוד; היא עוד מקור למסלולים מפתיעים.