Скід 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

Карысны вынік — лепш лакалізаваны збой, а не больш упэўненая гісторыя. Калі скід знікае пасля выпраўлення проксі, у вас ёсць прычына. Калі ён пераходзіць на іншы этап, вы даведаліся нешта пра шлях. У любым выпадку доказы павінны вытрымаць чытанне другім чалавекам. Запішыце тое, што вы назіралі, а не тое, што вы заключылі.