Proxychains tra Squid: CONNECT-limoj sur pordo 80
Distingi ordinarajn HTTP-proksaj petojn de la HTTP CONNECT-tuneloj de proxychains, kiam la celloka pordo 80 estas rifuzata.
La retumilo ŝargas HTTP-paĝon tra Squid. La sama celo fiaskas sub proxychains. Tio ne nepre signifas, ke unu el la du programoj elektis malĝustan proksan IP-adreson.
Ordinara HTTP-kapabla kliento povas sendi la retan peton al la antaŭa prokso en HTTP-proksa formo. Generika soketa ĉirkaŭvolvaĵo anstataŭe bezonas bajtan tunelon por la konekto, kiun la aplikaĵo volis malfermi. Por HTTP-prokso en sia ĉeno, proxychains uzas CONNECT.
Tio signifas, ke simplteksta retejo sur pordo 80 povas produktei CONNECT-peton por pordo 80. Squid-politiko, kiu permesas CONNECT nur al sia aprobita listo de TLS-pordoj, povas rifuzi tiun tunelon, kvankam ordinaraj HTTP-petoj al pordo 80 estas permesataj.
Komparu petojn, ne nur gastigajn nomojn
La dokumentaro de proxychains-ng priskribas ĝian subtenon de HTTP CONNECT. La aliraj reguloj de Squid povas distingi metodon kaj cellokan pordon. Temas pri malsamaj petvojoj al la sama retejo.
Legu la rifuzon kaj la celatan politikon antaŭ ol ŝanĝi ĝin. Etendi CONNECT-aliron al ĉiu pordo estas granda ŝanĝo; ĝi ne devus esti la defaŭlta respondo al ĉirkaŭvolvaĵa malkongruo.
Se la aplikaĵo havas denaskan subtenon de HTTP-prokso, uzi ĝin povas eviti nenecesan generikan tunelon por simplteksta HTTP. Se ĝi vere bezonas krudan TCP-tunelon, elektu aprobitan proksan protokolon kaj pordan politikon, kiuj provizas unu.
Sukcesa retumila peto estas utila pruvo pri la atingeblo de la prokso kaj pri unu subtenata petreĝimo. Ĝi ne pruvas, ke ĉiu tunela metodo, celloka pordo aŭ aplikaĵa protokolo estas permesata tra tiu prokso.