SSH נופל ב-VPN כל דקה? זו לא ה-keepalive

SSH מתחבר, עובד כדקה, ואז קופא בערך באותו מרווח בכל פעם. ההסבר הנפוץ הוא פסק זמן של חוסר פעילות, אז אנשים מורידים את ה-MTU ומגדירים keepalives בצד הלקוח. קישור ה-WireGuard שעבדתי עליו כבר עבר את כל זה: MTU מנהרה קטן יותר, הגדרות client-alive, ו-keepalive מוגדר למנהרה. הנפילות נמשכו ללא שינוי. הסיבה התבררה כנתיב LAN אסימטרי, והתבנית שווה זיהוי כי היא מנצחת כל תיקון שמבוסס על טיימרים.

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

המיתוס: keepalives מתקנים נפילה שקטה

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

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

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

מה השער הנוסף באמת עושה

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

הכתובות למטה משקפות את הסידור הזה:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

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

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

בחר נתיב אחד מכוון

עבור הסידור למעלה, ניתוב תת-הרשת המרוחקת ישירות לשער ה-VPN מסיר את חצי החיבור:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

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

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

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

בדוק משני הקצוות

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

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

מתי אסימטריה בסדר

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

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