שם DNS פרטי או רק כתובת IP? החליטו לפני שאתם משתפים

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

תנאי ראשון: איזה נתיב resolver יש ללקוחות?

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

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

resolver ציבורי לא ילמד אזור פרטי רק מפני שהמחשב הנייד התחבר ל-VPN.

הסיומת ראויה לאותה תשומת לב. השתמשו בתת-דומיין של דומיין שהארגון שולט בו, כדי שהבעלות ותכנון התעודות יישארו מפורשים. הימנעו מ-.local: מפרט ה-DNS הרב-שידורי קושר את הסיומת הזו לפתרון link-local, ומנהרה מנותבת אינה משחזרת את ההתנהגות הזו עבורכם.

תנאי שני: איזה מקור השירות מקבל?

כללי קבלה נכתבים מול כתובות, ולכן השאלה המועילה היא איזו כתובת השירות רואה לאחר ניתוב ותרגום. עבור שירות לדוגמה בכתובת 10.20.30.40, לקוחות המשרד מגיעים מ-10.20.30.0/24 ולקוחות מרוחקים מגיעים ממאגר נפרד כגון 10.99.0.0/24.

אם שער מתרגם את המאגר המרוחק, השירות רואה את המתרגם, וכלל שנכתב עבור 10.99.0.0/24 לא יתאים.

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

תנאי שלישי: האם השם קשור לשירות או למארח?

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

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

לכל דבר שיוחלף, ייבנה מחדש או יורחב, חזית יציבה שווה את התצורה הנוספת. הבדיקה פשוטה: אם אתם יכולים להחליף את ה-backend בלי לספר למשתמשים, השם קשור לשירות; אם לא, הוא קשור למארח.

בדקו את שתי ההחלטות בנפרד

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

curl -sv --max-time 5 https://files.corp.example/health

אחר כך בדקו פעם אחת מקור אסור, ורשמו את התוצאה.

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

היכן ההחלטה בדרך כלל משתבשת

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

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

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