Анализ работы WireGuard в MikroTik RouterOS

Фундаментальные принципы WireGuard в экосистеме RouterOS

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

1.1 Виртуальный интерфейс WireGuard: Нативный компонент ядра

Философия дизайна WireGuard основана на простоте, представляя VPN как стандартный виртуальный сетевой интерфейс (например, wg0). MikroTik полностью следует этому подходу, интегрируя WireGuard непосредственно в RouterOS (начиная с версии 7) как отдельный тип интерфейса, управляемый через меню

/interface wireguard

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

При создании нового интерфейса WireGuard в RouterOS автоматически генерируется пара криптографических ключей. Параметр private-key хранится в секрете на маршрутизаторе, в то время как доступный только для чтения public-key служит идентификатором маршрутизатора для его пиров. Этот процесс отражает простоту обмена ключами SSH, что является одной из основных целей дизайна WireGuard. Такой подход по умолчанию способствует соблюдению лучших практик безопасности: каждый интерфейс получает уникальную и надежную идентификацию с момента создания. Это избавляет администратора от необходимости использовать внешние утилиты, такие как wg genkey, для генерации ключей самого маршрутизатора.

Ключевые параметры интерфейса включают:

• listen-port: UDP-порт, на котором интерфейс прослушивает входящие рукопожатия и пакеты данных. В RouterOS по умолчанию используется порт 13231 , однако можно использовать любой другой свободный UDP-порт.

• mtu: Максимальный размер передаваемого блока (Maximum Transmission Unit) для туннеля. RouterOS устанавливает значение по умолчанию 1420 байт. Это консервативное значение, учитывающее служебные заголовки WireGuard и нижележащих протоколов IPv4/IPv6, что помогает предотвратить фрагментацию пакетов.

• private-key / public-key: Фундаментальная пара ключей на основе эллиптической кривой Curve25519, которая определяет криптографическую идентичность интерфейса.

1.2 Рукопожатие и жизненный цикл сессии: Установление безопасной связи

Процесс установления соединения в WireGuard не является постоянным и состоянием, как в TCP. Вместо этого WireGuard использует транспортный протокол UDP без установления соединения. Безопасная сессия устанавливается с помощью рукопожатия, требующего всего одного приема-передачи (1-RTT), основанного на шаблоне Noise_IK из фреймворка Noise Protocol. Процесс включает отправку сообщения "инициатором" и получение ответа от "ответчика", после чего может начаться передача зашифрованных данных.

Процесс обмена ключами выглядит следующим образом:

1. Инициация: Инициатор отправляет свой эфемерный (временный) публичный ключ в открытом виде, а свой статический публичный ключ — в зашифрованном. Для шифрования используется ключ, полученный в результате обмена по протоколу Диффи-Хеллмана между эфемерным приватным ключом инициатора и статическим публичным ключом ответчика.

2. Ответ: Ответчик выполняет обратные вычисления и отправляет в ответ свой эфемерный публичный ключ, завершая обмен.

3. Сессионные ключи: После успешного рукопожатия обе стороны могут сгенерировать пару симметричных сессионных ключей (один для отправки, другой для получения) с помощью функции деривации ключей на основе HMAC (HKDF). Эти ключи используются для высокоскоростного аутентифицированного шифрования всех последующих пакетов данных с помощью алгоритма ChaCha20Poly1305.

Рукопожатие не является однократным событием. Оно периодически повторяется (каждые несколько минут) на основе таймерной машины состояний. Этот процесс смены ключей обеспечивает совершенную прямую секретность (Perfect Forward Secrecy, PFS): даже если сессионный ключ будет скомпрометирован, его нельзя будет использовать для расшифровки прошлого или будущего трафика, так как для каждого нового рукопожатия используются новые эфемерные ключи.

Эта архитектура определяет "включил и забыл" природу интерфейса WireGuard. В отличие от старых VPN, требующих активного управления соединениями, протокол WireGuard самостоятельно обрабатывает все аспекты подключения, роуминга и смены ключей без ручного вмешательства. Флаг running в свойствах интерфейса лишь указывает на то, что он административно включен, и не отражает статус сессии с конкретным пиром. Основным диагностическим инструментом для проверки успешной связи с пиром становится свойство last-handshake.

Роль persistent-keepalive в RouterOS

Этот параметр, настраиваемый для каждого пира, указывает клиенту отправлять небольшой аутентифицированный пустой пакет через регулярные интервалы (например, 25 секунд). Его основная функция — поддерживать активной UDP-сессию в NAT-устройствах и межсетевых экранах с отслеживанием состояний, предотвращая ее завершение из-за неактивности. Это критически важно для клиентов, находящихся за NAT и которым необходимо оставаться доступными для сервера.

