Как читать ошибку SO_ORIGINAL_DST в Squid

NF getsockopt(SO_ORIGINAL_DST) указывает на поиск исходного назначения. В схеме перехвата Squid должен восстановить, куда изначально направлялось перенаправленное соединение.

Явно настроенный браузер намеренно отправляет запросы прокси. Это соединение не получает историю перехвата NAT только потому, что рядом с портом слушателя Squid написано intercept.

Поэтому это несоответствие может проявиться ещё до того, как сертификат назначения станет важен.

Начните с того, как пришло соединение

• Если в приложении настроен адрес прокси, определите обычный слушатель прямого прокси, который оно должно использовать.
• Если шлюз перенаправляет иначе прямой трафик, проверьте, доходит ли он до нужного слушателя перехвата и сохраняет ли поддерживаемая схема NAT требуемые сведения о назначении.
• Если существуют оба режима, проверьте, к какому адресу и порту фактически обращался сбойный клиент.

Документация Squid по http_port прямо различает эти случаи: если флаг режима опущен, выбирается режим прямого прокси; intercept ожидает перехват NAT на уровне IP.

Затем рассмотрите безопасность транспорта отдельно. HTTP-прокси может передавать HTTPS через CONNECT. Соединение TLS к прокси требует совместимого слушателя и настройки клиента. Расшифровка трафика к назначению — ещё одна необязательная возможность.

Не копируйте старое “решение для HTTPS”, которое включает генерацию сертификатов только потому, что адрес назначения начинается с HTTPS. Сначала исправьте согласованность клиента и слушателя. Если после этого останется настоящая ошибка TLS, её будет полезнее исследовать.