Sådan læses en SO_ORIGINAL_DST-fejl i Squid

NF getsockopt(SO_ORIGINAL_DST) peger på et opslag af den oprindelige destination. I en aflytningsopsætning skal Squid genskabe, hvor den omdirigerede forbindelse oprindeligt var på vej hen.

En eksplicit konfigureret browser sender sine anmodninger til proxyen med vilje. Den forbindelse får ikke NAT-aflytningshistorik, blot fordi intercept står ved Squid-lytterens port.

Derfor kan denne uoverensstemmelse fejle, før destinationens certifikat bliver relevant.

Begynd med hvordan forbindelsen ankom

• Hvis programmet har en proxyadresse, skal du finde den almindelige videresendende proxylytter, det bør bruge.
• Hvis en gateway omdirigerer trafik, der ellers er direkte, skal du kontrollere, at den når den tilsigtede aflytningslytter, og at det understøttede NAT-design bevarer de nødvendige destinationsoplysninger.
• Hvis begge tilstande findes, skal du kontrollere, hvilken adresse og port den fejlende klient faktisk kontaktede.

Squids dokumentation for http_port gør forskellen tydelig: udelades et tilstandsflag, vælges videresendende proxy-tilstand; intercept forventer NAT-aflytning på IP-laget.

Behandl derefter transportsikkerhed separat. En HTTP-proxy kan bære HTTPS via CONNECT. En TLS-forbindelse til proxyen kræver en kompatibel lytter og klientkonfiguration. At dekryptere destinationstrafik er endnu en valgfri mulighed.

Kopier ikke en gammel “HTTPS-løsning”, der slår certifikatgenerering til, blot fordi destinations-URL'en begynder med HTTPS. Reparer først overensstemmelsen mellem klienten og lytteren. Hvis der derefter er en egentlig TLS-fejl tilbage, er den mere nyttig at undersøge.