פינג עובד אבל SSH נכשל דרך ה-VPN: איזה שלב נשבר?
ניסיון מפורט אחד מפריד בין נגישות TCP, תעבורת SSH, זהות המארח, התחברות המשתמש והרשאת הסשן, כדי שתפסיק לנחש לגבי המנהרה.
תגובות פינג והתחברות SSH שנדחתה יכולות להיות נכונות בו-זמנית, והזוג לא מפליל את המנהרה. תגובות הדהוד וחיבור TCP לפורט 22 הם בדיקות שונות עם בוררים שונים, מדיניות שונה ולעיתים קרובות יעדים שונים. תעדו ניסיון SSH מכוון אחד, ואז תנו שם לשלב האחרון שאליו הגיע. אותו פריט ראיה אחד מחליף תריסר שינויי תצורה ספקולטיביים.
תעדו ניסיון אחד, לא סשן של דקירות
הריצו את הלקוח פעם אחת עם אבחון מפורט, שיתוף חיבורים מושבת וזמן המתנה מוגבל לחיבור. השבתת השיתוף חשובה כי חיבור מאסטר שאומת קודם לכן יענה במקום הניסיון החדש ויסתיר את התקלה שאתם רודפים אחריה.
ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]שמרו את היעד, משפחת הכתובות, חותמת הזמן והשגיאה האחרונה שאינה סודית. דגל IPv4 גם אומר שהניסיון הזה לא אומר דבר על נתיב IPv6 לאותו שם, אז אל תכלילו ממנו. תעדו מהיכן בוצע הניסיון. בדיקה בשער ה-VPN אינה נקודת המבט של מחשב נייד שמאחוריו, ורוב הסתירות בכרטיסים האלה נובעות מערבוב של השניים.
שלבים אחד ושניים: TCP לפני SSH
הגבול הראשון הוא נגישות ה-socket: כתובת, פורט ונתיב שהמנות באמת עוקב אחריו. אם חיבור ה-TCP לא מושלם לעולם, שום דבר מעליו עדיין לא קיים, ומפתחות מארח וחשבונות אינם רלוונטיים.
nc -vz 10.90.4.20 22
ip route get 10.90.4.20
tcpdump -ni any 'host 10.90.4.20 and port 22'תאמו את הלכידה עם ניסיון הלקוח. SYN שיוצא ושום דבר לא חוזר מצביע על סינון, בוררים או נתיב חסר בצד הרחוק; תגובה עם איפוס מצביעה על משהו שדוחה באופן פעיל ולא מפיל. הגבול השני הוא חילופי פרוטוקול SSH עצמם. חיבור TCP שמתבצע ואז נתקע עבר את הנגישות ונכנס למשא ומתן, לתגובת שרת או לטיפול בחבילות. זו חקירה אחרת, ושם בעיות שקשורות לגודל הופכות לאפשריות לראשונה.
שלב שלישי: של מי המפתח שענה
כשהתעבורה פעילה, הלקוח מאמת את מפתח המארח של השרת. דחייה כאן היא הצהרה על זהות, לא על קריפטוגרפיה: העמית הציג מפתח שהמדיניות שלכם אינה מקבלת. התייחסו לזה כתנאי עצירה ואמתו מחוץ לרצועה, מול הקונסולה או מול המפעיל שבנה מחדש את המארח. מחיקת הרשומה הזכורה כדי לנקות את האזהרה היא הקיצור היחיד שראוי לסרב לו, כי היא משמידה את הראיה שמשהו ענה באופן בלתי צפוי.
אם המארח אכן נבנה מחדש, הסירו את הרשומה הישנה רק לאחר אימות טביעת האצבע החדשה, ורשמו את התאריך והסיבה. המהנדס הבא ייתקל באותה אזהרה וזקוק להקשר הזה.
שלבים ארבעה וחמישה: חשבון מול הרשאה
אימות הוא הגבול הרביעי. אישורים שנדחו פירושם שהשרת העריך את הניסיון ודחה אותו; בדקו את החשבון, את סוג האישורים שהשרת מקבל ואת המדיניות של השרת עצמו ולא את סיסמת ה-VPN. הגבול החמישי הוא הרשאה לאחר התחברות מוצלחת. משתמש מאומת עדיין יכול להידחות מקבלת shell, מפקודה, מתת-מערכת או מהעברה, והדחיות האלה נראות כמו תקלות למי שקורא רק את השורה האחרונה של הלקוח.
| Last stage reached | What it proves | Where to look next |
|---|---|---|
| No TCP connection | No SSH transport exists | Address, port, route, selectors, filter, listener |
| TCP up, exchange incomplete | Reachability is not the blocker | Server response, negotiation, packet handling |
| Host identity rejected | The peer is not the expected host | Independently verified host key |
| User authentication rejected | The attempt reached authentication | Account, credential and server policy |
| Authenticated, session denied | Login succeeded, the operation did not | Shell, command or forwarding permission |
הפסיקו אחרי כמה ניסיונות סיסמה כושלים. ניחושים חוזרים יוצרים נעילות שנראות לאחר מכן כתקלה שנייה ולא קשורה, ועולות יותר זמן מהכרטיס המקורי.
חזרה לאחור והרשומה שאתם שומרים
שנו דבר אחד בכל פעם, ורשמו מה שיניתם לפני שתבדקו שוב. אם שינוי מחמיר את הניסיון, החזירו אותו מיד במקום לערום תיקון נוסף עליו. חזרו על הפעולה המקורית מהלקוח ומההקשר המקוריים. התחברות מוצלחת ממכונה אחרת, במשפחת כתובות אחרת, אינה שחזור ואינה מוכיחה את התיקון.
נקו את מה שאתם משתפים. פלט לקוח מפורט יכול לשאת שמות פנימיים, תוויות חשבון, נתיבי מפתחות ומזהי מפתח ציבורי, אז פרסמו את המסקנה המבוימת ולא עקבה גולמית.