TCP-reset ei todista, että VPN:ääsi estetään

Asiakaslokiin ilmestyy „yhteys nollattu, käynnistetään uudelleen“, ja johtopäätös saapuu ennen todistetta. Joku päättää, että verkko estää VPN:n, tai että varmenne on väärä, tai että tietty maa puuttuu asiaan. Reset on TCP-paketti, joka päättää yhteyden, ja lokirivi kirjaa, että asiakkaasi vastaanotti sellaisen. Se ei nimeä lähettänyttä laitetta eikä syytä.

Reset on paketti, ei tuomio

TCP määrittelee resetin käsittelyn: RST-lipulla varustettu segmentti päättää yhteyden heti. Vastaanottaja ei neuvottele, ei yritä uudelleen eikä kysy miksi. Se ilmoittaa resetistä ja jatkaa.

Sen verran asiakas tietää. RST on voinut tulla palvelimelta, välityspalvelimelta, palomuurilta tai kuormantasaimelta, joka menetti tilansa.

Alkuperän selvittäminen on erillinen harjoitus. Näennäinen lähdeosoite kaappauksessa ei todista fyysistä alkuperää eikä kerro mitään sen takana olevasta politiikkapäätöksestä. Välilaitteet voivat väärentää osoitteita, ja tilalliset laitteet voivat nollata yhteyden aikakatkaisun eikä aikomuksen vuoksi. Resetin kohteleminen tuomiona ohittaa sen osan, jossa asia selvitetään.

Vahvista, mikä yhteys nollattiin

Tarkista ensin, käyttääkö aktiivinen profiili todella TCP:tä. Reset UDP-tunnelissa ei ole järkevä, ja HTTP-välityspalvelimen loki voi koskea eri TCP-osuutta kuin VPN itse.

Kirjaa kohde, portti, yrityksen ajankohta ja vaihe, johon asiakas oli päässyt.

Vaihe on hyödyllisin kenttä. Reset TLS-kättelyn aikana osoittaa yhteen epäiltyjen joukkoon; reset todennuksen jälkeen toiseen. Ilman vaihetta mikä tahansa teoria sopii.

Vertaa polun molempia päitä

Jos ylläpidät palvelinta, vertaa sen tapahtumia samasta yrityksestä. Hyväksyikö se yhteyden? Sulkeeko se sen tarkoituksella? Lähtikö vastaus yhdeltä rajalta eikä koskaan saapunut seuraavalle?

Kaappaa asiakkaalla ja palvelimella, jos voit. Reset, joka näkyy asiakkaalla mutta ei palvelimella, ei syntynyt palvelimella.

Tarkkaile RST-segmenttejä molempiin suuntiin:

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

Rajaa kontrolloidulla vertailulla

Toinen hyväksytty verkko voi kertoa, seuraako vika asiakasta vai polkua. Jos sama profiili toimii muualla, asiakkaan kokoonpano on luultavasti kunnossa ja muuttuja on polku.

Se ei silti tunnista yhtä välilaitetta. Se rajaa laajuuden reitiksi, mikä on hyödyllinen ja rehellinen tulos.

Säilytä ero sen välillä, että tämä polku epäonnistuu, ja sen välillä, että tämä nimetty toimija aiheutti sen. Ensimmäinen on testattavissa; toinen yleensä ei yhdestä asiakkaasta.

Tarkista korjaus muuttamatta luottamusasetuksia

Älä poista TLS-vahvistusta käytöstä, älä luo tunnuksia uudelleen äläkä julista estopolitiikkaa yhden reset-rivin perusteella. Jokainen noista muutoksista muuttaa testattavaa järjestelmää ja tekee seuraavasta vertailusta merkityksettömän.

Korjaa tunnistettu komponentti sen omistajan kautta ja toista sitten sama profiili ja sama havainto:

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

Hyödyllinen lopputulos on paremmin paikannettu vika, ei itsevarmempi tarina. Jos reset katoaa välityspalvelimen korjauksen jälkeen, sinulla on syy. Jos se siirtyy toiseen vaiheeseen, olet oppinut jotain polusta. Kummassakin tapauksessa todisteen pitäisi kestää toisen ihmisen luenta. Kirjoita muistiin, mitä havaitsit, älä sitä, mitä päättelit.