In TCP-reset bewiist net dat dyn VPN blokkearre wurdt

„Ferbiningsreset, opnij starte“ ferskynt yn it kliïntloch, en de konklúzje komt earder as it bewiis. Ien beslút dat it netwurk it VPN blokkearret, of dat it sertifikaat ferkeard is, of dat in bepaald lân him der mei bemuoit. In reset is in TCP-pakket dat in ferbining beëiniget, en de lochrigel skriuwt op dat dyn kliïnt ien ûntfong. Hy neamt noch it apparaat dat it stjoerd hat, noch de reden.

In reset is in pakket, gjin oardiel

TCP definiearret resetferwurking: in segmint mei de RST-flagge beëiniget de ferbining daliks. De ûntfanger ûnderhannelet net, besiket it net opnij en freget net wêrom. Hy meldt de reset en giet troch.

Dat is alles wat de kliïnt wit. De RST kin fan de tsjinner, in proxy, in firewall of in loadbalancer komme dy't syn tastân ferlern hat.

Tawizing is in aparte oefening. In skynbere boarneadres yn in opname is gjin bewiis fan de fysike oarsprong en seit neat oer it beliedsbeslút dêrefter. Tuskenapparaten kinne adressen ferfalskje, en tastân-hâldende apparaten kinne resetje by time-out ynstee fan mei opset. It reset as oardiel behannelje slacht it part oer dêr't men it útfynt.

Befêstigje hokker ferbining reset is

Kontrolearje earst oft it aktive profyl echt TCP brûkt. In reset op in UDP-tunnel hat gjin sin, en in loch fan in HTTP-proxy kin in oare TCP-skinkel oangean as it VPN sels.

Skriuw de bestimming, de poarte, de tiid fan de poging en de faze dy't de kliïnt berikt hie op.

De faze is it nuttichste fjild. In reset by de TLS-hânskodding wiist op ien set fertochten; in reset nei autentikaasje op in oare. Sûnder de faze past elke teory.

Ferlykje beide kanten fan it paad

As do de tsjinner beheart, ferlykje dan syn barren foar deselde poging. Akseptearre er de ferbining? Sleat er dy mei opset? Ferliet in antwurd ien grins en berikte nea de folgjende?

Meitsje in opname by de kliïnt en by de tsjinner as do kinst. In reset dy't by de kliïnt ferskynt mar net by de tsjinner, is net by de tsjinner ûntstien.

Let op RST-segminten yn beide rjochtingen:

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

Behein mei in kontrolearre ferliking

In twadde goedkard netwurk kin dy fertelle oft de flater de kliïnt of it paad folget. As itselde profyl earne oars wurket, is de kliïntkonfiguraasje wierskynlik goed en is it paad de fariabele.

Dat identifisearret noch gjin ien tuskenapparaat. It beheint it berik ta in rûte, wat in nuttich en earlik resultaat is.

Hâld it ûnderskied tusken dit paad mislearret en dizze neamde akteur feroarsake it. It earste is testber; it twadde meastentiids net fan ien kliïnt.

Kontrolearje de repaasje sûnder fertrouwensynstellings te feroarjen

Skeakelje TLS-ferifikaasje net út, generearje gjin nije oanmeldgegevens en kundigje gjin blokkearbelied oan op grûn fan ien resetrigel. Elk fan dy feroarings feroaret it systeem dat test wurdt en makket de folgjende ferliking sinleas.

Reparearje it identifisearre komponint fia syn eigner, en werhelje dan itselde profyl en deselde waarnimming:

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

It nuttige resultaat is in better pleatste flater, gjin selsbetrouwenferhaal. As de reset ferdwynt nei in proxyrepaasje, hast in oarsaak. As er nei in oare faze ferhúzet, hast wat oer it paad leard. Hoe dan ek, it bewiis moat in twadde persoan syn lêzen oerlibje kinne. Skriuw op wat do waarnommen hast, net wat do konkludearre hast.