Параметр RouterOS	Параметр wg-quick.conf	Тип данных / Формат	Примечания к реализации в RouterOS
name	Имя интерфейса (например, wg0)	Строка	Имя виртуального интерфейса в RouterOS.
private-key	PrivateKey	Строка Base64	Приватный ключ интерфейса.
listen-port	ListenPort	Целое число (1-65535)	UDP-порт для прослушивания.
allowed-address	AllowedIPs	IP-префикс (CIDR)	Определяет внутреннюю маршрутизацию WG и ACL. Не создает маршруты в главной таблице маршрутизации RouterOS.
endpoint-address	Endpoint	IP-адрес или доменное имя	Внешний IP-адрес пира.
endpoint-port	Endpoint (часть)	Целое число (1-65535)	Внешний UDP-порт пира.
persistent-keepalive	PersistentKeepalive	Целое число (секунды)	Интервал отправки keep-alive пакетов для поддержания NAT-сессий.

Криптоключевая маршрутизация и движок маршрутизации RouterOS

В этом разделе проводится глубокий анализ ключевой инновации WireGuard — криптоключевой маршрутизации — и, что наиболее важно, рассматривается ее специфическое и часто неверно понимаемое взаимодействие с основной таблицей маршрутизации RouterOS. Будет показано, что RouterOS поддерживает строгое разделение между внутренней логикой маршрутизации WireGuard и глобальными решениями о маршрутизации устройства.

2.1 Двойственность allowed-address: Таблица маршрутизации и список контроля доступа

Параметр allowed-address в конфигурации пира является сердцем криптоключевой маршрутизации. Он создает статическую, криптографически защищенную карту между публичным ключом пира и IP-адресами, которые этот пир уполномочен использовать. Этот параметр выполняет две различные функции в зависимости от направления трафика :

1. Для исходящих пакетов (Таблица маршрутизации): Когда основная таблица маршрутизации RouterOS направляет пакет на интерфейс WireGuard, этот интерфейс обращается к своему списку пиров. Он проверяет IP-адрес назначения пакета и сопоставляет его с диапазонами allowed-address всех настроенных пиров. Пакет шифруется с использованием публичного ключа того пира, у которого найден наиболее специфичный совпадающий маршрут, и отправляется на endpoint-address этого пира.

2. Для входящих пакетов (Список контроля доступа): Когда зашифрованный пакет поступает на listen-port, он расшифровывается и аутентифицируется. Затем интерфейс проверяет IP-адрес источника расшифрованного пакета. Пакет допускается к дальнейшей обработке в RouterOS только в том случае, если его IP-адрес источника попадает в диапазон allowed-address пира, от которого он был получен. Если совпадения нет, пакет молча отбрасывается. Это обеспечивает мощный встроенный механизм фильтрации на уровне интерфейса.

2.2 Различие в RouterOS: Намеренное разделение обязанностей

В отличие от стандартных реализаций Linux, использующих утилиту wg-quick, которая может автоматически добавлять маршруты в основную системную таблицу маршрутизации на основе параметра AllowedIPs, RouterOS этого не делает. Область действия параметра allowed-address строго ограничена внутренней логикой самого интерфейса WireGuard.

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

Для того чтобы трафик направлялся в туннель WireGuard или чтобы маршрутизатор знал о удаленных сетях, доступных через туннель, администратор должен вручную создать статические маршруты в /ip route или настроить протокол динамической маршрутизации (например, OSPF или BGP) для работы через интерфейс WireGuard. Единственный маршрут, который создается автоматически, — это подключенный маршрут для IP-адреса, назначенного непосредственно самому интерфейсу WireGuard.

2.3 Анатомия пути пакета через RouterOS

Поток исходящего пакета (из LAN к удаленному пиру):

1. Пакет от клиента в локальной сети (например, 192.168.88.100) отправляется на удаленный адрес (например, 10.10.20.5).

2. Маршрутизатор MikroTik получает пакет на своем LAN-интерфейсе.

3. Проверяется основная таблица маршрутизации (/ip route). Вручную настроенный статический маршрут (например, dst-address=10.10.20.0/24 gateway=wireguard1) направляет пакет на интерфейс wireguard1.

4. Интерфейс wireguard1 анализирует адрес назначения пакета (10.10.20.5) и находит пира, чей allowed-address содержит этот IP (например, пир с allowed-address=10.10.20.0/24).

