VPN зноў падключаны, але сесія праграмы ўсё роўна не працуе

Тунэль вяртаецца, кліент паведамляе пра злучэнне, а браўзер усё яшчэ круціцца на старонцы, якую загружаў да абрыву. Паўторнае падключэнне VPN аднаўляе шлях і не аднаўляе стан злучэння, які праграмы і далёкі бок назапасілі на старым шляху. Гэта розныя рэчы для рамонту, і блытаніна паміж імі вяртае вас у налады VPN без прычыны.

Адзін тэст чыста іх раздзяляе, і займае ён дзесяць секунд. Даслаце новы запыт на той жа адрас, пакуль стары вісіць.

Што перажывае перападключэнне, а што не

Тунэль — гэта набор маршрутаў, ключоў і адрасоў, і перападключэнне можа аднавіць усе тры, пакуль кожны ўсталяваны паток застаецца мёртвым. Аперацыйная сістэма трымае сокет адкрытым, бо праграма папрасіла пра гэта, і тайм-аўт гэтага сокета можа быць за некалькі хвілін або гадзін. Пад гэтым партнёр забыўся пра паток, запіс трансляцыі скончыўся, або шлях цяпер ідзе праз кропку, якая ніколі не бачыла рукапаціскання. Нішто ў паслядоўнасці перападключэння не праходзіць па сокетах праграмы і не рамантуе іх.

Некаторыя кліенты дадаюць хук, які скідвае састарэлыя злучэнні пры перападключэнні, а большасць — не. Паводзіны тут залежаць ад кліента, платформы і версіі.

Далёкі бок таксама вас забыў

Далёкі канец трымае ўласны стан: сесію TLS, блок кіравання TCP і, магчыма, запіс адлюстравання, які звязвае ваш адрас і порт з патокам. Прылада трансляцыі на шляху можа скончыць тэрмін гэтага адлюстравання за час разрыву, нават калі тунэль аднаўляецца хутка. Як толькі адлюстраванне знікае, пакеты прыходзяць для патоку, якога сервер ужо не пазнае, і адказам можа быць скід, якога кліент ніколі не пакажа. Праграмы паведамляюць пра гэта як пра прыпынак, а не як пра памылку, бо яны ўсё яшчэ чакаюць сокет, які ніколі не адкажа.

Тайм-аўты прастою на баку сервера робяць тое ж па сваім раскладзе, таму сесія можа памерці зусім без сеткавай падзеі. Злучэнне, якое прастаяла даўжэй, чым чакае сервер, ужо знікла, перш чым вы заўважыце рух тунэля.

Новы запыт — гэта тэст, які іх раздзяляе

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

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

Пацвердзіце новым злучэннем, а не старым

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

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

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

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