ServerAliveInterval של SSH דרך VPN: איזה צד שולח את הבדיקה?

רוב העצות לשמירת חיבור SSH פעיל נעצרות ב«הוסיפו ServerAliveInterval 30» ומשאירות בחוץ את החלקים השימושיים. מילת המפתח היא טיימר בצד הלקוח שנורה רק כשהערוץ שקט, הוא סופר בדיקות ללא מענה ולא שניות, והוא חי בקובץ שבו הערך הראשון שמתאים מנצח. טעו בשלושת המאפיינים האלה והפעלה בריאה של VPN עדיין תיפול, בעוד שחיבור מת יישאר תלוי.

שני הכיוונים שייכים לדמונים שונים

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

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

מה בדיקה מוכיחה ומה לא

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

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

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

הסדר קובע איזה ערך שורד

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

אפשרויות שורת הפקודה מנצחות את הקובץ, מה שהופך ניסוי זמני לזול:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

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

ssh -G office-shell | grep -i alive

מה עושות בדיקות החיים דרך מנהרה

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

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

חיבורים מרובי-שימוש מוסיפים קמט. כש-ControlMaster במשחק הבדיקות שייכות לחיבור הראשי, והפעלה חדשה מעל ראשי קיים יורשת את מה שהראשי ההוא ניהל משא ומתן עליו. אם הראשי של ה-mux תקוע, פתיחת חלון נוסף לא תבדוק את הנתיב שוב.

אימות ההגדרה מקצה לקצה

בשרת, הפיקו את תצורת הדמון האפקטיבית במקום לקרוא את הקובץ ולנחש איזה include ניצח:

sshd -T | grep -i clientalive

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

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