5. Пакет шифруется публичным ключом этого пира и инкапсулируется в UDP.

6. Зашифрованный пакет отправляется через физический WAN-интерфейс на endpoint-address пира.

Поток входящего пакета (от удаленного пира в LAN):

1. Зашифрованный UDP-пакет поступает на публичный IP-адрес маршрутизатора на настроенный listen-port. Правило межсетевого экрана в цепочке input должно разрешать этот UDP-трафик.

2. Интерфейс wireguard1 получает пакет и идентифицирует пира на основе криптографических идентификаторов в рукопожатии.

3. Пакет расшифровывается и аутентифицируется. IP-адрес источника определяется, например, как 10.10.20.5.

4. Критическая проверка ACL: Интерфейс проверяет, находится ли 10.10.20.5 в списке allowed-address отправляющего пира. Если да, пакет принимается. В противном случае он отбрасывается.

5. Расшифрованный IP-пакет передается в цепочку forward RouterOS.

6. Правило межсетевого экрана в цепочке forward должно разрешать трафик с интерфейса WireGuard (in-interface=wireguard1) на LAN-интерфейс (out-interface=bridge-lan).

7. Таблица маршрутизации направляет пакет соответствующему клиенту в локальной сети.

Двойственная природа allowed-address как ключа маршрутизации и ACL является одновременно источником безопасности WireGuard и его наиболее частых ошибок в конфигурации. Она криптографически связывает идентификатор (публичный ключ) с набором IP-адресов, гарантируя, что пакет, пришедший на интерфейс, действительно отправлен аутентифицированным пиром и имеет разрешенный IP-адрес источника. Однако этот же механизм часто становится причиной сбоев. Администратор может правильно настроить /ip route для отправки трафика в туннель, но забыть включить соответствующую сеть в allowed-address пира на принимающей стороне. В результате трафик будет односторонним: отправляющий маршрутизатор зашифрует и отправит пакет, а принимающий — расшифрует его и отбросит на этапе проверки ACL.

Продвинутые сценарии, анализ проблем и их решения

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

3.1 Сценарий: Дублирование конфигураций пиров ("Клонированные клиенты")

• Определение проблемы: Два или более клиентских устройства настроены с использованием одного и того же файла конфигурации WireGuard, что означает, что они используют один и тот же приватный ключ и, следовательно, представляют один и тот же публичный ключ маршрутизатору MikroTik.

• Технический анализ: Это не приводит к простому подключению по принципу "кто первый, тот и успел". Вместо этого активируется встроенная в WireGuard функция роуминга. Запись о пире на маршрутизаторе MikroTik хранит единые значения current-endpoint-address и current-endpoint-port. Когда Клиент А завершает рукопожатие, маршрутизатор обновляет конечную точку на публичный IP и порт Клиента А. Когда Клиент Б впоследствии завершает рукопожатие, маршрутизатор перезаписывает конечную точку данными Клиента Б. Хотя статические ключи одинаковы, у каждого клиента свои эфемерные ключи для сессии. Когда Клиент А (теперь "устаревший" клиент) пытается отправить данные, его пакеты шифруются эфемерным ключом, который больше не соответствует ожиданиям маршрутизатора для текущей сессии. Маршрутизатор получает эти пакеты, но не может их аутентифицировать и молча отбрасывает. Соединение "переключится" обратно на Клиента А только тогда, когда он инициирует новое рукопожатие, что может произойти после того, как его таймер persistent-keepalive определит, что соединение разорвано.

• Симптомы: Пользователь сталкивается с крайне нестабильным соединением, которое "перескакивает" между двумя устройствами. Один пользователь может просматривать веб-страницы, а затем внезапно теряет связь, когда устройство другого пользователя отправляет трафик. Наблюдаются значительные потери пакетов и высокая задержка из-за постоянного переустановления рукопожатий. Значения last-handshake и current-endpoint-address для пира на MikroTik будут часто меняться.

• Решение: Фундаментальный принцип WireGuard — одна уникальная криптографическая идентичность (публичный ключ) на устройство. Единственное правильное решение — сгенерировать новую, уникальную пару ключей для каждого клиентского устройства и создать для каждого из них отдельную запись о пире на маршрутизаторе MikroTik.

• Историческое примечание по RouterOS: До версии RouterOS v7.2rc4 существовало "ограничение", при котором RouterOS не позволяла настраивать один и тот же публичный ключ пира более одного раза на всем устройстве, даже на разных интерфейсах WireGuard. Это было специфическое решение реализации RouterOS, а не ограничение протокола, и оно было исправлено.

