Proxychains через Squid: обмеження CONNECT на порту 80
Розрізняйте звичайні запити HTTP-проксі та тунелі HTTP CONNECT від proxychains, коли цільовий порт 80 заборонено.
Браузер завантажує HTTP-сторінку через Squid. Та сама ціль не працює під proxychains. Це не обов'язково означає, що одна з двох програм обрала неправильну IP-адресу проксі.
Звичайний клієнт, який розуміє HTTP, може надіслати вебзапит до прямого проксі у формі HTTP-проксі. Натомість універсальна обгортка сокета потребує байтового тунелю для з'єднання, яке застосунок хотів відкрити. Для HTTP-проксі у своєму ланцюжку proxychains використовує CONNECT.
Це означає, що звичайний текстовий сайт на порту 80 може створити запит CONNECT для порту 80. Політика Squid, яка дозволяє CONNECT лише до затвердженого списку портів TLS, може відхилити такий тунель, навіть якщо звичайні HTTP-запити на порт 80 дозволені.
Порівнюйте запити, а не лише імена хостів
Документація proxychains-ng описує підтримку HTTP CONNECT. Правила доступу Squid можуть розрізняти метод і цільовий порт. Це різні шляхи запиту до того самого сайту.
Прочитайте відмову та передбачену політику, перш ніж її змінювати. Розширення доступу CONNECT на кожен порт — істотна зміна; це не має бути типовою відповіддю на невідповідність обгортки.
Якщо застосунок має вбудовану підтримку HTTP-проксі, її використання може уникнути зайвого універсального тунелю для звичайного текстового HTTP. Якщо йому справді потрібен необроблений TCP-тунель, виберіть затверджений протокол проксі та політику портів, які його надають.
Успішний запит браузера — корисний доказ доступності проксі та одного підтримуваного режиму запиту. Але він не доводить, що кожен метод тунелювання, цільовий порт чи протокол застосунку дозволений через цей проксі.