TLS מקומי, העברת SSH או VPN לשירות ענן אחד
TLS מקומי, העברת SSH ושכבת-על מנותבת מגינים על ממשקים שונים. עברו על כל אחד כדי לבחור את הגבול הקטן ביותר שמכסה את השירות.
השאלה לעתים רחוקות היא אם להצפין משהו בין שתי מכונות ענן; היא איזה ממשק אתם מצפינים ומי בודק את הזהות של מי. אני מתחיל את השיחות האלה בשירות ולא בתרשים הרשת, כי השירות כבר יודע מה הוא צריך. שלושה גבולות מכסים את רוב המקרים: ה-TLS של היישום עצמו, פורט TCP אחד שמועבר דרך SSH ושכבת-על מנותבת שנותנת לכל משתתף כתובת. הם לא מדורגים לפי חוזק, אלא לפי כמה מהבעיה הם מכסים.
התחילו בשירות, לא ברשת
צאו מהתהליך החוצה. באיזה פרוטוקול הוא מדבר, איזה שם הלקוח יאמת, ומי בכלל רשאי לפתוח חיבור? שלוש התשובות האלה מחסלות אפשרויות מהר יותר מכל טבלת השוואה, והתצורה של השירות עצמו בדרך כלל עונה עליהן תוך דקות ספורות.
קחו API פנימי קטן שכבר מגיש HTTPS בפורט 8443 עם תעודה עבור api.internal.example. ss -ltnp במארח מראה למה הוא נקשר, ו-openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example מראה אם התעודה תקפה לשם שהלקוח ישתמש בו בפועל. אם שניהם בריאים, השירות יכול להגן על הזרם שלו ורק הנגישות נשארת. זו בעיה קטנה בהרבה מבניית רשת.
שלב 1: האם השירות מגן על עצמו?
זו האפשרות לבחור כשהיא מתאימה, והיא מתאימה לעתים קרובות יותר ממה שצוותים מניחים. ההצפנה של השירות מכסה את כל הדרך בין הלקוח לשרת, כולל כל קפיצה ביניהם, מה שאף מנהרה סביב האמצע לא משפרת. הגדירו את השם הצפוי ואת האמון במפורש במקום להסתמך על מה שמאגר ברירת המחדל של הלקוח מכיל במקרה.
הצפנה ונגישות נשארות בקרות נפרדות, ומיזוגן הוא המקום שבו האפשרות הזו נכשלת. שירות TLS על מאזין ציבורי ללא הגבלה עדיין מקבל ניסיונות חיבור מכל אחד, ולכן המאזין וכללי הרשת חייבים להיות מוגדרים בנפרד מעצם היות המטען מוגן. אחר כך בדקו את התלויות, כי API מעל TLS לא אומר דבר על נקודת הגילוי, פורט הניהול או ערוץ ההעברה ההמונית שלצדו. כל אחד מהם צריך תשובה משלו, ואח אחד לא מוגן מספיק כדי להפוך את כל הגבול לבדיה.
שלב 2: האם פורט TCP אחד הוא כל הדרישה?
כשהדרישה היא באמת פורט TCP אחד, העברה היא הדבר הקטן ביותר שעובד. העברה מקומית של SSH נושאת את הפורט הזה דרך חיבור מאומת שכבר קיים.
הצורה היא ssh -N -L 8443:127.0.0.1:8443 [email protected], והפרט החשוב הוא כתובת היעד: 127.0.0.1 נפתרת בצד המרוחק, ולכן החיבור לשירות נפתח מהבסטיון ולא מהמחשב הנייד שלכם. קשרו את המאזין המקומי בצורה צרה כ--L 127.0.0.1:8443:... כדי שלא תפרסמו את השירות ברשת המקומית שלכם בטעות. בצד השרת, הגבילו מה החשבון רשאי להעביר במקום לסמוך על התנהגות טובה של הלקוח. PermitOpen, AllowTcpForwarding local ו-GatewayPorts no כברירת מחדל הם שלושת ההגדרות שהופכות ממסר כללי לערוץ מסוים.
החוזה צר בשני הכיוונים. SSH מגן על הערוץ שלו, וקפיצה נוספת מהבסטיון ליישום אחר צריכה הגנה משלה. לשירות שמאזין רק ל-loopback של הבסטיון יש חשיפה שונה לגמרי מזו שמגיעים אליה דרך רשת אחרת, וההעברה לא משנה זאת. שמרו על האימות ובדיקות ה-TLS של היישום במקומם במקום להתייחס למנהרה כאל תחליף להם.
זה עובד היטב לחיבור אחד עם בעלים אחד. בקנה מידה זה הופך למערכת: התנגשויות פורטים מקומיות, פיקוח, סבב מפתחות והשאלה מי מפעיל מחדש את ההעברה לאחר אתחול.
שלב 3: האם ניתוב הוא הדרישה האמיתית?
הרשימה הזו היא המחיר הכנה של האפשרות הקטנה ביותר, ולכן צוותים מחליפים בסופו של דבר חופן פקודות רקע נשכחות במשהו מנוהל. התחליף אינו VPN אוטומטית. אם הדרישה היא עדיין פורט TCP אחד, העברה בפיקוח עם בעלים מתועד זולה יותר לתפעול משכבת-על והיא נכשלת בדרכים שאתם רואים. מדדו בעלות תפעולית לפני שתמדדו אלגנטיות.
ניתוב הופך לתשובה הנכונה כשניתוב הוא הדרישה. כמה יישומים שזקוקים לקישוריות IP רגילה, פרוטוקולים שהעברת TCP לא יכולה לשאת, או שירותים שעוברים בין מארחים — כולם מצביעים לאותו כיוון.
שכבת-על נותנת למשתתפים כתובת ומסלול, ואז מתחילה העבודה האמיתית: טווחים לא חופפים, בעלות על מסלולים, DNS, רישום, ביטול ומה קורה כשעמית נעלם. שום דבר מזה לא מגיע עם הכתובת. עמית שהתקבל לשכבת-העל גם אינו מורשה אוטומטית לכל פעולה ביעד, ולכן אימות ברמת השירות נשאר.
מה שבבעלותכם לאחר מכן
שני דברים שייכים לרשומה שאתם משאירים. הראשון הוא הזהות שהלקוח אמור לאמת, כי כל אחד מהגבולות האלה נשחק בשקט ברגע שבדיקת שם מוקלת כדי לגרום למשהו לעבוד. השני הוא שלב ההסרה: איזה מפתח, איזה כלל או איזה מסלול נעלם כשהגישה מסתיימת, ומי מבצע זאת.
הסיור מסתיים במקום שבו התחיל, בשירות. בחרו את הגבול שמכסה את התעבורה בפועל ומאמת את העמיתים שהתכוונתם לאמת, ואז כתבו כיצד הגישה מתעדכנת, מנוטרת ומוסרת. ה-אסמכתא של OpenSSH הוא המקום לאשר את אפשרויות ההעברה לפני שמבטיחים חוזה צר. אם אינכם יכולים לתאר את שלב ההסרה במשפט אחד, הגבול גדול מהבעיה.