Proxychains tramite Squid: restrizioni CONNECT sulla porta 80
Distinguere le normali richieste HTTP proxy dai tunnel HTTP CONNECT di proxychains quando la porta 80 di destinazione viene negata.
Il browser carica una pagina HTTP tramite Squid. La stessa destinazione fallisce con proxychains. Ciò non significa necessariamente che uno dei due programmi abbia scelto un IP del proxy sbagliato.
Un normale client che comprende HTTP può inviare la richiesta web al proxy forward in forma di proxy HTTP. Un wrapper di socket generico invece necessita di un tunnel di byte per la connessione che l'applicazione voleva aprire. Per un proxy HTTP nella sua catena, proxychains usa CONNECT.
Ciò significa che un sito in testo semplice sulla porta 80 può generare una richiesta CONNECT per la porta 80. Una regola di Squid che consente CONNECT solo verso la propria lista approvata di porte TLS può rifiutare quel tunnel anche se le normali richieste HTTP alla porta 80 sono consentite.
Confrontate le richieste, non solo i nomi host
La documentazione di proxychains-ng descrive il suo supporto per HTTP CONNECT. Le regole di accesso di Squid possono distinguere metodo e porta di destinazione. Sono percorsi di richiesta diversi verso lo stesso sito.
Leggete il rifiuto e la regola prevista prima di modificarla. Estendere l'accesso CONNECT a ogni porta è un cambiamento sostanziale; non dovrebbe essere la risposta predefinita a una discrepanza del wrapper.
Se l'applicazione ha il supporto nativo per il proxy HTTP, usarlo può evitare un tunnel generico non necessario per HTTP in testo semplice. Se ha davvero bisogno di un tunnel TCP grezzo, scegliete un protocollo proxy e una regola di porte approvati che lo forniscano.
Una richiesta del browser riuscita è una prova utile della raggiungibilità del proxy e di una modalità di richiesta supportata. Non dimostra che ogni metodo di tunneling, porta di destinazione o protocollo applicativo sia consentito attraverso quel proxy.