Nettleseren laster en HTTP-side gjennom Squid. Samme destinasjon feiler under proxychains. Det betyr ikke nødvendigvis at ett av de to programmene valgte feil proxy-IP.

En vanlig HTTP-kyndig klient kan sende nettforespørselen til videresendingsproxyen i HTTP-proxyform. En generisk socket-innpakning trenger derimot en bytetunnel for forbindelsen applikasjonen ville åpne. For en HTTP-proxy i kjeden bruker proxychains CONNECT.

Det betyr at et klartekstnettsted på port 80 kan lage en CONNECT-forespørsel for port 80. En Squid-policy som bare tillater CONNECT til sin godkjente liste over TLS-porter, kan avvise den tunnelen selv om vanlige HTTP-forespørsler til port 80 er tillatt.

Sammenlign forespørsler, ikke bare vertsnavn

Dokumentasjonen for proxychains-ng beskriver støtten for HTTP CONNECT. Squids tilgangsregler kan skille mellom metode og destinasjonsport. Dette er ulike forespørselsveier til samme nettsted.

Les avvisningen og den tiltenkte policyen før du endrer den. Å utvide CONNECT-tilgang til alle porter er en betydelig endring; det bør ikke være standardresponsen på en misforhold i innpakningen.

Hvis applikasjonen har innebygd HTTP-proxystøtte, kan bruk av den unngå en unødvendig generisk tunnel for klartekst-HTTP. Hvis den virkelig trenger en rå TCP-tunnel, velg en godkjent proxyprotokoll og portpolicy som leverer en.

En vellykket nettleserforespørsel er nyttig bevis om proxyens rekkevidde og én støttet forespørselsmodus. Den beviser ikke at enhver tunnelmetode, destinasjonsport eller applikasjonsprotokoll er tillatt gjennom den proxyen.

Relaterte artikler