זמן הפעילות של שרת VPN: מה המספר הזה לא אומר לך

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

מה המספר מודד

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

systemctl show -p ActiveEnterTimestamp --value openvpn-server@server
uptime -s
systemctl is-active openvpn-server@server

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

תהליך יכול לפעול בזמן שהנתיב למטה

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

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

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

רעננות: הדוח ישן מהניסיון שלך

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

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

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

מה לבדוק במקום

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

nc -vz -w 5 vpn.example.net 1194
curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' https://vpn.example.net/
mtr -rwc 20 vpn.example.net

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

לקרוא רשימות צמתים ציבוריות בלי להיות מוטעה

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

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

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