Скидання 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

Корисний результат — точніше локалізований збій, а не впевненіша історія. Якщо скидання зникає після виправлення проксі, у вас є причина. Якщо воно переходить на інший етап, ви дізналися щось про шлях. У будь-якому разі доказ має витримати читання другою людиною. Записуйте те, що ви спостерігали, а не те, що ви зробили висновок.