Nettlesaren lastar ei HTTP-side gjennom Squid. Same mål mislukkast under proxychains. Det tyder ikkje nødvendigvis at eitt av dei to programma valde feil proxy-IP.

Ein vanleg HTTP-kyndig klient kan senda nettførespurnaden til videresendingsproxyen i HTTP-proxyform. Eit generisk socket-innpakking treng derimot ein bytetunnel for sambandet programmet ville opna. For ein HTTP-proxy i kjeda brukar proxychains CONNECT.

Det tyder at eit klartekstnettstad på port 80 kan laga ein CONNECT-førespurnad for port 80. Ein Squid-policy som berre tillèt CONNECT til si godkjende liste over TLS-portar, kan avvisa den tunnelen sjølv om vanlege HTTP-førespurnader til port 80 er tillatne.

Samanlikn førespurnader, ikkje berre vertsnamn

Dokumentasjonen for proxychains-ng skildrar støtta for HTTP CONNECT. Tilgangsreglane til Squid kan skilja mellom metode og målport. Dette er ulike førespurnadsvegar til same nettstad.

Les avvisinga og den tiltenkte policyen før du endrar han. Å utvida CONNECT-tilgang til kvar port er ei vesentleg endring; det bør ikkje vera standardresponsen på eit mishøve i innpakkinga.

Viss programmet har innebygd HTTP-proxystøtte, kan bruk av han unngå ein unødvendig generisk tunnel for klartekst-HTTP. Viss det verkeleg treng ein rå TCP-tunnel, vel ein godkjend proxyprotokoll og portpolicy som leverer ein.

Ein vellukka nettlesarførespurnad er nyttig prov om rekkevidda til proxyen og om éin støtta førespurnadsmodus. Han beviser ikkje at kvar tunnelmetode, målport eller programprotokoll er tillaten gjennom den proxyen.

Relaterte artiklar