Webbläsaren läser in en HTTP-sida via Squid. Samma mål misslyckas under proxychains. Det betyder inte nödvändigtvis att något av de två programmen valde fel proxy-IP.

En vanlig HTTP-medveten klient kan skicka webbegäran till vidarebefordringsproxyn i HTTP-proxyform. Ett generiskt socket-omslag behöver i stället en bytestunnel för anslutningen som programmet ville öppna. För en HTTP-proxy i sin kedja använder proxychains CONNECT.

Det innebär att en klartextwebbplats på port 80 kan generera en CONNECT-begäran för port 80. En Squid-regel som bara tillåter CONNECT till sin godkända lista över TLS-portar kan avvisa den tunneln även om vanliga HTTP-begäranden till port 80 är tillåtna.

Jämför begäranden, inte bara värdnamn

Dokumentationen för proxychains-ng beskriver dess HTTP CONNECT-stöd. Squids åtkomstregler kan skilja mellan metod och målport. Det är olika begärandevägar till samma webbplats.

Läs avvisandet och den avsedda regeln innan du ändrar den. Att utöka CONNECT-åtkomsten till varje port är en betydande ändring; det bör inte vara standardresponsen på en missanpassning i omslaget.

Om programmet har inbyggt HTTP-proxystöd kan användning av det undvika en onödig generisk tunnel för klartext-HTTP. Om det verkligen behöver en rå TCP-tunnel, välj ett godkänt proxyprotokoll och en portregel som tillhandahåller en.

En lyckad webbläsarbegäran är ett användbart bevis om proxyns nåbarhet och om ett stött begärandeläge. Den bevisar inte att varje tunnelmetod, målport eller programprotokoll är tillåten genom den proxyn.

Relaterade artiklar