שירות Onion מול שירות VPN: מודלי גישה שונים
כתובת Onion קשורה למפתח השירות ומגיעים אליה בתוך Tor; VPN מעניק מסלול אל שער. השוו את הקהל, הגילוי ואימות האפליקציה.
אנשים מתארים שירות Onion ושירות שנגיש רק דרך VPN כשני טעמים של אותו רעיון: הסתירו את השער ושתפו את הכתובת הסודית. הם נבדלים בכך שהכתובת קשורה אליו, מי יכול להגיע אליה ומה חייב לקרות לפני שבקשה מגיעה. האחד הוא נקודת מפגש בתוך Tor, והשני הוא מסלול בתוך רשת פרטית. התייחסות לשניהם כאל דברים הניתנים להחלפה מייצרת עיצובים שאינם פרטיים וגם אינם ניתנים לתחזוקה.
המיתוס: שני העיצובים הם רק דלת נסתרת
התכונה המשותפת אמיתית אך דקה: אף אחד מהעיצובים לא מציב את ממשק הניהול על שער ציבורי שנגיש ישירות. כל השאר מתפצל. כתובת Onion נגזרת מהמפתח של השירות עצמו, ולכן השם קשור לזהות; כתובת VPN היא רק כתובת בתוך רשת שאליה התקבלתם. האחד מסתיר את השירות בתוך שכבת כיסוי, והשני מקבל אתכם לטופולוגיה פרטית. התייחסות לשני כאל מילה נרדפת לראשון היא תחילת הבלבול.
אף אחת מהתכונות אינה בקרת אבטחה עבור האפליקציה עצמה. מיקום נסתר אינו מתקן את התוכנה שמאחוריו, ומסלול פרטי אינו מוסיף אימות לדף הכניסה. שני העיצובים עדיין זקוקים להרשאות של האפליקציה עצמה, ושניהם עדיין זקוקים למישהו שאחראי על עדכונים ושחזור.
למה מצביעה כתובת Onion באמת
כתובת Onion מגרסה v3 מקודדת את המפתח הציבורי של השירות, ולכן איש אינו יכול לבחור כתובת לשירות שאינו שולט בו. הלקוח מתחבר דרך Tor לנקודת מפגש, והשירות מגיע לאותה נקודה מצדו; שום צומת יציאה רגיל אינו נושא את החיבור הזה אל השירות. השם הוא זהות, לא רשומת DNS.
dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor
לכן הוספת מסלול או רשומה ב-hosts לשם onion אינה מועילה דבר. החיפוש אינו המנגנון; לקוח Tor והמעגלים שלו הם המנגנון. אם השירות מיועד לקבוצה קטנה של אנשים, הרשאת לקוח onion יכולה לדרוש מפתח לפני שהחיבור יתקבל, אבל זו עדיין אינה כניסה לאפליקציה. פרסום הכתובת הוא גם פעולה מכוונת, שכן כל מי שלומד אותה יכול לנסות להתחבר אלא אם הגבלתם אותה.
עצרו אם הסיבה היחידה לעיצוב onion היא להימנע מהגדרת אימות. שכבת הכיסוי אינה מספקת זאת, ואתם תבנו אותה בכל מקרה מאוחר יותר.
מה מסלול VPN מעניק באמת
VPN מכניס התקן לרשת ונותן לו מסלול אל שער או תת-רשת. השירות שמאחורי אותו שער רואה כתובת מתוך מאגר המנהרה ומחיל את ההרשאה שיש לו. המסלול אינו אומר דבר על זהות המשתמש; הוא אומר לאן מנות רשאיות ללכת.
ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null
המודל הזה מתאים לקבוצה מוכרת עם התקנים מנוהלים, משום שהשער יכול לכפות את מצב ההתקן ואת הרשת ניתן לבקר. הוא מתאים היטב לאורחים אנונימיים או מזדמנים, שיהיה צורך לרשום אותם קודם. הכניסה של האפליקציה עצמה עדיין קובעת מה משתמש מחובר רשאי לקרוא. ערבוב בין נגישות לבין הרשאה הוא הדרך שבה VPN בסופו של דבר מעניק תת-רשת שלמה לכל מי שיכול להתחבר.
עצרו אם הקהל אינו ידוע או משתנה כל הזמן. רישום זרים ברשת פרטית כדי להראות להם עמוד אחד הוא התחייבות גדולה לעומת פרסום שירות.
הבחירה בין השניים, ומה נשאר זהה
בחרו במודל onion כאשר הקהל טכני, השירות אינו אמור להיות בעל כתובת ציבורית כלל, ואתם יכולים לקבל את דרישות הלקוח של Tor. בחרו במודל VPN כאשר הקהל הוא קבוצה מוגדרת שאתם מנהלים את התקניה ואת הגישה שלה תרצו לתעד בשכבת הרשת. אף בחירה אינה מסירה את הצורך באימות האפליקציה, בתיקונים או במסלול שחזור. אף אחת מהן אינה פרטית יותר אוטומטית במובן החשוב למשתמשים שלכם.
בשני העיצובים, כתבו מי יכול להגיע לשירות, כיצד הם מזוהים ומה קורה כאשר אישור אובד. התשובה לשירות onion כוללת את מפתחות הרשאת הלקוח ואת הכתובת עצמה; התשובה ל-VPN כוללת את החשבון, את ההתקן ואת מדיניות השער. אלו מלאי שונים, ורק אחד מהם יהיה ברור למנהל הבא.
ההשוואה נגמרת במקום שבו האפליקציה מתחילה. כתובת נסתרת ומסלול פרטי הם בחירות של שכבת התעבורה, והאפליקציה עדיין חייבת להחליט מה בקשה רשאית לעשות. שמרו את ההחלטות האלה במסמכים נפרדים, ואף אחד מהעיצובים לא יבלע בשקט את העבודה של האחר.