’n TCP-reset bewys nie dat jou VPN geblokkeer word nie

Verbinding reset, herbegin verskyn in die kliëntlog, en die gevolgtrekking kom voor die bewyse. Iemand besluit die netwerk blokkeer die VPN, of die sertifikaat is verkeerd, of ’n spesifieke land meng in. ’n Reset is ’n TCP-pakket wat ’n verbinding beëindig, en die logreël teken aan dat jou kliënt een ontvang het. Dit noem nie die toestel wat dit gestuur het of die rede daarvoor nie.

’n Reset is ’n pakket, nie ’n uitspraak nie

TCP definieer resetverwerking: ’n segment met die RST-vlag beëindig die verbinding onmiddellik. Die ontvanger onderhandel nie, probeer nie weer nie en vra nie hoekom nie. Dit rapporteer die reset en gaan voort.

Dit is al wat die kliënt weet. Die RST kon van die bediener, ’n proxy, ’n firewall of ’n lasbalanseerder gekom het wat toestand verloor het.

Toeskrywing is ’n aparte oefening. ’n Oënskynlike bronadres in ’n opname is nie bewys van die fisiese oorsprong nie, en dit sê niks oor die beleidsbesluit daarachter nie. Middelbokse kan adresse vervals, en toestandvolle toestelle kan op tydsverloop reset eerder as uit opset. Om die reset as uitspraak te behandel, slaan die deel oor waar jy uitvind.

Bevestig watter verbinding gereset is

Kontroleer eers dat die aktiewe profiel werklik TCP gebruik. ’n Reset op ’n UDP-tonnel maak geen sin nie, en ’n log van ’n HTTP-proxy kan ’n ander TCP-been betref as die VPN self.

Teken die bestemming, poort, pogingstyd en die fase wat die kliënt bereik het aan.

Die fase is die nuttigste veld. ’n Reset tydens die TLS-handdruk wys op een stel verdagtes; ’n reset ná verifikasie wys op ’n ander. Sonder die fase pas elke teorie.

Vergelyk beide kante van die pad

As jy die bediener administreer, vergelyk sy gebeurtenisse vir dieselfde poging. Het dit die verbinding aanvaar? Het dit dit doelbewus gesluit? Het ’n antwoord een grens verlaat en nooit die volgende bereik nie?

Neem op by die kliënt en by die bediener as jy kan. ’n Reset wat by die kliënt verskyn maar nie by die bediener nie, het nie by die bediener ontstaan nie.

Let op RST-segmente in beide rigtings:

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

Vernou met ’n beheerde vergelyking

’n Tweede goedgekeurde netwerk kan jou sê of die fout die kliënt of die pad volg. As dieselfde profiel elders werk, is die kliëntkonfigurasie waarskynlik reg en is die pad die veranderlike.

Dit identifiseer steeds nie een middelbok nie. Dit vernou die omvang tot ’n roete, wat ’n nuttige en eerlike resultaat is.

Hou die onderskeid tussen hierdie pad faal en hierdie genoemde akteur het dit veroorsaak. Die eerste is toetsbaar; die tweede gewoonlik nie van ’n enkele kliënt nie.

Kontroleer die oplossing sonder om vertrouensinstellings te verander

Moenie TLS-verifikasie deaktiveer, geloofsbriewe hergenereer of ’n blokkeringsbeleid uit een resetreël aankondig nie. Elkeen van daardie veranderinge verander die stelsel onder toets en maak die volgende vergelyking betekenisloos.

Herstel die geïdentifiseerde komponent deur sy eienaar, en herhaal dan dieselfde profiel en dieselfde waarneming:

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

Die nuttige uitkoms is ’n beter gelokaliseerde fout, nie ’n meer selfversekerde verhaal nie. As die reset ná ’n proxy-regstelling verdwyn, het jy ’n oorsaak. As dit na ’n ander fase skuif, het jy iets oor die pad geleer. Hoe dit ook al sy, die bewyse moet ’n tweede persoon se lees kan oorleef. Skryf neer wat jy waargeneem het, nie wat jy afgelei het nie.