מפעילים לקוח VPN דרך SSH? הצמידו קודם את המסלול שלכם

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

רשמו את הנתיב לפני שמתחילים

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

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

הצמידו את הכתובת בהגדרה של הלקוח עצמו

מסלול שנוסף ביד נעלם באתחול ומתחרה בעדכוני הטבלה של הלקוח עצמו, לכן שימו את החריגה במקום שבו הטבלה מנוהלת. ב-OpenVPN מילת המפתח net_gateway נפתרת לשער שהתקיים לפני המנהרה, כך ש-route 203.0.113.9 255.255.255.255 net_gateway משאיר בדיוק כתובת אחת מחוצה לה. WireGuard זקוק לגישה אחרת מפני ש-wg-quick מנהל את המסלולים בעצמו: הגדירו Table = off והוסיפו את החריגה ב-PostUp, עם PostDown מתאים שמסיר אותה. שתי הצורות מבטאות את אותה כוונה, ושתיהן מגבילות את החריגה לכתובת אחת במקום להחליש את המנהרה להכול.

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

או הוציאו את הטבלה הראשית מהמשוואה

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

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

הניחו שההצמדה עלולה להיכשל

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

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

אמתו בסדר שחשוב

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

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