Чытанне памылкі Squid 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, гэта будзе больш карысная памылка для разбору.