TCP reset batek ez du frogatzen zure VPN-a blokeatuta dagoenik

«Konexioa berrezarri da, berrabiarazten» agertzen da bezeroaren erregistroan, eta ondorioa froga baino lehenago iristen da. Norbait erabakitzen du sareak VPN-a blokeatzen duela, edo ziurtagiria oker dagoela, edo herrialde jakin batek esku hartzen duela. Reset bat konexio bat amaitzen duen TCP pakete bat da, eta erregistroko lerroak zure bezeroak bat jaso duela jasotzen du. Ez du bidali zuen gailua ezta arrazoia ere izendatzen.

Reset bat paketea da, ez epaia

TCPk resetaren prozesamendua definitzen du: RST bandera duen segmentu batek konexioa berehala amaitzen du. Hartzaileak ez du negoziatzen, ez du berriro saiatzen eta ez du zergatik galdetzen. Resetaren berri ematen du eta aurrera jarraitzen du.

Hori da bezeroak dakien guztia. RST zerbitzaritik, proxy batetik, suebaki batetik edo egoera galdu duen karga-balantzagailu batetik etor zitekeen.

Jatorriaren egozpena ariketa bereizia da. Kaptura batean ageri den iturri-helbide itxurazkoa ez da jatorri fisikoaren froga, eta ez du ezer esaten haren atzeko politika-erabakiari buruz. Tarteko gailuek helbideak faltsutu ditzakete, eta egoera duten gailuek denbora-mugagatik egin dezakete reset, asmoagatik beharrean. Reset-a epai gisa hartzeak informazioa lortzen den zatia saltatzen du.

Egiaztatu zein konexio berrezarri zen

Lehenik egiaztatu profil aktiboak TCP erabiltzen duela benetan. UDP tunel batean reset bat egiteak ez du zentzurik, eta HTTP proxy baten erregistroa VPN-arena ez den beste TCP hanka bati buruzkoa izan daiteke.

Erregistratu helmuga, ataka, saiakeraren ordua eta bezeroak lortutako etapa.

Etapa da eremurik erabilgarriena. TLS eskuko tratuak egitean reset batek susmagarri multzo bat seinalatzen du; autentifikazioaren ondorengo reset batek beste bat. Etaparik gabe, teoria guztiak egokitzen dira.

Alderatu bidearen bi muturrak

Zerbitzaria administratzen baduzu, alderatu haren gertaerak saiakera bererako. Konexioa onartu zuen? Nahita itxi zuen? Erantzun batek muga bat utzi eta ez zuen hurrengora iritsi?

Hartu kaptura bezeroan eta zerbitzarian ahal baduzu. Bezeroan ageri den baina zerbitzarian ageri ez den reset bat ez zen zerbitzaritik sortu.

Begiratu RST segmentuak bi noranzkoetan:

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

Mugatu alderaketa kontrolatu batekin

Onartutako bigarren sare batek esan diezazuke hutsegiteak bezeroari edo bideari jarraitzen dion. Profil berak beste leku batean funtzionatzen badu, bezeroaren konfigurazioa ziurrenik ondo dago eta aldagaia bidea da.

Horrek oraindik ez du tarteko gailu zehatz bat identifikatzen. Esparrua ibilbide batera mugatzen du, eta hori emaitza erabilgarria eta zintzoa da.

Mantendu «bide honek huts egiten du» eta «aktore izendatu honek eragin zuen» arteko bereizketa. Lehena probagarria da; bigarrena normalean ez, bezero bakar batetik.

Egiaztatu konponbidea konfiantza-ezarpenak aldatu gabe

Ez desgaitu TLS egiaztapena, ez sortu berriro kredentzialak eta ez iragarri blokeo-politikarik reset lerro bakar batetik abiatuta. Aldaketa horietako bakoitzak probatzen ari zaren sistema aldatzen du eta hurrengo alderaketa zentzugabe bihurtzen du.

Konpondu identifikatutako osagaia bere jabearen bidez, eta gero errepikatu profil bera eta behaketa bera:

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

Emaitza erabilgarria gaizki kokaturiko hutsegite hobea da, ez istorio ziurragoa. Reset-a proxyaren konponketaren ondoren desagertzen bada, kausa bat duzu. Beste etapa batera mugitzen bada, bideari buruz zerbait ikasi duzu. Edonola ere, frogak bigarren pertsona baten irakurketa gainditu beharko luke. Idatzi zer behatu duzun, ez zer ondorioztatu duzun.