מנהרה מלאה מול מנהרה מפוצלת: ארבעת ההבדלים
התווית קובעת מהיכן יוצא שאר התעבורה של מחשב נייד, לא כמה היא מהירה. השוו יציאה, עומס, DNS והתנהגות בכשל לפני שתבחרו.
תוויות מנהרה מתארות לאן הולך שאר התעבורה של מחשב נייד, לא כמה מהר היא הולכת. במנהרה מלאה, בקשות ציבוריות עוברות דרך שער ה-VPN לפני שהן יוצאות לאינטרנט. במנהרה מפוצלת, יעדים פרטיים משתמשים במנהרה וכל השאר עובר בנתיב המקומי. שניהם מגיעים ליישום הפנימי, כך שבדיקת הנגישות שאנשים עושים ראשונה לא אומרת דבר על המדיניות שנפרסה.
בדקו במקום זאת את היציאה: איזו כתובת מדווח דף הדהוד ציבורי, ואיזה פותר ענה.
מיתוס: מנהרה מפוצלת היא רק האפשרות המהירה יותר
מנהרה מפוצלת נמכרת לעתים קרובות כתכונת ביצועים, והיא יכולה להיות כזו, אבל זה תוצר לוואי ולא ההגדרה. ההגדרה היא החלטת ניתוב לגבי היעדים שנכנסים למנהרה. הבדל המהירות מופיע רק כשהנתיב הישיר טוב באמת מהעקיפה דרך המשרד. בקישור ביתי צפוף ובשער בעומס קל, המנהרה המלאה יכולה להיות המהירה מבין השתיים.
לכן המסגור הכנה עוסק בבעלות ובשליטה על הנתיב, כאשר ביצועים הם משהו שמודדים אחר כך. מדיניות שנבחרה בגלל מהירות ומזיזה בשקט את ה-DNS ואת היציאה הציבורית שלכם נבחרה מהסיבה הלא נכונה.
מה באמת משתנה: היציאה
במנהרה מלאה, אתר ציבורי רואה את כתובת היציאה של המשרד והסינון של המשרד רואה את הבקשה. במנהרה מפוצלת, אותו אתר רואה את כתובת הבית של המשתמש והמשרד לא רואה דבר. אלה מודלים שונים של נראות, ואף אחד מהם אינו בטוח יותר באופן אוטומטי. השאלה המועילה היא איזה מהם הארגון באמת יכול להפעיל.
בדקו זאת ישירות במקום לסמוך על תג מחובר. הדהוד כתובת ציבורי מראה את היציאה, ובדיקת פותר מראה של מי ה-DNS שענה.
| Question | Full tunnel | Split tunnel |
|---|---|---|
| Public exit address | Office egress | Local connection |
| Gateway load | All covered traffic | Private destinations only |
| Office visibility | Requests and destinations | Private resource access only |
מה השער צריך לשאת לאחר מכן
שער שנושא שיחות וידאו, הורדות ויישומים פרטיים צריך קיבולת לעומס עבודה שונה לחלוטין מזה שנושא רק בקשות פנימיות. חיבור האינטרנט של האתר נושא גם את הגעת המשתמש וגם את היציאה הציבורית שלאחריה, כך ששני קישורים יכולים להתמלא בעת ובעונה אחת.
יציאה מקומית מסירה את העומס הזה ואת העקיפה, והיא לא מבטיחה חוויה טובה יותר, כי גם הנתיב הישיר יכול להיות צפוף. השוו את היישום בפועל במקום להתייחס לתווית ניתוב כמדידת ביצועים.
קיימים חריגים תחת מנהרה מלאה
נתיב ברירת מחדל אינו מלאי של כל מנה. נתיבים ספציפיים יותר, הרשאות רשת מקומית, החרגות יישומים וכללי IPv6 נפרדים כולם מזיזים תעבורה, ולכן מדיניות שמתוארת כמנהרה מלאה עדיין יכולה לדלוף. תיעוד הניתוב של מערכת ההפעלה עושה את ההבחנה הזו עבור ברירות מחדל של מנהרה כפויה, ורשימת החריגים של הלקוח היא המקום שבו הדליפה בדרך כלל חיה. אמתו התנהגות, לא כוונה.
IPv6 ראוי למבט נפרד, כי מנהרה שנושאת רק IPv4 משאירה מחסנית שלמה מחוץ למדיניות.
DNS הוא מדיניות נפרדת
שמות פנימיים זקוקים לפותר שמכיר אותם, ופותר זה עשוי להיות נגיש רק דרך המנהרה. דפדפן עם DNS מוצפן משלו יכול לעקוף את פותר המערכת לחלוטין, מה שיוצר פיצול שבו שמות פנימיים נכשלים ושמות ציבוריים עובדים, או להפך.
החליטו לאן החיפושים צריכים ללכת, ואז התאימו את הלקוח ואת הדפדפן. גלישה ציבורית מוצלחת לעולם אינה בודקת פתרון שמות פנימי, ולכן זו הראיה הלא נכונה לצטט כאשר אתר אינטראנט נעלם.
כתבו את מדיניות הכשל, ואז בדקו אותה
החליטו מה קורה כשהמנהרה נופלת: לחסום הכול, לחסום רק משאבים פרטיים, או לאפשר חיבורים ישירים. חיבור מחדש אוטומטי לא עונה על השאלה הזו, ומתג הרג שמכסה רק את ממשק המנהרה יכול להשאיר יישומים מוחרגים מדברים בחופשיות. בדקו ניתוק אמיתי ושינוי רשת, ואז קראו את מצב הלקוח, כי התיעוד מתאר את ההתנהגות המכוונת ולא את זו המותקנת.
רשמו את הנתיבים הפרטיים, את היציאה הציבורית, את שרתי ה-DNS, את החריגים המקומיים ואת התנהגות הכשל בהערה קצרה אחת. ההערה הזו היא מה שהופך את המדיניות לניתנת לאימות על ידי מי שלא כתב אותה.