Leggere un errore SO_ORIGINAL_DST di Squid
Verificate se un client configurato esplicitamente ha raggiunto un listener di intercettazione prima di diagnosticare un errore nella ricerca della destinazione originale in Squid.
NF getsockopt(SO_ORIGINAL_DST) indica una ricerca della destinazione originale. In una configurazione di intercettazione, Squid deve risalire a dove era diretta originariamente la connessione reindirizzata.
Un browser configurato esplicitamente invia le proprie richieste al proxy di proposito. Quella connessione non acquisisce una cronologia di intercettazione NAT solo perché accanto alla porta del listener Squid compare intercept.
Questo disallineamento può quindi fallire prima che il certificato della destinazione diventi rilevante.
Partite da come è arrivata la connessione
- Se l'applicazione ha un indirizzo proxy configurato, individuate il normale listener proxy di inoltro che dovrebbe usare.
- Se un gateway reindirizza traffico altrimenti diretto, verificate che raggiunga il listener di intercettazione previsto e che la configurazione NAT supportata conservi le informazioni di destinazione necessarie.
- Se esistono entrambe le modalità, verificate quale indirizzo e quale porta il client che fallisce ha realmente contattato.
La documentazione http_port di Squid rende esplicita la distinzione: omettere un flag di modalità seleziona la modalità proxy di inoltro; intercept prevede l'intercettazione NAT a livello IP.
Poi trattate la sicurezza del trasporto separatamente. Un proxy HTTP può trasportare HTTPS tramite CONNECT. Una connessione TLS verso il proxy richiede un listener e una configurazione client compatibili. Decifrare il traffico verso la destinazione è ancora un'altra capacità opzionale.
Non copiate una vecchia “soluzione HTTPS” che attiva la generazione di certificati solo perché l'URL di destinazione inizia con HTTPS. Riparate prima l'accordo tra client e listener. Se poi resta un vero errore TLS, sarà un errore più utile da indagare.