הגעה לפרוקסי HTTP או SOCKS קיים דרך SSH
הגיעו לפרוקסי HTTP או SOCKS מרוחק ב-loopback דרך SSH בלי לחשוף את המאזין שלו לציבור.
אם relay.example.net כבר מריץ SOCKS על ה-127.0.0.1:1080 שלו, העבירו את הגישה במקום לחשוף את המאזין הזה לציבור:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| נקודת קצה | תפקיד |
|---|---|
מחשב נייד 127.0.0.1:1081 | כתובת ה-SOCKS שיש להגדיר באפליקציה במחשב הנייד. |
ממסר 127.0.0.1:1080 | הפרוקסי הקיים שאליו מגיעים מצד שרת ה-SSH. |
תחביר ההעברה המקומית מקצה את היעד הקבוע לצד השרת. פרוקסי HTTP על פורט ה-loopback המרוחק 3128 או נקודת קצה פנימית כמו proxy.internal.example:8080 פועל באותו עיקרון. הגדירו את הלקוח לפרוטוקול ה-HTTP הקיים הזה ולחשבון; העברה דרך SSH אינה יוצרת SOCKS ואינה מאזין HTTPS עם TLS.
השירות הקיים עדיין בוחר את גרסאות הפרוטוקול הנתמכות, את האימות, את היעדים ואת היציאה הסופית. אם תהליך SSH אחר יצר את הפרוקסי המרוחק הזה, שני התהליכים חייבים להישאר פעילים. מסלול מחשב נייד→ממסר→שער מותיר לאתר לראות את החיבור היוצא האחרון, ולא זהות שהוקצתה על ידי פורט מקומי 1081.
השאירו את הכריכה של המחשב הנייד מקומית במפורש. חשיפה רחבה יותר משנה מי יכול להגיע לשירות, וכניסת SSH אינה מוסיפה סיסמת SOCKS למאזין. במקרה של סירוב, בדקו את המאזין במחשב הנייד, את תעבורת ה-SSH ואת הפרוקסי המרוחק כשלבים נפרדים.