Читање на грешката 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 грешка, таа ќе биде покорисна за истражување.