הגעה לאתר HTTPS הזמין רק דרך VPN באמצעות העברת SSH

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

שלב ראשון: אשרו את שלושת התנאים המוקדמים

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

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

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

שלב שני: קשרו פורט loopback ושמרו על הסשן פעיל

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

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

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

שלב שלישי: שמרו על שם ה-HTTPS כשהשקע מקומי

גלישה אל https://127.0.0.1:9443/ משנה את שם שרת ה-TLS ואת סמכות האפליקציה. תעודה שהונפקה עבור portal.lab.example לא תיבדק מול כתובת loopback, והשגיאה הנובעת מכך נראית כמו תעודה שבורה ולא כמו קיצור דרך של העברה. לבדיקת שורת פקודה, שמרו על ה-URL האמיתי ושנו רק את יעד השקע. זה מה ש---connect-to עושה, והמדריך curl מתעד את צורת ארבעת השדות המשמשת להלן.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

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

שלב רביעי: דעו מה העברה אחת אינה יכולה לכסות

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

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

שלב חמישי: נקו ותעדו

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

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