Keepalive није поновно повезивање: изаберите према квару који имате

keepalive и поновно повезивање конфигуришу се у истом даху, али решавају различите проблеме, зато подешавање једног ретко поправља друго. keepalive шаље мали саобраћај да одржи запис стања живим или да примети да је партнер престао да одговара. Поновно повезивање руши оно што је покварено и поново гради везу, укључујући кључеве, адресе и руте. Изаберите механизам који одговара квару, а не онај чије дугме већ знате. Два питања то одлучују: да ли је пут мртав или нешто између партнера заборавља га?

Када је мапирање проблем

Тунел који умире само после неколико минута тишине обично губи запис превода, а не партнера. Опција PersistentKeepalive код WireGuard-а постоји за NAT и стање заштитног зида, а сопствене белешке пројекта описују га управо тако, а не као проверу здравља. Интервал од неколико десетина секунди одржава запис топлим, док је пакет сваке секунде одлука о батерији, а не о поузданости. OpenVPN долази на исто место преко ping и ping-restart , који прво примете тишину и затим делују.

Ове поставке такође нису заменљиве између протокола. Правило мртвог партнера у IKEv2, ping тајмер у OpenVPN-у и keepalive у WireGuard-у одговарају на исто питање трима различитим синтаксама и трима различитим подразумеваним вредностима, зато је копирање броја између њих нагађање обучено као подешавање.

Када везе више нема

Ако партнер промени адресу, овлашћење истекне или се удаљена страна рестартује, мали пакети нису поправка. Поновно повезивање мора да обнови стање : добити адресу, поново инсталирати руте, поново преговарати кључеве и у неким распоређивањима поново аутентификовати корисника.

Клијенти који се поново повезују без надзора држе сертификат или сачувану тајну. Клијент који би питао човека не успева тачно када нико није присутан, а то је сценарио у ком је поновно повезивање имало значаја. То је дизајнерска одлука донета месецима раније, а не поставка коју можете да промените током прекида.

Шта ниједно не доказује

Тунел може бити поново повезан, са кључевима и рутама, док је услуга иза њега угашена, а keepalive може држати мапирање отвореним за сесију чији је сервер нестао пре сати. Оба механизма могу пријавити успех док је оно што вам је заиста важно недоступно.

Зато тест завршава стварним захтевом. Пошаљите нешто кроз тунел после интервала који вам је важан, а затим одвојено изазовите квар за који сте пројектовали: период мировања за случај мапирања, рестарт или промену адресе за случај поновног повезивања.

Блокирање директног саобраћаја је одвојена одлука

Петља поновног повезивања може бити потпуно здрава док апликација тихо користи уобичајену руту, а то је цурење, не квар. Ако је захтев да ништа не излази изван тунела, реците то изричито у конфигурацији клијента и докажите тако што ћете спустити тунел и гледати шта се још повезује. Ниједан механизам не подразумева то понашање и никаква дисциплина понављања га не успоставља.

Забележите који је механизам радио и да ли је после тога нови захтев успео. Та два податка су потребна следећем инжењеру и ниједан није видљив у икони статуса. Линија у дневнику која каже да се клијент поново повезао није исто што и захтев који је функционисао.

Напишите политику, не само број

Ставите пар у једну реченицу: интервал мировања, праг живости, шта покреће обнову , и шта клијент ради док понавља. Без те реченице сваки будући инцидент поново отвара исти спор да ли је keepalive прекратак или је поновно повезивање преспоро.

Белешке WireGuard-а о ограничењима корисно су подсећање да је keepalive заобилазно решење за средње кутије, а не општи дизајн живости. Прочитајте то ограничење пре него што подигнете учесталост као одговор на проблем који не може да реши.