איך להפריד בין תמיכת פרוטוקול VPN לבין האמון במפעיל
פרוטוקול מאשר את מכניקת המנהרה, לא את החברה שמאחוריה. שפטו שימור, נתוני חשבון וביקורות לפי מה שהמפעיל מפרסם.
שני לשוניות של ספקים פתוחות, שתיהן מפרסמות WireGuard, וההשוואה נתקעה על משפט אחד: המנהרה חזקה, אז השירות בטח בסדר. זו הסקה שגויה. הפרוטוקול מגדיר כיצד שני עמיתים מצפינים ומאמתים, אבל הוא לא אומר דבר על מי מפעיל את נקודת הקצה, מה מערכת החשבונות שומרת, או כיצד החברה עונה לבקשה משפטית. עליכם להפריד את השאלות האלה לפני שתג יענה עליהן במקומכם.
מה תווית פרוטוקול יכולה לאשר ומה לא
WireGuard מגדיר לחיצת יד הבנויה על Noise, קבוצה קבועה של פרימיטיבים מודרניים, ומודל ניתוב שבו AllowedIPs קובע מה נכנס למנהרה. אלו הבטחות אמיתיות לגבי פורמטי הודעות והחלפת מפתחות, וראוי שיהיו לכם. הן גם הבטחות לגבי קוד, לא לגבי המכונה שעליה הקוד הזה רץ.
המימוש עדיין משאיר בחירות. ספק יכול לטעון את מודול הגרעין או לספק בנייה במרחב המשתמש, לדחוף DNS דרך המנהרה או להשאיר אותו אצל הפותר המקומי, ולסובב מפתחות לפי לוח הזמנים שלו. אף אחת מהבחירות האלה לא מופיעה בתווית הפרוטוקול, וכל אחת מהן משנה מה השירות יכול להבחין בו.
OpenVPN הופך את הפער לקל יותר לראייה. לחיצת היד TLS ומודל התעודות שלו יכולים להיות מוגדרים היטב או גרוע, עם או בלי tls-auth, עם צפנים מודרניים או עם חלופת תאימות. שני שירותים יכולים שניהם לומר OpenVPN ולסיים בחשיפה שונה מאוד. דף הפרוטוקול של WireGuard מדויק לגבי ההצפנה ושותק לגבי המפעיל, וזה בדיוק הגבול שכדאי לזכור.
מה שרק המפעיל יכול לענות
התחילו בבעלות. האם נקודת הקצה נמצאת על חומרה שהספק שולט בה, על VPS שכור, או על מכונה התנדבותית בדירה של מישהו? התשובה קובעת מי יכול להעתיק דיסק, מי מתקן את הגרעין, ומי מבחין בכניסה מוזרה. השוואת פרוטוקולים לא מגיעה לשום דבר מזה.
לאחר מכן מגיעים רשומות החשבון והתשלום. כתובת דוא״ל, חותמת זמן לחידוש, טביעת אצבע של כרטיס ופנייה לתמיכה כולם חיים מחוץ למנהרה. כך גם הפותר: אם הספק מפעיל DNS משלו, הוא רואה שמות גם כשהדפים ב-HTTPS. בקשו שימור בימים, לא את המילה מינימלי.
מוינו את התשובות לשתי עמודות, מפני שהן נושאות משקל שונה. עמודה אחת מתארת את התוכנה; השנייה היא הבטחה שהשירות חייב לקיים.
| Question | Protocol tells you | Operator must document |
|---|---|---|
| Who holds the server private key? | How the key exchange works | Key generation, storage and rotation |
| Which addresses connected when? | Nothing | Whether handshake or session metadata is retained |
| What happens to a legal request? | Nothing | Disclosure policy, jurisdiction and response history |
| Who can read diagnostics? | Nothing | Support access rules and retention limits |
אפשר לבדוק הבטחות רק מול מסמכים. ספק שאינו יכול לנקוב בתקופת השימור שלו אינו חושף פגם בפרוטוקול; הוא מראה לכם את איכות הרשומות שלו, וזה בדיוק הדבר שניסיתם לשפוט.
בדקו את הפרופיל שהלקוח באמת מיישם
הלקוח הוא המקום שבו פרופיל מופשט הופך למסלולים. בלינוקס עם wg-quick, התצורה המופשטת מראה בדיוק מה ייושם, כולל שורות ה-DNS וה-AllowedIPs שממשק גרפי עשוי להסתיר מאחורי מתג.
sudo wg-quick strip wg0
sudo wg show wg0 latest-handshakes
resolvectl status wg0קראו את הפלט כשלוש עובדות נפרדות. AllowedIPs של 0.0.0.0/0 אומר שהמסלול המוגדר כברירת מחדל נכנס כולו למנהרה; שורת DNS אומרת שהשמות הולכים לפותר שהפרופיל מכנה; לחיצת יד עדכנית אומרת שההפעלה חיה. keepalive מתמשך אומר לכם שהלקוח מחזיק מיפוי NAT פתוח, וזו בחירת התנהגות, לא דירוג אבטחה.
הסתייגות אחת חשובה כאן. הפקודות האלה מאמתות את המנהרה שיש לכם, לא את המדיניות שמאחוריה. לחיצת יד מושלמת מוכיחה שההצפנה עובדת; היא אינה מוכיחה שרשומות החיבורים של החודש שעבר נמחקו, מפני שהאירוע ההוא לא משאיר עקבות במכונה שלכם.
ראיות ששורדות דף שיווקי
בקשו דו״ח ביקורת עצמאי וקראו את היקפו לפני הלוגו. הדו״חות מכנים את התשתית, התקופה והחריגים; רבים מכסים שרתי VPN אך משאירים את פורטל החשבון, החיוב וכלי התמיכה מחוץ לסקירה. ביקורת שמחריגה את המערכות שמחזיקות את כתובת הדוא״ל שלכם עונה על שאלה צרה יותר ממה שדף המכירות מרמז.
לאחר מכן קראו את מדיניות הפרטיות לפי קטגוריות ולא לפי שמות תואר. מדיניות שימושית מכנה מה נאסף, מדוע ולכמה זמן, והיא מבדילה בין מטא-נתוני חיבור לנתוני חשבון. דו״ח שקיפות, אם קיים, מראה אם לספק יש בכלל תהליך לבקשות, אם כי מספריו טובים רק כמו הגוף שמפרסם אותם.
קוד פתוח עוזר בשכבת הלקוח ונעצר שם. לקוח קריא מוכיח מה ההתקן שלכם שולח; הוא אינו מוכיח מה השרת שומר. בנייה משוחזרת מצמצמת את הפער בין קוד מפורסם לקוד שנשלח, אך היא עדיין מתארת תוכנה, לא תפעול.
מבחן קצר של שלושה מסמכים מסנן את רוב הטענות: מדיניות עם קטגוריות נקובות ושימור, ביקורת עדכנית עם היקף מוצהר, ותשובה בכתב מהתמיכה על תרחיש אחד קונקרטי. אם אחד מהשלושה חסר, התייחסו לטענה המסוימת הזו כלא מאומתת, לא כשקרית.
איפה עובר הגבול בפועל
עם נקודת קצה התנדבותית, שפטו את המארח הבודד. המוניטין של פרויקט התוכנה לא עובר לכל מכונה שמריצה אותו, ולאדם שמפעיל את המכונה ההיא אולי אין שום קשר לפרויקט. רשתות מסחריות מארגנות אחריות אחרת, אבל הן עדיין מרכזות אותה בישות אחת.
אחסון עצמי הופך את השאלה. אתם הופכים למפעיל, כך שתמיכת הפרוטוקול סגורה והאמון הופך לתיקון שלכם, לניהול המפתחות ולשימור הלוגים שלכם. זו תשובה לגיטימית לחלק מהקוראים, לא עקיפה.
בשירות בתשלום, החוזה והתחום השיפוטי הם חלק מהמוצר. שינויי בעלות, רכישות וכללי גילוי מקומיים יכולים לשנות את חובות המפעיל בלי לגעת בפרוטוקול, ולכן השוואה שנעצרת בגיליון המפרט מתיישנת.
רשמו את שלוש העובדות שלא הצלחתם לאמת מהאתר. שלחו אותן לתמיכה ושמרו את התשובה. תשובה ספציפית מעבירה את השירות לקטגוריה אחרת, ושתיקה היא גם תשובה ששייכת להשוואה שלכם.