הגעה לתחנת עבודה מאחורי NAT בלי העברת פורט
תחנת עבודה בלי פורט נכנס נגישה עדיין דרך מרכז, ממסר או מתווך יישומים. השוו מה כל תכנון מבטיח לפני שתבחרו אחד.
שני קצוות מאחורי NAT של הספק ונתב משרד נעול לא מותירים שום פורט נכנס להעברה, והרפלקס הוא לבקש אחד בכל זאת. השאלה הטובה יותר היא איזה צד יכול לחייג החוצה ואיזה שירות נגיש רשאי לשאת את התעבורה. ארבעה תכנונים עונים על השאלה הזאת בדרכים שונות, והם נכשלים בדרכים שונות כשמסלול נחסם. הבחירה ביניהם היא השוואה של הבטחות, לא של שמות פרוטוקולים.
ארבעה תכנונים, ארבע הבטחות שונות
הטבלה שלמטה היא הגרסה הקצרה. קראו את העמודה האמצעית כהבטחה שאפשר לבדוק, ואת העמודה הימנית כהבטחה שאיש לא נתן.
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
איזו שורה חלה תלוי במשימה ולא בהעדפה. הפעלת שולחן עבודה מרחוק אחת, מעטפת ניהולית אחת וגישה לתת-רשת פרטית שלמה הם שלושה דרישות שלא זקוקות לאותה נקודת כניסה, גם כשהן נוגעות במקרה באותה מכונה.
מרכז משנה מי מחייג החוצה, לא מה מותר
בתכנון של מרכז מנותב, המחשב הנייד המרוחק ותחנת העבודה, או שער האתר שלפניה, פותחים כל אחד מנהרה יוצאת אל שירות ששניהם יכולים להגיע אליו. שום דבר לא מקבל חיבור לא מבוקש בנתב של תחנת העבודה, וזו בדיוק הסיבה שהתכנון הזה שורד NAT ועובד גם כשבאתר אין כתובת סטטית. לאחר מכן המרכז מנתב תעבורה בין שתי הכתובות הפנימיות לפי המדיניות שלו.
המחיר הוא שהמרכז חייב להתקיים, להיות נגיש משני הצדדים ומישהו חייב להפעיל אותו. סינון יוצא חייב לאפשר את התעבורה, ורשת שחוסמת אותה תסכל את התכנון גם אם לא נדרשה העברת פורט.
החלק העדין הוא שנגישות והרשאה הן החלטות נפרדות שמתקבלות במקומות שונים. מסלול אל קידומת לא אומר דבר על איזה שירות בתחנת העבודה הזהות רשאית להשתמש בו, וכלל חומת אש שמתיר את המנהרה לא אומר דבר על האם החשבון יכול להתחבר. הגדירו את שניהם, בדקו את שניהם, והשאירו את החלטת ההרשאה אצל המערכת שמחזיקה במשאב ולא אצל טבלת הניתוב.
המעבר עובד רק כששתי המחסניות מיישמות אותו
מעבר בין עמיתים הוא יכולת של מערכת מסוימת, לא הגדרה שמשפרת VPN. Interactive Connectivity Establishment אוסף כמה כתובות מועמדות ובודק זוגות עד שאחד עובד: מועמדי מארח בממשקים מקומיים, מועמדים רפלקטיביים של שרת שנבנים ממה ש-NAT חושף, ומועמדים ממוסרים שמוקצים על ממסר. כתובת פרטית לבדה אינה מסלול, כי הצד השני לא יכול לנתב אליה.
שווה להבין את המקרה הממוסר לפני שדוחים אותו. RFC 8656 מתאר את TURN כפרוטוקול שבו לקוח מבקש משרת כתובת תעבורה ממוסרת והשרת מעביר תעבורה בין אותו לקוח לעמיתיו. לכן הממסר נושא את הנתונים, וזה שונה מהותית מספרייה שרק עוזרת לקצוות להיפגש. החלפת כתובת הממסר עם העמית היא שלב תיאום שהיישום חייב לבצע.
מה שאי אפשר להבטיח הוא מסלול ישיר. NAT סימטרי וכמה חומות אש ארגוניות מסכלים קידוח חורים, וכשהם עושים זאת המערכת או נופלת חזרה לממסר או נכשלת. גם אי אפשר להסיק ששני קצוות מתורגמים לא יוכלו לדבר לעולם; מחסנית נתמכת עם גיבוי ממסר קיימת בדיוק מפני שלעיתים קרובות הם יכולים. החליטו אם זמינות או ישירות חשובה יותר, ואז בדקו איזה מסלול בחר הפריסה בפועל במקום להניח את המקרה הטוב.
מתווך צר יותר מרשת
כשהדרישה היא יישום אחד, מתווך יישומים או חיבור הפוך שתחנת העבודה מפעילה יכולים להיות התשובה הקטנה ביותר. תחנת העבודה מחייגת החוצה אל מתווך, המתווך מאמת את המשתמש המרוחק, ורק הפעלת היישום הזאת נישאת. לא נוצר מסלול אל תת-הרשת של תחנת העבודה, ולכן פגיעה בהפעלה המרוחקת אינה יורשת מסלול לכל התקן שלידה.
לצרות הזאת יש מחיר: כל יישום נוסף זקוק לאינטגרציה משלו, וכל מה שהיישום מניח על רשת מקומית, כמו שיתוף קבצים שהוא פותח בשרת סמוך, עלול שלא להיות נגיש. מתווכים גם מרכזים מדיניות ורישום במקום אחד, וזה שימושי עד שאותו מקום הופך לתקלה.
השוו גבולות אמון, ואז בדקו את המסלול
מרכז שמסיים מנהרות יכול לקרוא את התעבורה שהוא מנתב. ממסר יכול לשאת חילוף מוגן באופן עצמאי כשההיישום מצפין מקצה לקצה, ומתווך בדרך כלל מסיים את ההפעלה שהוא מציג. קבעו היכן ההגנה באמת נגמרת לפני שאתם מחליטים ששני תכנונים שקולים כי שניהם מוצפנים.
ואז בדקו למה תחנת העבודה באמת מגיעה כלפי חוץ, כי כל תכנון למעלה תלוי בזה. הריצו זאת בתחנת העבודה, כשאתם מחליפים את שם המארח שבו אתם מתכוונים להשתמש.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comאשרו את התכנון רק לאחר שהפעולה המרוחקת המיועדת מצליחה תחת הזהות המותרת, זהות לא מאושרת נדחית, וההתנהגות כשהמסלול הישיר או הממוסר אינו זמין ידועה ומתועדת. כללו התחברות מחדש והקשר האתחול הרגיל של תחנת העבודה, כי הפעלה שהחלה במשרד דרך ה-LAN לא בודקת דבר שהגישה המרוחקת תלויה בו.