keepalive не е повторно поврзување: изберете според дефектот што го имате

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

Кога мапирањето е проблемот

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

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

Кога врската ја нема

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

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

Што не докажува ниту едното

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

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

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

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

Запишете кој механизам се извршил и дали потоа успеало ново барање. Тие два факти се она што му треба на следниот инженер, а ниту еден не е видлив во иконата за статус. Ред во дневникот што вели дека клиентот се поврзал повторно не е исто што и барање што работело.

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

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

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