TCP reset ei tõesta, et sinu VPN on blokeeritud

Kliendi logisse ilmub „ühendus lähtestati, taaskäivitan“ ja järeldus jõuab enne tõendit. Keegi otsustab, et võrk blokeerib VPN-i, või et sertifikaat on vale, või et teatud riik sekkub. Reset on TCP-pakett, mis lõpetab ühenduse, ja logirida märgib, et sinu klient sai ühe. See ei nimeta saatnud seadet ega saatmise põhjust.

Reset on pakett, mitte otsus

TCP määratleb reseti töötlemise: RST-lipuga segment lõpetab ühenduse kohe. Vastuvõtja ei läbiräägi, ei proovi uuesti ega küsi, miks. Ta teatab resetist ja liigub edasi.

See on kõik, mida klient teab. RST võis tulla serverilt, puhverserverilt, tulemüürilt või koormusjaoturilt, mis kaotas oleku.

Päritolu tuvastamine on eraldi harjutus. Näiline lähteaadress salvestises ei tõesta füüsilist päritolu ega ütle midagi selle taga oleva poliitikaotsuse kohta. Vaheseadmed võivad aadresse võltsida ja olekut säilitavad seadmed võivad lähtestada aegumise, mitte kavatsuse tõttu. Reseti otsusena käsitlemine jätab vahele osa, kus see välja selgitatakse.

Kinnita, milline ühendus lähtestati

Kõigepealt kontrolli, kas aktiivne profiil kasutab tõesti TCP-d. Reset UDP-tunnelil ei ole mõttekas ja HTTP-puhverserveri logi võib puudutada teist TCP-osa kui VPN ise.

Kirjuta üles sihtkoht, port, katse aeg ja etapp, milleni klient jõudis.

Etapp on kõige kasulikum väli. Reset TLS-kätlemise ajal osutab ühele kahtlusaluste hulgale; reset pärast autentimist teisele. Ilma etapita sobib iga teooria.

Võrdle tee mõlemat otsa

Kui haldad serverit, võrdle selle sündmusi sama katse jaoks. Kas see võttis ühenduse vastu? Kas see sulges selle meelega? Kas vastus lahkus ühest piirist ega jõudnud kunagi järgmisesse?

Salvesta kliendi ja serveri juures, kui saad. Reset, mis ilmub kliendi juures, kuid mitte serveri juures, ei tekkinud serveris.

Jälgi RST-segmente mõlemas suunas:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

Ahenda kontrollitud võrdlusega

Teine heakskiidetud võrk võib öelda, kas tõrge järgib klienti või teed. Kui sama profiil töötab mujal, on kliendi konfiguratsioon tõenäoliselt korras ja muutuja on tee.

See ei tuvasta ikka üht konkreetset vaheseadet. See kitsendab ulatuse marsruudini, mis on kasulik ja aus tulemus.

Hoia alles vahe selle vahel, et see tee ei tööta, ja selle vahel, et see nimetatud osaleja põhjustas selle. Esimest saab testida; teist tavaliselt ühest kliendist mitte.

Kontrolli parandust usaldusseadeid muutmata

Ära lülita TLS-i kontrolli välja, ära genereeri mandaate uuesti ega kuuluta blokeerimispoliitikat ühe reset-rea põhjal. Iga selline muudatus muudab testitavat süsteemi ja teeb järgmise võrdluse mõttetuks.

Paranda tuvastatud komponent selle omaniku kaudu ja korda seejärel sama profiili ja sama vaatlust:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

Kasulik tulemus on paremini lokaliseeritud tõrge, mitte enesekindlam lugu. Kui reset kaob puhverserveri parandamise järel, on sul põhjus. Kui see liigub teise etappi, oled tee kohta midagi õppinud. Igal juhul peaks tõend vastu pidama teise inimese lugemisele. Kirjuta üles, mida sa vaatlesid, mitte mida sa järeldasid.