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

Встановлений сокет без руху трафіку — це ознака, яку треба шукати, а новий запит, що повертає код стану, показує, що шлях живий. Таблиця з’єднань відповідає, чи щось ще відображає потік, і це та частина, яку клієнт не бачить. Запит до розв’язувача покриває другу половину завантаження сторінки, бо збій імені та зависле з’єднання в браузері виглядають однаково. Разом ці чотири виводи відокремлюють застарілий сеанс від зламаного тунелю.

Запишіть час переривання, час перепідключення та різницю між старим і новим запитом. Цей запис перетворює неясну скаргу на звіт, з яким хтось може працювати.