שמרו על SSH מקומי כשהמארח מריץ VPN יוצא

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

השלבים שלהלן מניחים שהמנהל נמצא באותו LAN.ניהול מרחוק הוא בעיה אחרת עם תשובה אחרת.

קשרו את SSH לכתובת שהמנהלים משתמשים בה

התחילו מהמאזין.ss -ltnp | grep :22 מראה למה sshd קשור, ומאזין על 0.0.0.0 מקבל חיבורים מכל ממשק, כולל המנהרה. קשירה לכתובת ה-LAN צרה יותר והופכת את הכוונה לגלויה:ListenAddress 192.168.10.20 בתוך sshd_config, ולאחריה בדיקת תצורה וטעינה מחדש. שגיאת הקלדה בכתובת הזו גלויה יותר מתו כללי, מפני ש-sshd מסרב לעלות כשהכתובת אינה קיימת.

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

שמרו על מסלול ה-LAN מחוץ למנהרה

למארח עם כתובת ב-192.168.10.0/24 יש מסלול מחובר עבור הקידומת הזו, ומסלול ספציפי יותר מנצח את ברירת המחדל של ה-VPN באותה טבלה. זו הסיבה ש-SSH מקומי ממשיך לעתים קרובות לעבוד מעצמו כשהמנהרה עולה. אמתו זאת במקום להניח:ip route get 192.168.10.50 מציין את הממשק ואת כתובת המקור שבהם ישתמש הגרעין, והתשובה צריכה להיות התקן ה-LAN, לא המנהרה. חזרו על הבדיקה גם ממכונת המנהל, מפני שהטבלה שלו עצמה קובעת אם החבילות יגיעו בכלל. שני מארחים על אותו כבל יכולים לחלוק על הכיוון שנגיש.

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

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

הפכו את חריגת חומת האש לצרה כמו הכלל

אם המארח מריץ חומת אש, אפשרו SSH רק ממקור הניהול ורק בממשק ה-LAN. כלל שמתיר פורט 22 מכל מקום רחב יותר מהנדרש וקשה יותר להצדקה בסקירה. במארח nftables הכלל שייך לשרשרת הקלט עם התאמת ממשק ומקור; במארח iptables המקבילה היא זוג התאמות על -i ו -s. העירו על הכלל עם קבוצת המנהלים שהוא משרת, כדי שהביקורת הבאה לא תצטרך לנחש למה פורט 22 פתוח.

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

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

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

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

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

כתבו את נתיב השחזור ב-runbook

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

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