פורט VPN מועבר: מה יכולים לראות מבקרים והספק

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

שלושה אובייקטים, שלוש שאלות שונות

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

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

מה מבקר יכול לקשר בין נקודות קצה

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

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

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

מה הספק של ההעברה חייב לדעת

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

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

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

משך המיפוי משנה את החשיפה

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

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

פרסמו במכוון, ואז סגרו את שתי הדלתות

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

openssl s_client -connect pub.example.net:443 -brief < /dev/null
curl -sSI https://pub.example.net/

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

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