3.2 Сценарий: Неоднозначная маршрутизация с пересекающимися allowed-address

• Определение проблемы: Администратор настраивает двух отдельных пиров на одном интерфейсе WireGuard с пересекающимися диапазонами allowed-address. Распространенный пример — два "мобильных" пира, оба настроены с allowed-address=0.0.0.0/0 в попытке направить весь их трафик через MikroTik.

• Технический анализ: Когда интерфейсу WireGuard необходимо отправить пакет по назначению, которое попадает в пересекающийся диапазон, он должен выбрать, какому пиру его отправить. Логика WireGuard предписывает выбирать пира с наиболее специфичным совпадающим маршрутом. Если у двух пиров идентичный, пересекающийся маршрут (например,0.0.0.0/0), поведение может стать непредсказуемым. Обсуждения на форумах показывают, что "побеждает первый" или поведение в RouterOS иным образом не определено. Это создает неоднозначное и ненадежное состояние маршрутизации внутри самого интерфейса WireGuard.

• Симптомы: Исходящий трафик из LAN в интернет (через туннель) может направляться только к одному из пиров или не работать вовсе. Связь будет непостоянной и сложной для диагностики, так как основная таблица /ip route выглядит корректно.

• Решение: Параметр allowed-address должен рассматриваться как таблица маршрутизации; маршруты должны быть уникальными и специфичными. Для мобильных пользователей каждый пир должен иметь allowed-address, как минимум, свой уникальный IP-адрес в туннеле (например, 10.100.100.2/32). Если нескольким пирам необходимо маршрутизировать трафик для одной и той же удаленной сети, эта сеть должна быть указана в списке allowed-address только одного пира на данном интерфейсе.

3.3 Сценарий: Работа через трансляцию сетевых адресов (NAT)

• Определение проблемы: "Сервер" WireGuard на MikroTik находится за вышестоящим NAT-маршрутизатором, или клиент находится за NAT, что приводит к сбоям соединения.

• Технический анализ и решения:

1. Сервер за NAT: Сервер не может получать начальные пакеты рукопожатия от клиентов, так как вышестоящий NAT-маршрутизатор не знает, куда их направить.

Решение: На вышестоящем маршрутизаторе должно быть настроено правило dst-nat (проброс портов). Это правило должно перенаправлять UDP-трафик, поступающий на его публичный WAN-интерфейс на порту WireGuard (например, 13231), на приватный LAN IP-адрес маршрутизатора MikroTik на тот же порт.

2. Клиент за NAT: Клиент может инициировать рукопожатие, но NAT-сессия на его локальном маршрутизаторе может истечь по таймауту. Если сервер попытается отправить данные после истечения сессии, пакеты будут отброшены маршрутизатором клиента.

Решение: Параметр persistent-keepalive должен быть установлен в конфигурации пира на клиенте (указывающей на сервер). Стандартное значение — около 25 секунд. Это гарантирует, что клиент будет отправлять пакеты достаточно часто, чтобы поддерживать NAT-сессию активной. Устанавливать persistent-keepalive на сервере для клиента, как правило, не нужно и некорректно.

3. Необходимые правила межсетевого экрана на MikroTik:
   • /ip firewall filter: Необходимо правило в цепочке input для accept входящего UDP-трафика на listen-port WireGuard, предназначенного самому маршрутизатору. Также необходимо правило в цепочке forward для разрешения прохождения трафика через маршрутизатор с интерфейса WireGuard в LAN и обратно.
   • /ip firewall nat: Если клиентам необходим доступ в интернет через маршрутизатор MikroTik, требуется правило src-nat с action=masquerade для трафика, покидающего WAN-интерфейс (out-interface=ether1) с IP-адресом источника из подсети WireGuard (src-address=10.100.100.0/24).

Почти во всех сценариях сбоя — от клонированных клиентов до неверных allowed-address или истекших NAT-сессий — результатом является "молчаливое отбрасывание" пакетов. WireGuard спроектирован как "скрытный" протокол, который не отвечает на неаутентифицированные пакеты, что является сильной стороной безопасности, но усложняет диагностику. Это означает, что ping или traceroute просто завершатся по таймауту без ясной причины. Это повышает важность диагностических инструментов RouterOS: таймер last-handshake является лучшим индикатором работоспособности соединения, а анализатор пакетов (/tool sniffer) необходим для определения, доходят ли пакеты рукопожатия до маршрутизатора, что является ключом к диагностике проблем с NAT и межсетевым экраном.