Å lese en SO_ORIGINAL_DST-feil i Squid

NF getsockopt(SO_ORIGINAL_DST) peker på et oppslag av den opprinnelige destinasjonen. I et avlyttingsoppsett må Squid gjenopprette hvor den omdirigerte forbindelsen opprinnelig var på vei.

En eksplisitt konfigurert nettleser sender forespørslene sine til proxyen med vilje. Den forbindelsen får ikke NAT-avlyttingshistorikk bare fordi intercept står ved siden av porten til Squid-lytteren.

Derfor kan denne uoverensstemmelsen feile før sertifikatet til destinasjonen blir relevant.

Begynn med hvordan forbindelsen ankom

• Hvis applikasjonen har en konfigurert proxyadresse, finn den vanlige videresendende proxylytteren den bør bruke.
• Hvis en gateway omdirigerer trafikk som ellers ville vært direkte, kontroller at den når den tiltenkte avlyttingslytteren og at det støttede NAT-designet bevarer den nødvendige destinasjonsinformasjonen.
• Hvis begge modusene finnes, kontroller hvilken adresse og port den feilende klienten faktisk kontaktet.

Squids dokumentasjon for http_port gjør forskjellen tydelig: å utelate et modusflagg velger videresendende proxymodus; intercept forventer NAT-avlytting på IP-nivå.

Deretter behandler du transportsikkerhet separat. En HTTP-proxy kan bære HTTPS via CONNECT. En TLS-forbindelse til proxyen krever en kompatibel lytter og klientkonfigurasjon. Å dekryptere destinasjonstrafikk er nok en valgfri egenskap.

Ikke kopier en gammel “HTTPS-løsning” som slår på sertifikatgenerering bare fordi destinasjonsadressen begynner med HTTPS. Reparer først samsvaret mellom klienten og lytteren. Hvis det deretter gjenstår en ekte TLS-feil, er det en mer nyttig feil å undersøke.