Ryšį atnaujino kita pusė per tarpinį serverį: raskite nepavykusį etapą
Naudokite ryšio etapą ir patvirtinančius įrodymus tarpinio serverio atnaujinimui tirti, nelaikydami trumpos operacinės sistemos klaidos žinutės priežasties priskyrimu.
„Connection reset by peer“ nurodo nutrūkusį transporto ryšį. Jis nenurodo, kad priežastis yra interneto tiekėjas, tarpinio serverio operatorius ar svetainė.
| Atnaujinimo laikas | Kur tirti |
|---|---|
| Iškart po TCP prisijungimo | Protokolo nesuderinamumas arba paslauga, atmetanti pradinį mainą |
| Po sėkmingo CONNECT | Nustatytas tunelio kelias |
| Atsakymo metu | Viršutinės grandies uždarymas, tarpininko gyvavimo trukmės politika ir perdavimo kelias |
Tada pakeiskite vieną svarbią sąlygą, palikdami tarpinį serverį ir paskirties vietą nepakeistus. Palyginkite teisingai sukonfigūruotą šifruotą kliento–tarpinio serverio ryšį, kur jis palaikomas, arba tą patį klientą iš kito patvirtinto tinklo. Paklauskite, ar operatorius gali susieti bandymą savo žurnaluose.
Kitas rezultatas susiaurina tyrimą, bet neįrodo vienos priežasties. Srauto nukreipimas per tunelį gali kartu pakeisti laiką, apkrovą, politiką ir tarpines priemones. Vien jo sėkmė negali įrodyti tyčinio blokavimo pradiniame kelyje.
Kur yra leidžiami paketų stebėjimai, palyginkite juos su programos ir tarpinio serverio žurnalais. Net numatomas paketo šaltinio adresas nepaaiškina, kodėl buvo išsiųstas atnaujinimas ar kuri sistema taikė politiką.
Išsaugokite skaitinę klaidą, laiko žymą, galinį tašką ir paskutinį užbaigtą etapą. Naudokite šiuos įrodymus prieš keisdami prisijungimo duomenis ar TLS nustatymus; trumpa atnaujinimo žinutė pati savaime nesuteikia priežasties keisti nė vieno jų.