Чаму VPN аднаўляецца даўжэй, чым доўжыцца збой

Wi-Fi вярнуўся трыццаць секунд таму, а VPN усё яшчэ не працуе, таму кліент выглядае зламаным. Часта ён проста ідзе па сваім уласным графіку паўтораў, і гэты графік не ведае, што сетка толькі што вярнулася. Менавіта гэты разрыў і ёсць сутнасцю: час аднаўлення — гэта збой плюс любое чаканне, на якое кліент ужо пагадзіўся. Знізіць кожны таймер — адзін адказ, а зразумець, які таймер важны, — другі.

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

Тры чаканні, якія выглядаюць як адно

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

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

Які этап на самой справе павольны?

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

Класіфікуйце збой, перш чым чапаць лік.

Калі зніжэнне таймера дапамагае, а калі не

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

Вельмі нізкі тайм-аўт, скапіяваны ў кожны профіль, — звычайны канчатковы стан наладкі без вымярэнняў.

Праверце гатоўнасць, перш чым вінаваціць кліент

Кліент часта не можа ўбачыць, што сетка прыдатная да ўжывання, пакуль нешта не паспрабуе. Захоплены партал, абнаўленне DHCP або змена маршруту могуць пакінуць яго чакаць па графіку, устаноўленаму да ўсяго гэтага. Назірайце за змяненнем сеткавага стану аперацыйнай сістэмы і наступнай спробай кліента на адным гадзінніку, і вы ўбачыце, чыё гэта чаканне. Хуткі варыянт — запісаць адзнаку часу падзеі «сетка гатовая» і адзнаку часу першай спробы пасля яе.

Пераканайцеся таксама, што прамы трафік падчас чакання ўсё яшчэ блакуецца, бо хутчэйшае перападлучэнне, якое ўтачвае трафік, не з'яўляецца паляпшэннем.

Што запісваць

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

Гэты запіс ператварае наступнае абнаўленне праграмнага забеспячэння ў параўнанне, а не ў эксперымент.