Как да четем грешка 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”, което включва генериране на сертификати само защото URL адресът на дестинацията започва с HTTPS. Първо поправете съгласуваността между клиента и слушателя. Ако след това остане истинска TLS грешка, тя ще бъде по-полезна за изследване.