VPN התנדבותיים ו-VPN מסחריים מציבים את האמון במקומות שונים

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

שלושה צדדים, לא אחד

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

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

איך נקודת קצה נעלמת

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

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

מה המדיניות באמת מכסה

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

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

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

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

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

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