ניתוב VPN מבוסס דומיין לעומת נתיבי IP: מה מתאים?
שם מארח בתיבת מנהרה מפוצלת אינו נתיב. השוו כללי דומיין לתחיליות מפורשות מבחינת רענון, היקף תת־דומיינים ומה קורה כשמשתנה ה־DNS.
נתיב IP תואם לתחילית כתובת, והליבה מחילה אותו בלי לשאול שאלות נוספות. כלל VPN מבוסס דומיין תואם לשם, כלומר משהו במחסנית חייב להחליט אילו כתובות השם הזה מייצג כעת ולשמור את ההחלטה עדכנית. אלה מנגנונים שונים עם דפוסי כשל שונים, והספקים משתמשים באותה מילה לשניהם. השוואה ביניהם ברשימות תכונות מחמיצה את העיקר; השוו ביניהם לפי מה שקורה כשהתשובה משתנה.
ההפרדה השימושית היא בין כלל שמפענח לבין כלל שאינו מפענח.
למה כל כלל בעצם תואם
כלל תחילית תואם לכתובות יעד בטבלת ניתוב. שום דבר לא מפוענח, שום דבר לא פג, וההתאמה מדויקת לכל מנה. כלל דומיין תואם לבקשה של יישום לשם, ש־RFC 1034 מגדיר כעץ של תוויות ולא ככתובת. חלק מהמוצרים מפענחים את השם פעם אחת ומתקינים את הכתובות שהתקבלו כנתיבים, מה שהופך את הכלל לכלל IP עם טיימר רענון מחובר.
דעו איזה משני אלה יש לכם לפני שאתם מנתחים תקלה, כי הכשל נראה אחרת לגמרי בכל מקרה.
היכן כלל הדומיין יושב במחסנית
אם המוצר מיישם כללי דומיין דרך פרוקסי מקומי, התעבורה חייבת להגיע לפרוקסי הזה, ויישומים שמתעלמים מפרוקסי המערכת עוקפים את הכלל לחלוטין. אם הוא מיישם אותם על ידי פענוח שמות והוספת נתיבים, הכתובות טריות רק עד הרענון האחרון. אם הוא מתחבר למפענח, התנהגות ה־DNS הופכת לחלק ממדיניות הניתוב, ומפענח גיבוי יכול לבטל אותה בשקט.
קראו את המודל של הספק ולא את תווית ההגדרה. שני לקוחות עם תיבה בשם Split Tunnel יכולים לעשות שלושה דברים שונים.
השוו מה נשבר
שלושה דברים נשברים אחרת. החלפת כתובות: שם מארח של CDN יכול להתפענח למערכת כתובות אחרת בתוך דקות, ולכן רשימה שהועתקה מתיישנת רע. היקף תת־דומיינים: כלל ל־example.com עשוי לכסות את api.example.com או לא, והתיעוד בדרך כלל מפורש לגבי איזה. כשל פענוח: כשהמפענח נכשל, לקוח שמפענח עשוי לחזור לנהור את התעבורה או לשלוח אותה ישירות.
רק השנייה היא שאלת תצורה. האחרות הן שאלות תכנון לגבי כמה המוצר מוכן לנחש.
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
מתי התחילית היא התשובה הטובה יותר
עבור תת־רשת פרטית יציבה, תחילית מפורשת ברורה יותר, מהירה יותר וקלה יותר לביקורת. היא גם שורדת הפסקת מפענח, כי שום דבר לא צריך להתפענח. פנו לכלל דומיין כשהשירות מתארח, כשכתובות מסתובבות, או כשבאמת אינכם יכולים למנות את מערכת היעדים. אל תפנו אליו רק מפני ששם המארח הוא מה שאתם מכירים במקרה.
רשימה סטטית מנוחשת היא הגרועה משניהם: היא נראית מתוחזקת, והיא מפספסת תעבורה בשקט ביום שבו הספק מוסיף מארח.
ודאו בבקשה טרייה
בדקו בבקשה קרה לאחר התחברות מחדש רגילה, כי עמוד מה־cache אולי לעולם לא ייגע בכלל. פענחו את השם, ואז בדקו לאן החיבור באמת הלך. dig +short app.example.com נותן את מערכת הכתובות הנוכחית, ורשימת החיבורים של הלקוח אומרת לכם איזה ממשק נשא את הזרימה.
חזרו על כך לאחר מרווח הרענון שהמוצר מתעד. אם מערכת הכתובות נסחפת והכלל לא עוקב, מצאתם את ההתנהגות האמיתית.
שמרו גם את מדיניות המפענח בנפרד. כלל דומיין צריך נתוני שמות נכונים, אבל הוא לבדו לא קובע איזה מפענח עונה לשאילתה.