הדפדפן טוען עמוד HTTP דרך Squid. אותו יעד נכשל תחת proxychains. זה לא בהכרח אומר שאחד משני התוכנות בחר כתובת IP שגויה של פרוקסי.

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

כלומר, אתר טקסט פשוט בפורט 80 יכול ליצור בקשת CONNECT עבור פורט 80. מדיניות Squid שמתירה CONNECT רק לרשימת פורטי ה-TLS המאושרת שלה עשויה לדחות את המנהרה הזו אף שבקשות HTTP רגילות לפורט 80 מותרות.

השוו בקשות, לא רק שמות מארח

התיעוד של proxychains-ng מתאר את התמיכה שלו ב-HTTP CONNECT. כללי הגישה של Squid יכולים להבחין בין שיטה לפורט יעד. אלה נתיבי בקשה שונים לאותו אתר.

קראו את הדחייה ואת המדיניות המיועדת לפני שתשנו אותה. הרחבת גישת CONNECT לכל פורט היא שינוי מהותי; היא לא אמורה להיות התגובה המוגדרת כברירת מחדל לחוסר התאמה בעטיפה.

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

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

מאמרים קשורים