Einen Squid-Fehler SO_ORIGINAL_DST lesen

NF getsockopt(SO_ORIGINAL_DST) deutet auf eine Suche nach dem ursprünglichen Ziel hin. In einer Interception-Konfiguration muss Squid rekonstruieren, wohin die umgeleitete Verbindung ursprünglich gehen sollte.

Ein explizit konfigurierter Browser schickt seine Anfragen absichtlich an den Proxy. Diese Verbindung erhält keine NAT-Interception-Historie, nur weil neben dem Port des Squid-Listeners intercept steht.

Diese Unstimmigkeit kann daher fehlschlagen, bevor das Zertifikat des Ziels überhaupt relevant wird.

Beginnen Sie damit, wie die Verbindung ankam

• Wenn die Anwendung eine Proxyadresse konfiguriert hat, ermitteln Sie den gewöhnlichen Forward-Proxy-Listener, den sie verwenden soll.
• Wenn ein Gateway ansonsten direkten Verkehr umleitet, prüfen Sie, ob er den vorgesehenen Interception-Listener erreicht und ob das unterstützte NAT-Design die nötigen Zielinformationen erhält.
• Wenn beide Modi existieren, prüfen Sie, welche Adresse und welchen Port der fehlschlagende Client tatsächlich kontaktiert hat.

Squids Dokumentation zu http_port macht den Unterschied deutlich: Ohne Modus-Flag wird der Forward-Proxy-Modus gewählt; intercept erwartet NAT-Interception auf IP-Ebene.

Behandeln Sie danach die Transportsicherheit getrennt. Ein HTTP-Proxy kann HTTPS über CONNECT übertragen. Eine TLS-Verbindung zum Proxy erfordert einen passenden Listener und eine passende Clientkonfiguration. Das Entschlüsseln des Zielverkehrs ist wieder eine andere optionale Fähigkeit.

Kopieren Sie keinen alten “HTTPS-Fix”, der die Zertifikatserzeugung einschaltet, nur weil die Ziel-URL mit HTTPS beginnt. Reparieren Sie zuerst die Übereinstimmung zwischen Client und Listener. Bleibt danach ein echter TLS-Fehler übrig, ist das ein aussagekräftigerer Fehler zum Untersuchen.