נפילת OpenVPN כל שעה: משא ומתן מחדש או חיבור מחדש אמיתי?

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

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

הבחינו בין איפוס רך לבין אתחול

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

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

קראו את הטיימר האפקטיבי, לא את הקובץ שלכם

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

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

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

שנו אותו במקום שבו הוא באמת נדחף

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

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

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

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

מה אתם מוותרים עליו כשמשביתים משא ומתן מחדש

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

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

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

כאשר המרווח מצביע למקום אחר

שני שכנים בתצורה מייצרים תסמינים דומים ותיקונים שונים. ping-restart מפעיל מחדש את המנהרה כאשר דבר אינו מגיע במשך תקופה מוגדרת, ואילו ping-exit מוריד את הלקוח לגמרי. נפילה בהמתנה בלי שום משא ומתן מחדש ביומן שייכת לאלה, או להתקן NAT שפג תוקף מיפוי ה-UDP לפי לוח הזמנים שלו.

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

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