sshuttle מול VPN מלא: מה השיטה שלו באמת מכסה
sshuttle נושא רק את מה ששיטת ההעברה שלו תומכת בו: בדקו קודם את הכיסוי של TCP, DNS ו-UDP, את ההרשאה המקומית הנדרשת ואת העוזר המרוחק.
בוחרים ב-sshuttle מפני ש-SSH כבר עובד וההצפנה נראית מוכרת, וטיעון זה מדלג על השאלה היחידה שקובעת אם הוא מתאים. אילו מנות יוצאות מהמכונה, איזה חשבון נושא אותן בצד השני, וכמה הרשאה מקומית דורש הכלי. שלוש התשובות הללו משתנות לפי שיטת ההעברה, ולכן הגדרה שעובדת ליישום אחד עלולה להיכשל בשקט ביישום הבא. הסקירה שלהלן מתחילה בפרוטוקול שהיישום באמת צריך.
התחילו בפרוטוקול שהיישום צריך
התמיכה בפרוטוקולים ב-sshuttle 2.0 תלויה בשיטה שתבחרו. שיטות NAT ו-nft בלינוקס מטפלות ב-TCP וב-DNS, ו-TPROXY מוסיף UDP כללי. לכל פלטפורמה ולכל שיטה גבולות משלה, ו-macOS מיירט באמצעות מנגנון שונה לגמרי. תעדו את הגרסה המותקנת, את השיטה שנבחרה ואת הפרוטוקולים שהיישום צריך לפני שתבחרו משהו.
לכן בקשת TCP שעובדת מוכיחה מעט מאוד על יישום UDP או על כל שאילתת DNS. sshuttle מתייחס גם ל-TCP כאל זרמים במקום לתמלל מנות IP שלמות, ולכן מסקנת תפוקה שהושאלה מ-VPN רגיל אינה עוברת לכאן. השוו את המנגנון שאתם מריצים בפועל לעומס שבאמת יש לכם.
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
מה הלקוח צריך מקומית
הסדר המתועד של הלקוח דורש root או sudo, מפני שהוא מתקין כללי יירוט מקומיים במקום ליצור ממשק תמלול. העובדה האחת הזו משנה את סיפור האבטחה: תהליך עם הרשאה כזו יכול להפנות מחדש תעבורה של המכונה כולה, לא רק של יישום אחד. התייחסו להרשאה כחלק מהתכנון ולא כפרט התקנה.
ודאו אילו כללים התקין הכלי ושהם נעלמים ביציאה. הפעלה שקרסה ומשאירה כללי יירוט עלולה לשלוח תעבורה לחור שחור הרבה אחרי שהמפעיל מאמין שהחיבור נעלם, והתסמין נראה כמו תקלת רשת ולא כמו כלל שנותר.
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip routeהפקודה הראשונה היא הצורה של קריאה טיפוסית, עם הקידומת שבאמת נדרשת לכם. השנייה מציגה מה התקין הכלי, והשלישית מאשרת שלא הופיע ממשק תמלול, וזו התוצאה הצפויה לתכנון הזה.
מה הצד המרוחק מריץ
הצד המרוחק הוא חשבון SSH מורשה בתוספת סביבת עוזר Python תואמת. התחברות שמצליחה תחת מעטפת מוגבלת אינה מעניקה אוטומטית רשות להריץ את העוזר הזה, וחשבון שיכול להריץ את העוזר אינו מגיע אוטומטית לכל שירות יעד. שתי העובדות שייכות לבקשת הגישה ולא להערות פתרון בעיות.
הגנו על אימות זהות המארח ועל האימות של החשבון. קבלת מפתח מארח לא מוכר כדי שהחיבור הראשון יעבוד מסירה את הבדיקה שהצד המרוחק הוא המכונה שהתכוונתם אליה, וזה חשוב כאן יותר מאשר בהעברה למטרה אחת.
הגבילו את החשבון המרוחק לשירותים שזרימת העבודה צריכה, ונהלו משא ומתן על ההיקף הזה עם מי שמפעיל את המארח. הם חלק מיחסי האמון, וכל הגדרה בצד הלקוח אינה משנה זאת.
היכן עובר גבול האמון
העברת חיבור API פרטי דרך SSH אינה מתירה כל פעולת API. TLS של היישום וההתחברות ליישום עדיין חלים, והכלי אינו יכול להפוך שירות ללא אימות לבטוח. גם קפיצה נוספת מהמארח המרוחק אינה אוטומטית אותו מקטע מוגן כמו ערוץ SSH, מפני שהחיבור השני הזה פועל לפי המדיניות שיש למארח המרוחק.
כתבו את הגבול כמשפט אחד: תעבורה לקידומות האלה יוצאת דרך החשבון הזה במארח ההוא. אם המשפט דורש פסקה של חריגים, התכנון עושה יותר ממה שהתיעוד שלו טוען וראוי למבט שני לפני שהוא מגיע לייצור.
הוכיחו זאת לפי פרוטוקול, ואז בחרו בכלי
בדקו כל פרוטוקול נדרש בבקשה לא מזיקה, כולל נתיב הפותר ומשפחות הכתובות שבהן היישום משתמש. כללו בבדיקה גם התנתקות, כדי שהתנהגות הכשל המותרת של היישום תהיה תוצאה ידועה ולא הפתעה בזמן תקרית. הפעלה שהעבירה כראוי כל עוד הייתה פעילה אינה אומרת דבר על מה שקורה כשהיא נופלת.
עבור קומץ שירותים שנקראים בשמם במפורש, העברה מקומית רגילה קלה יותר לבעלות וקלה יותר לביקורת. לתעבורת יישומים שמתאימה לשיטה שלו, sshuttle מציע דרך ביניים לגיטימית. כשהדרישה היא קישוריות IP רחבה, תכנון VPN הוא התשובה הכנה, והבחירה עוקבת אחרי כיסוי ואחריות תפעולית ולא אחרי דירוג של אלגוריתמי הצפנה.