העברה מקומית ב-SSH לפרוקסי HTTP קיים: שתי כתובות loopback

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

החליטו אם קיים כבר פרוקסי קבוע

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

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

בנו את ההעברה וקראו את הפקודה

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

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N מדכא פקודה מרוחקת ו--T מדכא הקצאת termios, כי אתם רוצים מנהרה ולא מעטפת. כתובת ה-loopback הראשונה היא המקום שבו המחשב הנייד מאזין; השנייה נפתרת על ידי שרת ה-SSH, ולכן 127.0.0.1 שם פירושו הפרוקסי באותה מכונה. ExitOnForwardFailure גורם לפקודה להיכשל בקול רם אם הפורט המקומי כבר תפוס, במקום להתחיל הפעלה שלא מעבירה דבר. כתבו את כתובת היעד כפי שהשרת פותר אותה, כי שם שרק המחשב הנייד שלכם יכול לפתור ייכשל בצד השני.

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

כוונו יישום אחד אל ההעברה

הגדירו את היישום להשתמש בפרוקסי HTTP בכתובת http://127.0.0.1:13128, עם פרטי התחברות אם הפרוקסי המרוחק דורש אותם. שמרו על אימות התעודות של היישום עצמו ליעדי HTTPS, כי מנהרת הפרוקסי אינה מחליפה אותו. זו העברה קבועה של שירות אחד, ולכן חייבים לומר ליישום שיש פרוקסי במקום להשאיר אותו לגלות אחד בעצמו.

בדיקה מהירה לפני כל הגדרה קבועה: curl -x http://127.0.0.1:13128 -I https://example.com, שמפעיל את שיטת HTTP CONNECT שהפרוקסי חייב לתמוך בה.

השאירו את הסמכות היכן שהייתה

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

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

אמתו את שני הקצוות ואז נקו

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

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