Скід злучэння з боку партнёра праз проксі: знайдзіце этап, што не ўдаўся
Выкарыстоўвайце этап злучэння і пацвярджальныя доказы, каб даследаваць скід проксі, не прымаючы кароткае паведамленне пра памылку аперацыйнай сістэмы за ўказанне прычыны.
«Connection reset by peer» паведамляе пра разарванае транспартнае злучэнне. Яно не ўказвае, што прычынай стаў інтэрнэт-правайдар, аператар проксі або вэб-сайт.
| Час скіду | Дзе даследаваць |
|---|---|
| Адразу пасля ўсталявання TCP | Нясупадзенне пратаколу або служба, якая адхіляе пачатковы абмен |
| Пасля паспяховага CONNECT | Усталяваны шлях тунеля |
| Падчас адказу | Закрыццё вышэйшага боку, палітыка часу жыцця пасярэдніка і шлях перадачы |
Затым змяніце адну значную ўмову, пакідаючы проксі і прызначэнне нязменнымі. Параўнайце правільна наладжанае шыфраванае злучэнне кліент–проксі, дзе гэта падтрымліваецца, або таго ж кліента з іншай дазволенай сеткі. Спытайцеся, ці можа аператар суаднесці спробу ў сваіх журналах.
Іншы вынік звужвае даследаванне, але не даказвае адной прычыны. Перадача трафіку праз тунель можа адначасова змяніць час, нагрузку, палітыку і прамежкавыя прылады. Сам па сабе поспех не можа даказаць наўмыснае блакаванне на зыходным шляху.
Там, дзе ёсць дазволеныя назіранні за пакетамі, параўнайце іх з журналамі праграмы і проксі. Нават чаканы адрас крыніцы пакета не тлумачыць, чаму быў адпраўлены скід або якая сістэма ўжыла палітыку.
Захавайце лікавую памылку, адзнаку часу, канчатковы пункт і апошні завершаны этап. Выкарыстоўвайце гэтыя доказы перад зменай уліковых даных або налад TLS; кароткае паведамленне пра скід само па сабе не дае падстаў змяняць ні тое, ні іншае.