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

Установен сокет без движещ се трафик е отличителният белег, който търсите, а нова заявка, която връща код за състояние, показва, че пътят е жив. Таблицата на връзките отговаря дали нещо още свързва потока, а това е частта, която клиентът не вижда. Заявката към резолвера покрива другата половина от зареждането на страница, защото отказ на име и застояла връзка изглеждат еднакво в браузъра. Заедно тези четири изхода отделят застояла сесия от счупен тунел.

Запишете времето на прекъсване, времето на повторно свързване и разликата между старата и новата заявка. Този запис превръща неясно оплакване в доклад, с който някой може да работи.