Keepalive не е повторно свързване: изберете според повредата, която имате

Keepalive и повторното свързване се настройват наведнъж, но решават различни проблеми, затова настройката на едното рядко поправя другото. Keepalive изпраща малък трафик, за да поддържа запис в състоянието жив или да забележи, че партньорът е спрял да отговаря. Повторното свързване разрушава счупеното и изгражда връзката отново, включително ключове, адреси и маршрути. Изберете механизма, който отговаря на повредата, а не този, чийто ключ вече познавате. Два въпроса решават това: пътят мъртъв ли е или нещо между страните го забравя?

Когато проблемът е в съответствието

Тунел, който умира само след минути тишина, обикновено губи запис за транслация, а не партньор. При WireGuard PersistentKeepalive съществува за състоянието на NAT и защитната стена, а собствените бележки на проекта го описват точно така, а не като проверка на здравето. Интервал от няколко десетки секунди поддържа записа топъл, докато пакет всяка секунда е решение за батерията, а не за надеждността. OpenVPN стига до същото място чрез ping и ping-restart , които първо забелязват тишината и после действат.

Тези настройки също не са взаимозаменяеми между протоколите. Политиката на IKEv2 за мъртъв партньор, таймерът ping на OpenVPN и keepalive на WireGuard отговарят на един и същ въпрос с три различни синтаксиса и три различни стойности по подразбиране, затова копирането на число между тях е догадка, облечена като настройка.

Когато връзката я няма

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

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

Какво не доказва нито едното

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

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

Блокирането на директния трафик е отделно решение

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

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

Напишете политиката, не само числото

Съберете двойката в едно изречение: интервалът на бездействие, прагът на живост, какво задейства изграждането наново , и какво прави клиентът, докато повтаря. Без това изречение всеки бъдещ инцидент отново отваря същия спор дали keepalive е твърде кратък, или повторното свързване е твърде бавно.

Бележките на WireGuard за ограниченията са полезно напомняне, че keepalive е заобиколно решение за междинни устройства, а не общ дизайн за живост. Прочетете това ограничение, преди да повишите честотата в отговор на проблем, който то не може да реши.