האם צריך DNS דינמי לשרת VPN ביתי?

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

תנאי ראשון: הכתובת שלכם באמת זזה

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

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

curl -fsS https://api.ipify.org; echo

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

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

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

OpenVPN מפרש מחדש את השורה remote vpn.example.net 1194 בכל התחברות מחדש, ו-resolv-retry infinite ממשיך לנסות שוב במקום לצאת כשהחיפוש נכשל. בשרת, float מאפשר לשיחה מבוססת לעקוב אחר עמית שכתובת המקור שלו השתנתה. WireGuard ישיר יותר: wg-quick up מפרש את Endpoint כשהתצורה מוחלת, והלקוח מפרש אותו שוב כשהוא בונה מחדש את המנהרה, כך שלחיצת יד שעדיין מצליחה מול הכתובת הישנה ממשיכה להצליח עד שהיא נעצרת.

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

תנאי שלישי: נתיב הכניסה עדיין פתוח

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

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

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

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

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

הריצו אותו מטיימר systemd כל כמה דקות במקום מלולאת shell, ורשמו ביומן את תגובת הספק במקום להניח הצלחה. התייחסו לאישור כמו למפתח, כי הוא קובע לאן כל לקוח נשלח: השתמשו באסימון עדכון מוגבל במקום בסיסמת חשבון, שמרו את הקובץ במצב 0600 ושלחו עדכונים ב-HTTPS.

אמתו לפני שאתם מתחייבים

חיפוש אחד אומר לכם מה שאר העולם רואה, והוא מדפיס את ה-TTL שעליכם להמתין אחרי שינוי:

dig +noall +answer vpn.example.net @1.1.1.1

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

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

כשהתשובה היא לא

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

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

לפני שתמשיכו, אשרו ארבעה דברים לפי הסדר:

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

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