Еще раз про «соединения» WireGuard

Еще раз про «соединения» WireGuard

Очень часто от коллег, да и в материалах в сети можно встретить упоминания о «соединениях», «подключениях» или «переподключениях» относительно WireGuard, что создает неправильное и искаженное восприятие происходящих процессов.

Это сильно мешает пониманию работы протокола, отладке и поиску неисправностей. Поэтому давайте разберемся как работает WireGuard на самом деле.

Протокол изначально разрабатывался с прицелом на простоту и эффективность, поэтому он делает одно дело, но делает его хорошо – а именно устанавливает защищенный туннель между двумя узлами.

Туннель WireGuard относится к туннелям без сохранения состояния (stateless), так же, как и туннели GRE или IP-IP. Это означает, что он не запоминает предыдущего состояния и не имеет никакого представления о состоянии противоположного узла.

Тем более, что в качестве транспорта используется UDP – транспортный протокол без подтверждения доставки.

В момент запуска службы WireGuard читает конфигурационные файлы и создает туннельные интерфейсы, если конфигурация не содержит ошибок, то интерфейс переходит в состояние Активен (UP) вне зависимости от состояние противоположной стороны.

И это произойдет даже в том случае, если противоположный узел выключен или недоступен. Косвенно о работе туннеля можно судить по времени с последнего рукопожатия (handshake), однако это очень и очень косвенный признак.

Например, при блокировках данного протокола у операторов связи рукопожатия могут проходить, но сам трафик в туннеле не ходит, но сам интерфейс будет показывать вам что все отлично и с точки зрения WireGuard это действительно так.

Его задача получить пакет, попадающий под одно из правил криптографической маршрутизации (не путать с маршрутизацией пакетов L3), зашифровать нужным ключом и отправить противоположному узлу (peer).

А дойдет пакет или не дойдет локальный экземпляр WireGuard не волнует, у него все хорошо, он работает. Точно также и с входящими пакетами, если пакет подпадает под правила – расшифровываем, нет – отбрасываем.

Погодите, погодите, а как же «WireGuard-сервер», адрес которого мы указываем в настройках «клиента»?

Мы не даром взяли эти термины в кавычки, на самом деле их использование некорректно. Все узлы WireGuard равнозначны и самодостаточны. Тот узел, который инициирует подключение называется инициатором, тот, который его принимает – ответчиком или респондером.

Один и тот же узел может быть и ответчиком и инициатором одновременно. Но классического соединения в понимании сеанса связи не устанавливается.

Инициатор и ответчик выполняют рукопожатие, формируют общий ключ и забывают друг о друге.

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

Получили ответ хорошо, нет – тоже хорошо. WireGuard это не волнует, эти вопросы должно решать сетевое ПО, которое использует туннель.

А как же опция persistent-keepalive? Но она также никак не связана с «поддержанием» соединения. Ее задача совсем в ином. Если инициатор находится за NAT, то при первом обращении к ответчику в брандмауэре создается установленное соединение (ESTABLISHED) и формируются таблицы трансляции NAT.

Если после этого в туннеле не было активности, то соединение в брандмауэре будет закрыто по истечению таймаута, также будет очищена таблица трансляции и все входящие пакеты от ответчика будут отброшены, также ответчик не сможет инициировать новое рукопожатие.

Внешне это будет выглядеть как отвал пира инициатора со стороны ответчика. При первом же пакете от инициатора к ответчику связь снова будет восстановлена.

Для сохранения состояния брандмауэра и таблиц трансляции WireGuard может отправлять ответчику нулевой пакет через промежуток времени указанный в опции persistent-keepalive.