Як читати помилку 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, її буде корисніше досліджувати.