האם עטיפת TLS נותנת לך רשת פרטית? בדרך כלל לא

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

מה עטיפת שירות באמת מחברת

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

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

application -> local listener -> TLS connection -> remote listener -> configured backend

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

מצא היכן נגמר ערוץ ה-TLS

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

בדוק את המאזין ואת ה-backend בנפרד, כי לחיצת יד שמצליחה בדלת הקדמית לא אומרת דבר על השירות שמאחוריה.

ss -ltnp | grep -F 443
openssl s_client -connect svc.example.net:443 -servername svc.example.net </dev/null | openssl x509 -noout -subject -dates

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

מה VPN מנותב מוסיף ועטיפה לא

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

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

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

השווה את הגבול שנכשל

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

אין לתקן בקשה נדחית של ה-backend על ידי השבתת אימות הזהות בחזית. זה מחליף כשל הרשאה שניתן לאבחן בכשל אמון שלא ניתן לאבחן.

curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30

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

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