TCP қайта орнату VPN-ның блокталғанын дәлелдемейді

Клиент журналында «байланыс қайта орнатылды, қайта іске қосылуда» пайда болады, ал қорытынды дәлелден бұрын келеді. Біреу желі VPN-ды блоктайды, немесе сертификат қате, немесе белгілі бір ел араласады деп шешеді. Қайта орнату — байланысты аяқтайтын TCP пакеті, ал журнал жолы клиентіңіздің бір пакет алғанын жазады. Ол оны жіберген құрылғыны да, себебін де атамайды.

Қайта орнату — пакет, үкім емес

TCP қайта орнатуды өңдеуді анықтайды: RST жалаушасы бар сегмент байланысты бірден аяқтайды. Қабылдаушы келіссөз жүргізбейді, қайталап әрекет етпейді және неге деп сұрамайды. Ол қайта орнату туралы хабарлайды да, әрі қарай жалғастырады.

Клиент білетіні осы ғана. RST серверден, проксиден, брандмауэрден немесе күйін жоғалтқан жүктеме теңгерушісінен келген болуы мүмкін.

Бастау көзін анықтау — бөлек жаттығу. Түсірілімде көрінетін бастапқы мекенжай физикалық шығу тегін дәлелдемейді және оның артындағы саясат шешімі туралы ештеңе айтпайды. Аралық құрылғылар мекенжайларды жасампаздай алады, ал күйі бар құрылғылар ниеттен емес, уақыт шегінен қайта орнатуы мүмкін. Қайта орнатуды үкім деп қарау шындықты анықтайтын бөлікті өткізіп жібереді.

Қай байланыс қайта орнатылғанын растаңыз

Алдымен белсенді профильдің шынымен TCP қолданатынын тексеріңіз. UDP туннелінде қайта орнатудың мағынасы жоқ, ал HTTP проксиінің журналы VPN-ның өзінен басқа TCP бөлігіне қатысты болуы мүмкін.

Межелі орынды, портты, әрекет уақытын және клиент жеткен кезеңді жазып алыңыз.

Кезең — ең пайдалы өріс. 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

Пайдалы нәтиже — жақсырақ локализацияланған ақаулық, ал сенімдірек әңгіме емес. Прокси түзетілгеннен кейін қайта орнату жоғалса, себебіңіз бар. Ол басқа кезеңге ауысса, жол туралы бірдеңе білдіңіз. Қалай болғанда да, дәлел екінші адамның оқуына төтеп беруі керек. Не байқағаныңызды жазыңыз, не қорытындылағаныңызды емес.