מחשב נייד נודד: שם יציב או כתובת משרד קבועה?

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

הפרידו בין שלוש הדרישות

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

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

הפכו את השם לדבר היציב

תנו למחשב הנייד שם שנפתר לכתובת כלשהי שהקורא יכול להגיע אליה. בדוגמה הזו כתובת המשרד היא 192.168.50.42, מאגר הגישה מרחוק מחלק 10.90.0.42, ו-laptop17.corp.example עוקב אחרי החיבור. שום דבר לא דורש שהאוקטט האחרון יתאים, ותכנון סביב ההתאמה הזו יוצר עבודה בלי תועלת. הרשומה צריכה להצביע על הכתובת שהקורא יכול להשתמש בה באמת, לא על כל ממשק שהיה למחשב אי פעם.

dig +short laptop17.corp.example

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

כאשר רשימת מקורות מותרים היא האילוץ האמיתי

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

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

מה באמת דורש ההמשכיות

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

ss -tnp state established '( dport = :443 )'

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