Å lese ein SO_ORIGINAL_DST-feil i Squid

NF getsockopt(SO_ORIGINAL_DST) peikar på eit oppslag av den opphavlege destinasjonen. I eit avlyttoppsett må Squid gjenopprette kvar den omdirigerte forbindinga opphavleg var på veg.

Ein eksplisitt konfigurert nettlesar sender førespurnadene sine til proxyen med vilje. Den forbindinga får ikkje NAT-avlyttarhistorie berre fordi intercept står ved sida av porten til Squid-lyttaren.

Difor kan denne uoverensstemminga feile før sertifikatet til destinasjonen blir relevant.

Byrja med korleis forbindinga kom inn

• Viss applikasjonen har ein konfigurert proxyadresse, finn den vanlege vidaresendande proxylyttaren han bør bruke.
• Viss ein gateway omdirigerer trafikk som elles ville vore direkte, kontroller at han når den tiltenkte avlyttarlyttaren og at det støtta NAT-designet bevarer den nødvendige destinasjonsinformasjonen.
• Viss begge modusane finst, kontroller kva adresse og port den feilande klienten faktisk kontakta.

Squid-dokumentasjonen for http_port gjer skilnaden tydeleg: å utelate eit modusflagg vel vidaresendande proxymodus; intercept ventar NAT-avlytting på IP-nivå.

Deretter handsamar du transportsikkerheit separat. Ein HTTP-proxy kan bera HTTPS via CONNECT. Ei TLS-forbinding til proxyen krev ein kompatibel lyttar og klientkonfigurasjon. Å dekryptere destinasjonstrafikk er nok ein valfri eigenskap.

Ikkje kopier ei gammal “HTTPS-løysing” som slår på sertifikatgenerering berre fordi destinasjonsadressa byrjar med HTTPS. Reparer først samsvaret mellom klienten og lyttaren. Viss det deretter står att ein ekte TLS-feil, er det ein meir nyttig feil å undersøkje.