Сброс 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

Полезный результат — более точно локализованный сбой, а не более уверенная история. Если сброс исчезает после исправления прокси, у вас есть причина. Если он переходит на другой этап, вы узнали что-то о пути. В любом случае доказательство должно выдержать чтение вторым человеком. Записывайте то, что вы наблюдали, а не то, что вы заключили.