ddclient מפרסם את יציאת ה-VPN: תקנו את מקור הגילוי

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

ודאו למה השם אמור להגיע

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

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

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

שחזרו את הערך לפני שתשנו משהו

צפו בשני המסלולים בנפרד. כשהמנהרה פעילה, הבדיקה מדווחת על היציאה; כשהמנהרה כבויה, או כשהבדיקה כבולה לממשק הפיזי, היא מדווחת על כתובת הבית: curl --interface eth0 https://ifconfig.me. אם שתי התשובות שונות, שחזרתם את התקלה בלי לגעת במעדכן.

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

כוונו את הגילוי למסלול הנבחר

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

למסלול מצב הנתב, גרסאות חדשות של ddclient משתמשות במשפחת האפשרויות usev4 ו-fwv4, עם תבנית דילוג אופציונלית לטקסט שמסביב לדף. בדקו את ה-README של הגרסה המותקנת שלכם, כי גרסאות ישנות כותבות את אותו רעיון עם use ו-fw, ושם אפשרות שהועתק מהגרסה הלא נכונה נכשל בעת האתחול.

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

שמרו על סודות וגרסאות מסודרים

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

ה-ddclient README מתעד את גישות הגילוי ואת שמות האפשרויות שלהן. אל תערבבו תוצאות IPv4 ו-IPv6 ברשומה אחת, ואל תניחו שאפשרות שקיימת בגרסה אחת קיימת באחרת.

אמתו את הערך, ואחר כך את הנגישות

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

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