כתובת ה-WAN השתנתה והמנהרה נפלה: הבדיקות לפי הסדר

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

תנו שם לאירוע לפני שאתם קוראים ביומן

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

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

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

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

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

אף אחת משתי ההתנהגויות לא אומרת דבר על היישומים שבפנים. מנהרה שהתאוששה אינה משחזרת הפעלת TCP שהעמית כבר חשב למתה.

מצב שהמנהרה אינה מחזיקה בו

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

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

סדרו את הבדיקות מבחוץ לפנים

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

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

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

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

החליטו על ההתנהגות הצפויה ורשמו אותה

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

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