Защо VPN се възстановява по-дълго от прекъсването

Wi-Fi се върна преди тридесет секунди, а VPN все още не работи, така че клиентът изглежда счупен. Често той просто следва собствения си график за повторни опити и този график не знае, че мрежата току-що се е върнала. Тази разлика е цялата история: времето за възстановяване е прекъсването плюс всяко чакане, което клиентът вече е приел. Намаляването на всеки таймер е един отговор, а разбирането кой таймер има значение е другият.

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

Три чакания, които изглеждат като едно

Разрешаването на крайната точка, договарянето на IKE или TLS, повторното предаване на пакети и стартирането на нов опит са отделни събития с отделни таймери. strongSwan документира експоненциалното забавяне при повторно предаване за IKE, а OpenVPN има свои собствени контроли за повторни опити с различна семантика. Копирането на число от едното в другото предполага, че механизмите съвпадат, а те не съвпадат. Прочетете последователността в журнала, преди да решите кой интервал разглеждате.

Тиха минута в журнала не означава непременно замразен процес. Това може да е експоненциално забавяне, което прави точно това, за което е настроено.

Кой етап всъщност е бавен?

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

Класифицирайте повредата, преди да пипате число.

Кога намаляването на таймер помага и кога не

Намалете горната граница за повторни опити, когато доминиращата цена е чакането след кратко и често прекъсване, например лаптоп, който се движи между точки за достъп. Оставете я, когато повредите са дълги или редки, защото агресивните повторни опити добавят натоварване точно в момента, в който концентраторът е най-малко способен да отговори. И в двата случая променете един параметър, запишете го и измерете следващото възстановяване, вместо да предполагате, че се е подобрило.

Много нисък таймаут, копиран във всеки профил, е обичайното крайно състояние на настройка без измерване.

Проверете готовността, преди да обвинявате клиента

Клиентът често не може да види, че мрежата е използваема, докато нещо не опита. Пленен портал, подновяване на DHCP или промяна на маршрут могат да го оставят да чака по график, зададен преди всичко това. Наблюдавайте промяната на мрежовото състояние на операционната система и следващия опит на клиента на един и същ часовник и ще видите чие е чакането. Бързият вариант е да отбележите времевия печат на събитието „мрежата е готова“ и времевия печат на първия опит след него.

Потвърдете също, че директният трафик все още е блокиран по време на чакането, защото по-бързо повторно свързване, което изтича трафик, не е подобрение.

Какво да записвате

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

Този запис превръща следващото надграждане на софтуера в сравнение, а не в експеримент.