Ресет TCP не доказује да је ваш VPN блокиран

У дневнику клијента појављује се „веза ресетована, поново покрећем“, а закључак стиже пре доказа. Неко одлучи да мрежа блокира VPN, или да је сертификат погрешан, или да се одређена земља меша. Ресет је TCP пакет који завршава везу, а линија дневника бележи да је ваш клијент примио један. Она не именује уређај који га је послао ни разлог.

Ресет је пакет, а не пресуда

TCP дефинише обраду ресета: сегмент са заставицом RST одмах завршава везу. Прималац не преговара, не покушава поново и не пита зашто. Он пријављује ресет и наставља.

То је све што клијент зна. RST је могао доћи са сервера, проксија, заштитног зида или балансера оптерећења који је изгубио стање.

Утврђивање порекла је посебна вежба. Привидна изворна адреса у снимку није доказ физичког порекла и ништа не говори о одлуци политике иза ње. Посредни уређаји могу да фалсификују адресе, а уређаји са стањем могу да ресетују због истека времена, а не намерно. Ако ресет третирате као пресуду, прескачете део у коме се открива истина.

Потврдите која је веза ресетована

Прво проверите да ли активни профил заиста користи TCP. Ресет на UDP тунелу нема смисла, а дневник HTTP проксија може да се односи на други TCP део од самог VPN-а.

Забележите одредиште, порт, време покушаја и фазу до које је клијент стигао.

Фаза је најкорисније поље. Ресет током TLS руковања указује на једну групу осумњичених; ресет после аутентификације на другу. Без фазе, свака теорија се уклапа.

Упоредите оба краја пута

Ако администрирате сервер, упоредите његове догађаје за исти покушај. Да ли је прихватио везу? Да ли ју је намерно затворио? Да ли је одговор напустио једну границу и никада није стигао до следеће?

Снимите саобраћај на клијенту и на серверу ако можете. Ресет који се види на клијенту, али не на серверу, није настао на серверу.

Обратите пажњу на RST сегменте у оба смера:

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

Сузите контролисаним поређењем

Друга одобрена мрежа може да вам каже да ли квар прати клијента или пут. Ако исти профил ради другде, конфигурација клијента је вероватно у реду, а променљива је пут.

То још увек не идентификује један конкретан посредни уређај. Сужава обим на руту, што је користан и искрен резултат.

Задржите разлику између „овај пут не успева“ и „овај именовани актер је то изазвао“. Прво је проверљиво; друго обично није са једног клијента.

Проверите исправку без промене подешавања поверења

Не искључујте TLS проверу, не генеришите поново акредитиве и не објављујте политику блокирања на основу једне линије ресета. Свака од тих промена мења систем који се тестира и чини следеће поређење бесмисленим.

Исправите идентификовану компоненту преко њеног власника, затим поновите исти профил и исто посматрање:

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

Користан резултат је боље локализован квар, а не сигурнија прича. Ако ресет нестане после исправке проксија, имате узрок. Ако се премести у другу фазу, научили сте нешто о путу. У сваком случају, доказ треба да издржи читање другог човека. Запишите шта сте посматрали, а не шта сте закључили.