עורך VPN מרוחק דרך SSH: איזה מחשב אתם עורכים?

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

שלב 1: תנו שם למחשב שמחזיק בפרופיל

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

hostnamectl
hostname -f
ip -brief address

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

שלב 2: קראו את הפרופיל לפי UUID, לא לפי תווית

NetworkManager מזהה חיבור לפי UUID, בעוד השם הוא תווית שכל אחד יכול לערוך או לשכפל. הציגו את שניהם והתאימו את הרשומה שאתם באמת מתכוונים אליה, במיוחד במארח שאליו יובאו כמה פרופילי VPN במשך השנים.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show --active
nmcli general permissions

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

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

UUID=$(nmcli -g UUID connection show 'Corp VPN')
nmcli connection edit uuid "$UUID"

שלב 3: החליטו אם עורך גרפי הוא הכלי הנכון

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

echo "$DISPLAY"
ssh -X you@vpn-host
xauth list

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

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

שלב 4: שמרו נתיב התאוששות לפני שתפעילו משהו

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

sudo systemctl status NetworkManager
ip route show default
ss -tn state established '( sport = :22 )'

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

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