Нулирането на 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

Полезният резултат е по-добре локализиран отказ, а не по-уверена история. Ако нулирането изчезне след поправка на прокси, имате причина. Ако се премести на друг етап, научихте нещо за пътя. Във всеки случай доказателството трябва да издържи на прочит от втори човек. Записвайте какво сте наблюдавали, а не какво сте заключили.