למה כלל פורט מקור שובר אחד מנתיבי ה-SSH שלך

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

שתי כניסות, פורט שירות אחד

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

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

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

קרא את הכלל, ואז את הטבלה

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

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

ip -4 rule show
ip route show table 100
ip route show table main

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

הגבל את הכלל לזרימה שאתה מתכוון אליה

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

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

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

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

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

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

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

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

הוכח זאת בהפעלה חדשה, לא בישנה

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

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

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