Die blaaier laai 'n HTTP-bladsy deur Squid. Dieselfde bestemming misluk onder proxychains. Dit beteken nie noodwendig dat een van die twee programme die verkeerde proxy-IP gekies het nie.

'n Gewone HTTP-bewuste kliënt kan die webversoek in HTTP-proxyvorm na die voorwaartse proxy stuur. 'n Generiese socket-omhulsel het eerder 'n grewe-tonnel nodig vir die verbinding wat die toepassing wou oopmaak. Vir 'n HTTP-proxy in sy ketting gebruik proxychains CONNECT.

Dit beteken 'n gewone-teks webwerf op poort 80 kan 'n CONNECT-versoek vir poort 80 lewer. 'n Squid-beleid wat CONNECT slegs na sy goedgekeurde TLS-poortlys toelaat, kan daardie tonnel verwerp selfs al word gewone HTTP-versoeke na poort 80 toegelaat.

Vergelyk versoeke, nie net gasheernommers nie

Die proxychains-ng-dokumentasie beskryf sy HTTP CONNECT-ondersteuning. Squid se toegangsreëls kan metode en bestemmingspoort onderskei. Dit is verskillende versoekroetes na dieselfde webwerf.

Lees die verwerping en die beoogde beleid voordat dit verander word. Om CONNECT-toegang na elke poort uit te brei is 'n aansienlike verandering; dit behoort nie die standaardreaksie op 'n omhulsel-wanverhouding te wees nie.

As die toepassing inheemse HTTP-proxyondersteuning het, kan die gebruik daarvan 'n onnodige generiese tonnel vir gewone-teks HTTP vermy. As dit werklik 'n rou TCP-tonnel nodig het, kies 'n goedgekeurde proxyprotokol en poortbeleid wat een voorsien.

'n Suksesvolle blaaierversoek is nuttige bewyse oor die proxy se bereikbaarheid en een ondersteunde versoekmodus. Dit bewys nie dat elke tonnelmetode, bestemmingspoort of toepassingsprotokol deur daardie proxy toegelaat word nie.

Verwante artikels