Een Squid-fout SO_ORIGINAL_DST lezen
Controleer of een expliciet geconfigureerde client een interceptielistener heeft bereikt voordat u een mislukte zoekactie naar de oorspronkelijke bestemming in Squid onderzoekt.
NF getsockopt(SO_ORIGINAL_DST) wijst op een zoekactie naar de oorspronkelijke bestemming. In een interceptieopstelling moet Squid reconstrueren waar de omgeleide verbinding oorspronkelijk naartoe ging.
Een expliciet geconfigureerde browser stuurt zijn verzoeken bewust naar de proxy. Die verbinding krijgt geen NAT-interceptiegeschiedenis alleen omdat intercept naast de poort van de Squid-listener staat.
Deze mismatch kan dus mislukken voordat het certificaat van de bestemming relevant wordt.
Begin met hoe de verbinding aankwam
- Als de toepassing een proxyadres heeft, bepaal dan welke gewone doorstuurproxylistener hij moet gebruiken.
- Als een gateway anders direct verkeer omleidt, controleer dan of het de bedoelde interceptielistener bereikt en of het ondersteunde NAT-ontwerp de vereiste bestemmingsinformatie bewaart.
- Als beide modi bestaan, controleer dan welk adres en welke poort de falende client werkelijk heeft benaderd.
De documentatie van Squid over http_port maakt het onderscheid duidelijk: een modusvlag weglaten kiest de doorstuurproxymodus; intercept verwacht NAT-interceptie op IP-niveau.
Behandel daarna transportbeveiliging apart. Een HTTP-proxy kan HTTPS via CONNECT vervoeren. Een TLS-verbinding naar de proxy vereist een compatibele listener en clientconfiguratie. Bestemmingsverkeer ontsleutelen is weer een andere optionele mogelijkheid.
Kopieer geen oude “HTTPS-oplossing” die certificaatgeneratie aanzet alleen omdat de bestemmings-URL met HTTPS begint. Repareer eerst de afstemming tussen de client en de listener. Blijft daarna een echte TLS-fout over, dan is dat een nuttiger fout om te onderzoeken.