OpenVPN נופל לאחר חידוש DHCP: שמרו על המסלול לנקודת הקצה

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

השוו את הסימפטום למסלולי ברירת המחדל החצויים

עם redirect-gateway def1, OpenVPN מתקין את 0.0.0.0/1 ואת 128.0.0.0/1 במקום להחליף את מסלול ברירת המחדל. יחד שני אלה מכסים את כל מרחב הכתובות, והם גוברים על 0.0.0.0/0 רק לפי אורך הקידומת. לכן כל יעד בלי התאמה ספציפית יותר נכנס למנהרה.

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

אשרו את צורת הטבלה לפני שנוגעים בכל דבר אחר. ip route show אמור לפרט את שני החצאים ועוד מסלול מארח לכתובת השרת; כשמסלול המארח חסר, לשאר החקירה יש נקודת התחלה ברורה.

למה המסלולים החצויים מנצחים בלי שינוי מדד

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

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

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

קחו שלושה צילומים, לא אחד

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

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

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

החליטו איזה רכיב מרענן את החריגה

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

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

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

בדקו את מחזור החיים, לא רק את החיבור מחדש

כפו חידוש עם dhcpcd -n eth0 או בשחרור החכירה ולקיחתה מחדש, ואז בדקו שוב ip route get עבור נקודת הקצה. עשו זאת פעמיים, כי הריצה השנייה תופסת ווים שמוסיפים מסלולים כפולים. ואז אתחלו, כי התמדה היא תכונה אחרת מנכונות.

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