איזה תעבורת אפליקציה מעבירה למעשה העברת SSH?

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

תנו שם לממשק לפני שאתם משווים משהו

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

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

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

העברות מקומיות, מרוחקות ודינמיות נבדלות במי מאזין

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

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

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

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

מצב התקן מנהרה הוא החריגה הרשתית האמיתית היחידה

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

sudo ssh -w 0:0 [email protected]
ip addr show tun0

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

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

בדקו שהאפליקציה שלכם משתמשת בממשק שבניתם

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

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

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

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