יעדים מקוריים בהעברה שקופה מ-TCP ל-SOCKS

חומת אש יכולה לשנות היכן חיבור TCP נוחת. אך היא אינה יכולה, בשינוי הזה בלבד, ללמד את היישום המקורי לדבר SOCKS.

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

הרכיב החסר הוא מתרגם

רכיב שקוף מ-TCP ל-proxy יושב בין הממשקים האלה. הוא מגלה את היעד שהיישום ביקש במקור, מקים את הפעלת SOCKS או HTTP CONNECT המתאימה, ואז מעביר את נתוני היישום דרך הזרם שנוצר.

במסלול Linux iptables שלו, קוד המקור של redsocks שולף את היעד השמור באמצעות SO_ORIGINAL_DST. מערכות הפעלה אחרות ושיטות הפניה אחרות משתמשות במנגנונים שונים. זו תכונה של המפנה ושל תצורת הרשת, ולא תכונה של לקוח SOCKS רגיל.

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

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

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