Browseren indlæser en HTTP-side gennem Squid. Samme destination fejler under proxychains. Det betyder ikke nødvendigvis, at et af de to programmer valgte en forkert proxy-IP.

En almindelig HTTP-klient kan sende webanmodningen til forward-proxyen i HTTP-proxyform. En generisk socket-indpakning har derimod brug for en bytetunnel til den forbindelse, som applikationen ville åbne. For en HTTP-proxy i sin kæde bruger proxychains CONNECT.

Det betyder, at et klartekstwebsted på port 80 kan frembringe en CONNECT-anmodning til port 80. En Squid-politik, der kun tillader CONNECT til sin godkendte liste over TLS-porte, kan afvise den tunnel, selv om almindelige HTTP-anmodninger til port 80 er tilladte.

Sammenlign anmodninger, ikke kun værtsnavne

Dokumentationen for proxychains-ng beskriver dens HTTP CONNECT-understøttelse. Squids adgangsregler kan skelne mellem metode og destinationsport. Det er forskellige anmodningsveje til samme websted.

Læs afvisningen og den tilsigtede politik, før du ændrer den. At udvide CONNECT-adgang til alle porte er en væsentlig ændring; det bør ikke være standardsvaret på en uoverensstemmelse i indpakningen.

Hvis applikationen har indbygget HTTP-proxyunderstøttelse, kan brug af den undgå en unødig generisk tunnel til klartekst-HTTP. Hvis den virkelig har brug for en rå TCP-tunnel, så vælg en godkendt proxyprotokol og portpolitik, der leverer en.

En vellykket browseranmodning er nyttigt bevis om proxyens rækkevidde og om én understøttet anmodningstilstand. Den beviser ikke, at enhver tunnelmetode, destinationsport eller applikationsprotokol er tilladt gennem den proxy.

Relaterede artikler