WireGuard עדיין משתמש בנקודת הקצה הישנה אחרי שינויי DNS

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

השם נפתר פעם אחת, לא באופן רציף

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

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

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

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

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

מדריך wg(8) מתעד את פקודות המשנה show שבהן משתמשות השורות האלה. השוו גם את משפחת הכתובות, לא רק את הכתובת, כי רשומה שקיבלה רשומת IPv6 היא השוואה אחרת מזו שכתובת ה-IPv4 שלה השתנתה. אם נקודת הקצה שונה מהרשומה, הממשק פועל על מידע מיושן והשם מעולם לא היה הבעיה. אם הן תואמות והמנהרה עדיין נכשלת, עברו למאזין ולכללים ולא לפרופיל.

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

הפעילו מחדש דרך המנהל של הממשק

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

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

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

קודם לחיצת יד, אחר כך נתיב הנתונים

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

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