שם נקודת קצה של VPN לעומת שם שירות פרטי: שני בעלים

שני שמות יכולים לתאר את אותו סניף ולהשיב על שאלות שונות לחלוטין. vpn.branch.example אומר לעמית מרוחק היכן למצוא את נקודת הקצה של VPN, והוא חייב להיפתר לפני שקיימת מנהרה. inventory.branch.example אומר למשתמש מורשה היכן נמצאת אפליקציה פרטית, והוא חשוב רק לאחר שהמנהרה עולה. תחזוקה של האחד לא עושה דבר לשני.

תנו שם לשני הרשומות לפני שאתם מנפים באגים באחת מהן

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

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

כשמוצע שינוי, שאלו איזו משתי הרשומות הוא נוגע בה. אם איש אינו יכול להשיב, השינוי אינו מוכן לתזמון.

נקודת הקצה חייבת להיפתר לפני שקיימת מנהרה

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

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

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

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

שם השירות מתאר היכן האפליקציה חיה

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

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

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

בדקו את שני הנתיבים בנפרד

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

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

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

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