מנהרה מפוצלת מול מדיניות החברה: איזה כלל מנצח
עיצוב ארגוני עשוי לדרוש יציאה מאושרת, DNS מנוהל או בדיקות נקודות קצה. עקיפה מקומית סותרת את העיצוב הזה גם כשהיא מאפשרת לאתר אחד להיטען.
סימון אפליקציה אחת בלקוח מנהרה מפוצלת מרגיש כמו העדפה מקומית, ובמכשיר מנוהל זה קרוב יותר לשינוי מדיניות. החריגה מסיטה תעבורה מהנתיב המאושר, שעשוי להיות אותו נתיב שנושא DNS מנוהל, סינון וכתובת המקור שהשירות מזהה. הלקוח אינו מתנהג רע כשהוא מחזיר את העריכה שלך; הפריסה עושה את עבודתה.
לפני שתתווכחו על תיבת הסימון, בררו איזו תכונה המדיניות קיימת כדי להגן עליה.
התכונה שמאחורי הכלל
חלק מהפריסות מנתבות הכול כך שכל התעבורה עוברת בשער מאושר. אחרות אכפתיות מפתרון שמות ומחזיקות את השאילתות במאתר הארגוני ולא במאתר של הרשת המקומית. אחרות זקוקות לכתובת מקור יציבה כדי שהשירותים הפנימיים יוכלו להחליט אם לענות בכלל.
קבוצה רביעית אוכפת את מצב נקודת הקצה: מצב הצפנת הדיסק, רמת התיקונים, בריאות הסוכן. פיצול המנהרה אינו משנה זאת, בעוד שעקיפה שמתחמקת מהתעבורה של הסוכן עצמו כן יכולה.
אלה ארבע דרישות שונות, וכל אחת נשברת בחריגה אחרת. קראו את הדרישה לפני הצעת השינוי, כי מי שכתב אותה יוכל לומר לכם מיד איזו חלה. שינוי שמספק את הדרישה הלא נכונה לא קונה דבר.
שתי טענות שווה להפריך מוקדם. מנהרה מלאה אינה נותנת למנהלים כל דף בטקסט פשוט, כי הצפנת אפליקציות ובקרות נקודות קצה קובעות מה נראה. גם מנהרה מפוצלת אינה בלתי בטוחה באופן גורף, כי DNS מנוהל, מדיניות לפי אפליקציה וסוכני נקודות קצה יכולים להחזיק מעמד ללא תלות בנתיב.
הריצו את הבדיקות לפי הסדר
הרצף שלהלן מצמצם חריגה לדבר הקטן ביותר שבאמת נכשל. עצרו בבדיקה הראשונה שאינה מתקיימת, כי תיקון מאוחר אינו מפצה על פער מוקדם.
שאלו איזו תעבורה מפספסת כעת את השער המאושר, ואז ודאו שפתרון השמות עדיין מגיע למאתר הארגוני. בדקו אם האפליקציה המדוברת מכבדת מתג חירום או אם ביזבזה את הניסיון הכושל בנתיב ישיר. לאחר מכן הביטו בשירותים משותפים: מציג מסמכים או מתווך עדכונים יכול לשאת את החריגה רחוק יותר ממה שתיבת הסימון מרמזת. לבסוף ציינו אם המדיניות מיושמת מחדש בהתחברות מחדש, כי ההתנהגות הזו קובעת אם שינוי מקומי ישרוד.
כל תשובה היא עובדה, ועובדות הן מה שבקשת חריגה צריכה. ויכוח אם ה-VPN מעצבן אינו אחד מהן. כתבו את התשובות לפני שהשיחה מתחילה.
בקשו חריגה צרה
דווחו על האפליקציה, היעד והפעולה שנכשלה, בסדר הזה. בקשה להשאיר מעדכן אחד בנתיב הישיר ניתנת לבדיקה; בקשה לעקוף את המנהרה עבור הדפדפן כולו אינה.
תארו מה כבר ניסיתם ומה הראו היומנים, ופנו לזה אל הצוות שבעל הפרופיל ולא אל מי שעונה בשירות העזרה. במכשיר מנוהל בעל הפרופיל יכול בדרך כלל ליצור חריגה נתמכת ששורדת עדכונים, בעוד שעריכת נתיב מקומית אינה יכולה.
אם התשובה היא לא, התייחסו לזה כהחלטת עיצוב ולא כמשוכה שיש לעקוף. הסקירה הבאה היא המקום לפתוח זאת מחדש, עם הפעולה הכושלת מתועדת והסיבה העסקית מצורפת. לעקוף אותה מסכן יותר ממה שהחריגה הייתה שווה אי פעם.
הפכו את החריגה לברת-קיימא
לאחר שינוי מאושר, אשרו את החלקים שעבדו קודם, ולא רק את החלק שהיה שבור. שמות פנימיים אמורים עדיין להיפתר דרך המאתר הארגוני, משאבים פרטיים אמורים להשיב, והמשימה שנכשלה קודם אמורה כעת להסתיים.
resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status
הפקודה הראשונה מוכיחה שהמאתר עדיין עונה עבור סיומת פנימית, והשנייה מוכיחה שבקשה מגיעה לשירות הפנימי מהנתיב הנוכחי. הריצו אותן שוב לאחר התחברות מחדש, כי דחיפת מדיניות יכולה לבטל בשקט שינוי שנראה יציב במהלך הבדיקה. שתי שורות פלט שנשמרות עם הפנייה סוגרות את המעגל. בלעדיהן החריגה נשענת על הזיכרון של מישהו מדף שנטען פעם אחת.
תעדו את החריגה, את מטרתה ואת הרכיבים שהיא מכסה באותו מקום שבו נשמרים הערות הפריסה. חריגה לא מתועדת הופכת לתקרית של הרבעון הבא, וחריגה מתועדת הופכת להוכחה שהעיצוב עומד בעומס עבודה אמיתי.