Att läsa ett SO_ORIGINAL_DST-fel i Squid

NF getsockopt(SO_ORIGINAL_DST) pekar på ett uppslag av den ursprungliga destinationen. I en avlyssningsuppsättning måste Squid återställa vart den omdirigerade anslutningen ursprungligen var på väg.

En uttryckligen konfigurerad webbläsare skickar sina förfrågningar till proxyn med avsikt. Den anslutningen får ingen NAT-avlyssningshistorik bara för att intercept står bredvid Squid-lyssnarens port.

Därför kan denna bristande överensstämmelse misslyckas innan destinationens certifikat blir relevant.

Börja med hur anslutningen kom in

• Om programmet har en konfigurerad proxyadress, identifiera den vanliga vidarebefordrande proxylyssnaren som det bör använda.
• Om en gateway omdirigerar trafik som annars skulle vara direkt, kontrollera att den når den avsedda avlyssningslyssnaren och att den stödda NAT-designen bevarar den nödvändiga destinationsinformationen.
• Om båda lägena finns, kontrollera vilken adress och port den felande klienten faktiskt kontaktade.

Squids dokumentation för http_port gör skillnaden tydlig: att utelämna en lägesflagga väljer vidarebefordrande proxyläge; intercept förväntar sig NAT-avlyssning på IP-nivå.

Behandla sedan transportsäkerheten separat. En HTTP-proxy kan bära HTTPS via CONNECT. En TLS-anslutning till proxyn kräver en kompatibel lyssnare och klientkonfiguration. Att dekryptera destinationstrafik är ännu en valfri förmåga.

Kopiera inte en gammal “HTTPS-lösning” som slår på certifikatgenerering bara för att destinationsadressen börjar med HTTPS. Reparera först överensstämmelsen mellan klienten och lyssnaren. Om det därefter återstår ett verkligt TLS-fel är det ett mer användbart fel att undersöka.