שתי הגדרות פרוקסי יכולות ליצור שרשרת שלא התכוונתם לה

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

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

application → wrapper proxy A → application proxy B → website

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

לתרשים הפשוט יש תנאים

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

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

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

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