Proxychains via Squid: CONNECT-beperkingen op poort 80
Onderscheid gewone HTTP-proxyverzoeken van proxychains HTTP CONNECT-tunnels wanneer de bestemmingspoort 80 wordt geweigerd.
De browser laadt een HTTP-pagina via Squid. Dezelfde bestemming mislukt onder proxychains. Dat betekent niet noodzakelijk dat een van beide programma's de verkeerde proxy-IP koos.
Een gewone HTTP-bewuste client kan het webverzoek in HTTP-proxyvorm naar de forward-proxy sturen. Een generieke socket-wrapper heeft daarentegen een bytetunnel nodig voor de verbinding die de toepassing wilde openen. Voor een HTTP-proxy in zijn keten gebruikt proxychains CONNECT.
Dat betekent dat een platte-tekstwebsite op poort 80 een CONNECT-verzoek voor poort 80 kan opleveren. Een Squid-beleid dat CONNECT alleen naar zijn goedgekeurde TLS-poortenlijst toestaat, kan die tunnel weigeren terwijl gewone HTTP-verzoeken naar poort 80 zijn toegestaan.
Vergelijk verzoeken, niet alleen hostnamen
De documentatie van proxychains-ng beschrijft de HTTP CONNECT-ondersteuning. De toegangsregels van Squid kunnen methode en bestemmingspoort onderscheiden. Dit zijn verschillende verzoekpaden naar dezelfde website.
Lees de weigering en het bedoelde beleid voordat u het wijzigt. CONNECT-toegang uitbreiden naar elke poort is een ingrijpende wijziging; het zou niet de standaardreactie op een wrapper-misverstand moeten zijn.
Als de toepassing native HTTP-proxyondersteuning heeft, kan het gebruik daarvan een onnodige generieke tunnel voor platte-tekst-HTTP vermijden. Als het echt een ruwe TCP-tunnel nodig heeft, kies dan een goedgekeurd proxyprotocol en poortbeleid dat er een levert.
Een geslaagd browserverzoek is nuttig bewijs over de bereikbaarheid van de proxy en over één ondersteunde verzoekmodus. Het bewijst niet dat elke tunnelmethode, bestemmingspoort of toepassingsprotocol via die proxy is toegestaan.