Proxychains از طریق Squid: محدودیت‌های CONNECT روی پورت 80

مرورگر یک صفحهٔ HTTP را از طریق Squid بارگذاری می‌کند. همان مقصد زیر proxychains شکست می‌خورد. این لزوماً به معنای آن نیست که یکی از دو برنامه IP پروکسی نادرست را انتخاب کرده است.

یک کلاینت معمولی که HTTP را می‌فهمد می‌تواند درخواست وب را در قالب پروکسی HTTP به پروکسی جلویی بفرستد. اما یک پوشش سوکت عمومی به یک تونل بایتی برای اتصالی نیاز دارد که برنامه می‌خواست باز کند. proxychains برای پروکسی HTTP در زنجیرهٔ خود از CONNECT استفاده می‌کند.

یعنی یک وب‌سایت متن ساده روی پورت 80 می‌تواند درخواست CONNECT برای پورت 80 تولید کند. سیاست Squid که CONNECT را فقط به فهرست پورت‌های TLS تأییدشده‌اش اجازه می‌دهد می‌تواند آن تونل را رد کند، هرچند درخواست‌های معمولی HTTP به پورت 80 مجاز باشند.

درخواست‌ها را مقایسه کنید، نه فقط نام میزبان‌ها را

مستندات proxychains-ng پشتیبانی آن از HTTP CONNECT را توصیف می‌کند. قواعد دسترسی Squid می‌توانند روش و پورت مقصد را از هم تشخیص دهند. این‌ها مسیرهای درخواست متفاوتی به یک وب‌سایت هستند.

پیش از تغییر، دلیل رد و سیاست مورد نظر را بخوانید. گسترش دسترسی CONNECT به همهٔ پورت‌ها تغییری اساسی است؛ نباید پاسخ پیش‌فرض به ناسازگاری پوشش باشد.

اگر برنامه پشتیبانی بومی پروکسی HTTP دارد، استفاده از آن می‌تواند از یک تونل عمومی غیرضروری برای HTTP متن ساده جلوگیری کند. اگر واقعاً به تونل TCP خام نیاز دارد، پروتکل پروکسی و سیاست پورت تأییدشده‌ای را انتخاب کنید که آن را فراهم کند.

یک درخواست موفق مرورگر شاهد مفیدی دربارهٔ دسترس‌پذیری پروکسی و یک حالت درخواست پشتیبانی‌شده است. اما ثابت نمی‌کند که هر روش تونل‌سازی، پورت مقصد یا پروتکل برنامه از طریق آن پروکسی مجاز است.