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

Во клиентскиот дневник се појавува „врската е ресетирана, рестартирање“, и заклучокот доаѓа пред доказот. Некој одлучува дека мрежата го блокира VPN-от, или дека сертификатот е погрешен, или дека одредена земја се меша. Ресетирањето е TCP пакет што завршува врска, а линијата во дневникот забележува дека вашиот клиент добил еден. Таа не го именува уредот што го испратил ниту причината.

Ресетирањето е пакет, не пресуда

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

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

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

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

Прво проверете дали активниот профил навистина користи 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

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