MikroTik и WireGuard: объединяем офисы и удалённых сотрудников

Когда MikroTik с WireGuard — правильный выбор, а когда нет

Связка уместна, когда роутеры MikroTik уже стоят или их покупка не проблема: WireGuard входит в RouterOS v7 без дополнительных лицензий, конфигурируется десятком команд и переносит на моделях с ARM-процессорами сотни мегабит в секунду. По сравнению с историческим набором роутеров — PPTP, который давно скомпрометирован и не должен использоваться, или L2TP/IPsec, который жив, но заметно капризнее в настройке, — WireGuard проще ровно в тех местах, где прежние варианты доставали: ключи вместо паролей, один порт UDP, предсказуемый NAT-проход.

Честные границы варианта. Если роутеров MikroTik нет и брать их стоит только ради VPN — возможно, лишнее: WireGuard поднимается и на любом маленьком Linux-сервере. WireGuard — третий уровень: L2-мосты между офисами им не делаются, они и редко нужны. Тонкие корпоративные требования — учёт доступов по пользователям, интеграция с доменной аутентификацией на шлюзе — выходят за его возможности; в небольших компаниях такие требования чаще воображаемые, чем реальные. Наконец, скорость туннеля зависит от процессора конкретной модели роутера — для гигабита между офисами стоит выбирать модель с запасом.

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

Настройка RouterOS v7: интерфейс, ключи, peers

Команды ниже одинаково работают через терминал SSH и через WinBox — разница только в удобстве, порядок не меняется.

На роутере офиса А создаётся WireGuard-интерфейс — RouterOS генерирует ключевую пару автоматически при создании:

/interface wireguard
add name=wg-tunnel listen-port=13231

Публичный ключ показывается в выводе /interface wireguard print — он понадобится второй стороне. Туннельному интерфейсу назначается адрес из плана:

/ip address
add address=10.10.10.1/30 interface=wg-tunnel

На роутере офиса Б — те же два шага со своим адресом (10.10.10.2/30) и своим портом. После этого стороны обмениваются публичными ключами: роутер А получает пирами роутер Б, и наоборот. Пир офиса Б на роутере А:

/interface wireguard peers
add interface=wg-tunnel public-key="<публичный ключ Б>" \
    endpoint-address=<адрес Б> endpoint-port=13231 \
    allowed-address=10.10.10.2/32,192.168.20.0/24

allowed-address здесь — тот самый двойной параметр WireGuard: и разрешение «от этого ключа принимаю только эти сети», и указание, куда отправлять пакеты для них. Важное отличие от wg-quick: маршруты RouterOS по allowed-address не создаёт — их вносим отдельно:

/ip route
add dst-address=192.168.20.0/24 gateway=wg-tunnel

У офиса Б всё зеркально: пир — публичный ключ А с allowed-address 10.10.10.1/32 и 192.168.10.0/24, маршрут в 192.168.10.0/24 через туннель. Если белый адрес есть только у одной стороны, endpoint указывается только у второй — первой достаточно allowed-address: соединение она узнает по входящим пакетам.

Про ключи на роутере: приватный ключ хранится в конфигурации RouterOS, а значит попадает и в экспорт настроек. Резервную копию конфигурации стоит беречь как сам ключ: тот же уровень доступа, то же хранение отдельно от «рабочих» архивов. Потерю ключа чинит перевыпуск пары на обеих сторонах, утечку — нет.

Техническая деталь, которую полезно знать заранее: у WireGuard MTU ниже обычного Ethernet. В большинстве сетей это незаметно, но если между офисами затесался PPPoE, симптом известный: пинг проходит, а передача файлов «виснет». Лечится снижением MTU на туннельном интерфейсе до 1380–1400.

Доступ сотрудников к офису

Мобильные сотрудники подключаются к роутеру офиса А отдельными пирами — по одному на устройство, с адресами из диапазона 10.10.20.0/24:

/interface wireguard peers
add interface=wg-tunnel public-key="<ключ ноутбука>" \
    allowed-address=10.10.20.10/32

На устройстве сотрудника — конфиг в формате wg-quick или профиль официального приложения: туннельный адрес 10.10.20.10, Endpoint — адрес офиса А и порт 13231, в AllowedIPs — офисная сеть 192.168.10.0/24, туннельные 10.10.10.0/24 и 10.10.20.0/24 и, при объединении, 192.168.20.0/24. Правило то же, что и для сервера: адрес из allowed-address пира на роутере — один на устройство.

Трафик сотрудников в офисные сети либо маршрутизируется честно — тогда в LAN нужен обратный маршрут в 10.10.20.0/24 на основном шлюзе, — либо прячется за src-nat на роутере:

/ip firewall nat
add chain=srcnat src-address=10.10.20.0/24 \
    dst-address=192.168.10.0/24 out-interface=bridge action=masquerade

Masquerade быстрее в настройке и не трогает остальные устройства, но серверы видят сотрудников под адресом роутера — для разграничения доступов честная маршрутизация выразительнее. Отзыв доступа сотруднику — удаление его пира; ключ без пира на роутере бесполезен.

Конфиг сотрудника собирается из данных печати пира и адреса офиса: три строки в мобильном приложении или профиль wg-quick. Доступ в этой схеме круглосуточный; если работе «после шести» есть место, ограничение по времени делается правилом файрвола с параметром времени, а не хитростями с ключами. О том, что туннель жив, стоит помнить и снаружи: доступность офисного адреса и порта — первый кандидат в первый контур любого мониторинга.

И обычная практика порядка: адресный план, список пиров и правило проброса живут в одном документе — том же, где хранится копия конфигурации роутеров. Разрозненные записи «у кого-то в блокноте» к третьему сотруднику перестают совпадать с реальностью.

Проверка

Состояние пиров показывает, где искать причину:

/interface wireguard peers print

Поле last-handshake — главное: свежее рукопожатие означает, что ключи, адреса и порт в порядке. Если рукопожатия нет — проблема до WireGuard: недоступен Endpoint, закрыт порт, не тот ключ. Если рукопожатие есть, а трафика нет — проблема после: allowed-address, маршруты, файрвол. Такое разделение экономит время: до ключей дело обычно доходит один раз, при первичной настройке.

Полный маршрут проверки сквозной: с ноутбука сотрудника — ping туннельного адреса роутера (10.10.10.1), затем LAN-адреса офисного ресурса, затем открытие самого ресурса по имени, если используется внутренний DNS. Каждый шаг отвечает за свой слой — так же, как и в серверном варианте WireGuard.

Диагностика с самого роутера тоже возможна, если указать источник: ping 192.168.20.10 src-address=192.168.10.1 отправляет пакеты от имени офисной сети, а не от WAN-адреса, — так проверка точнее повторяет путь реального сотрудника. Журнал WireGuard в RouterOS лаконичен: ошибки рукопожатия попадают в лог с указанием пира, и этого достаточно, чтобы отличить «не тот ключ» от «порт закрыт».