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

Воспоставен сокет по кој не се движи сообраќај е потписот што треба да се бара, а ново барање што враќа статусен код покажува дека патот е жив. Табелата со врски одговара дали нешто уште го пресликува текот, и тоа е делот што клиентот не може да го види. Барањето до разрешувачот ја покрива другата половина од вчитувањето на страница, зашто грешка во името и заглавена врска изгледаат исто во прелистувач. Заедно, тие четири излези одделуваат застарена сесија од скршен тунел.

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