פרוקסי HTTP, מנהרת SSH או VPN: בחרו את השכבה הנכונה

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

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

פרוקסי מעביר רק את מה שהוא מבין

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

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

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN מעביר מנות. כל מה שהלקוח מנתב לתוך המנהרה עובר דרכה, כולל UDP ו-ICMP, ולכן היא מתאימה לדרישת רשת ולא לחיבור יחיד.

מישהו חייב לפתור את השם

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

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

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

כשהרשת מתירה יציאה אחת בלבד

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

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

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

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

כתובת מזויפת אינה אחת האפשרויות

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

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

החליטו לפי פרוטוקולים ושמות

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

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