העניקו ל-Pi מרוחק פרוקסי SOCKS דרך לקוח ה-SSH שלכם

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

המאזין והצד שממנו נוצר החיבור יכולים להיות שונים

ssh -D 1080 רגיל מריץ את המאזין במחשב שלכם ושולח חיבורים משם. העברה דינמית מרוחקת הופכת את זה: המאזין מופיע במארח המרוחק, וכל חיבור שהוא מקבל נפתח מהצד המקומי. המדריך של לקוח OpenSSH מתעד -R בלי יעד קבוע בדיוק כסידור SOCKS4/5 הזה.

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

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

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

מה המאזין המרוחק באמת חושף

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

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

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

העבירו יישום אחד דרך הפרוקסי

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

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

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

המחשב הנייד עדיין זקוק לנתיב משלו ולגישה לפותר גם לשרת ה-SSH וגם ליישום. יש לבחור את התעבורה של לקוח ה-SSH שלו במדיניות ה-VPN המאושרת, וחריגת split-tunnel יכולה לשלוח את התעבורה הזו בנתיב אחר מזה שבדקתם.

הוכיחו את הנתיב וסגרו אותו

ודאו שהמאזין קיים במקום שבו אתם מצפים ושהיעד המיועד בלבד עונה:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

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

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

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