Ситуация знакомая любому админу малого бизнеса. Офис, склад в другом районе и директор, который работает из дома и хочет, «чтобы 1С открывалась как на работе». Бюджета на серьёзное железо нет, зато в каждой точке стоит MikroTik: стоил недорого и умеет примерно всё.
И вот тут начинается. WireGuard в RouterOS есть, настраивается быстро, туннель поднимается с первого раза, рукопожатие бодро тикает — а трафик не ходит, и вы сидите перед WinBox и понимаете, что между «интерфейс создан» и «пинг пошёл» есть шаг, о котором инструкция умолчала. Знакомо? Мне — очень.
Дальше три сценария, готовые блоки конфигурации и отдельно проблема совпадающих подсетей, на которой спотыкается каждый второй. Я тоже споткнулся, и помню это до сих пор.
Почему все сидят на MikroTik и что он умеет
Причина популярности простая: за деньги домашнего роутера вы получаете железку с маршрутизацией, фаерволом, VPN-сервером и скриптами. Расплата — интерфейс. RouterOS ничего не прощает и ничего не делает за вас: забыли правило фаервола — трафик не пойдёт, и никто не сообщит. Мне эта черта нравится и бесит одновременно. Нравится, потому что железка делает ровно то, что вы написали. Бесит, потому что написали вы не то, что думали.
Из коробки RouterOS умеет много: IPsec, OpenVPN, L2TP, PPTP (не надо), SSTP, EoIP, GRE. И WireGuard — с седьмой ветки. Это важно: в RouterOS 6 WireGuard нет и не появится. Версию смотрим командой /system/resource/print. Обновление с шестёрки — отдельное мероприятие, с бэкапом и без спешки в пятницу: синтаксис местами поменялся, фаервол ведёт себя иначе, и выяснять это в субботу по звонку директора я не советую.
Почему WireGuard, а не IPsec, который живёт тут годами? Проще на порядок, быстрее, легче для процессора и переживает смену адреса на одном конце. Впрочем, сравнение протоколов у меня разложено отдельно.
Сценарий 1: офис подключается к серверу провайдера
Самый простой случай: есть офисный MikroTik и VPN-сервер провайдера, а надо, чтобы часть офисного трафика выходила в интернет через него. Бизнесу это даёт предсказуемый внешний адрес, доступ к сервисам с географическими ограничениями и скрытый адрес офиса, причём сотрудники не настраивают ничего — роутер делает всё сам, и это, по моему опыту, единственный способ, при котором настройка доживает до конца месяца. От провайдера приходит обычный конфиг: приватный ключ вашей стороны, адрес в туннеле, публичный ключ и endpoint сервера. Отдельный вопрос — что заворачивать в туннель. Весь офис — плохая идея: банк-клиент, госпорталы и бухгалтерия закапризничают от иностранного адреса. Отправляйте только нужные подсети.
[Изображение: схема — офисная сеть, MikroTik, туннель до сервера провайдера, часть трафика напрямую]
Сценарий 2: два офиса в одной сети
Классический Site-to-Site. Офис и склад, головной и филиал. Задача — чтобы из одной сети было видно другую: файловый сервер, 1С, камеры, принтеры. Схема такая: на обоих роутерах поднимается WireGuard-интерфейс, они прописывают друг друга как пиров, между ними служебная подсеть вроде 10.99.0.0/30, а в маршруты добавляется «сеть соседа доступна через туннель». Ключевое: хотя бы у одной стороны должен быть белый IP. Инициировать может любая, но кому-то надо знать адрес другого. Обе точки за NAT — напрямую туннель не построить, нужен сценарий три.
И здесь всплывает главная засада, из-за которой половина проектов встаёт колом: подсети в обоих офисах одинаковые. Оба роутера настраивались из коробки, а из коробки почти у всех 192.168.88.0/24. Ниже про это отдельный раздел, и я бы на вашем месте прочитал его до начала работ.
К слову, если строить всё самому не хочется, есть VPN для объединения офисов — там эта топология собирается под ключ. Общая теория межофисных туннелей — в статье про Site-to-Site VPN.
Сценарий 3: офис и VPS с выделенным адресом
Идея: вместо прямых связей между офисами вы ставите в центр сервер с постоянным белым IP, и все точки подключаются к нему. Получается звезда — офисы, склад, ноутбуки удалёнщиков, телефоны в одном месте. Мне эта схема нравится больше прочих. Что она даёт.
- Белый адрес нужен только серверу. Офисы сидят за любым NAT, хоть за мобильным.
- Новая точка — это один пир на сервере. Остальные роутеры трогать не надо.
- Внешний трафик выходит с одного предсказуемого адреса. Для белых списков — незаменимо.
- Удалённые сотрудники подключаются туда же, отдельной инфраструктуры не надо.
Минус понятный: сервер становится единой точкой отказа, а трафик между офисами набирает задержку. Для файлов и 1С некритично, для телефонии, если честно, стоит померить. Сервер можно поднять самому на VPS, а можно взять выделенный VPN-сервер с готовой конфигурацией и мониторингом. Про то, когда бизнесу нужен персональный адрес, а когда хватает общего, есть отдельный разбор.
Настройка WireGuard в RouterOS по шагам
Дальше команды. Вбивать можно в терминал WinBox или через SSH. Оговорюсь сразу, где будет больно: не на создании интерфейса, оно проходит у всех, а на четвёртом шаге, где два параметра выглядят необязательными, а без них вы полдня ищете, куда девались пакеты. Я искал.
Шаг 1. Создаём интерфейс. Ключи RouterOS сгенерирует сам.
/interface/wireguard add name=wg-tunnel listen-port=13231
Шаг 2. Смотрим свой публичный ключ. Его вы отдадите второй стороне.
/interface/wireguard print
Шаг 3. Вешаем адрес на интерфейс. Адрес внутри туннеля, я его с офисной сетью когда-то путал.
/ip/address add address=10.99.0.1/30 interface=wg-tunnel
На второй стороне 10.99.0.2/30.
Шаг 4. Добавляем пира. Ключ берём у второй стороны, endpoint указываем, если у неё белый адрес.
/interface/wireguard/peers add interface=wg-tunnel public-key="ключ_второй_стороны" endpoint-address=203.0.113.10 endpoint-port=13231 allowed-address=10.99.0.2/32,192.168.20.0/24 persistent-keepalive=25s
Вот на этих двух параметрах и ошибаются чаще всего. allowed-address — не список разрешений, как думают многие и как думал когда-то я, а таблица маршрутизации внутри туннеля: тут перечисляется всё, что должно уходить этому пиру — его адрес в служебной подсети плюс его локальные сети. Забыли сеть филиала — пакеты не полетят, и ошибки вы не увидите: с точки зрения роутера ошибки и нет, он просто не знает маршрута. Второй параметр, persistent-keepalive, обязателен для стороны за NAT: без него NAT провайдера закроет сессию через несколько минут тишины. Ставьте 25s и не думайте.
[Изображение: окно WinBox с созданным WireGuard-интерфейсом и списком пиров]
Шаг 5. Маршрут до сети соседа.
/ip/route add dst-address=192.168.20.0/24 gateway=wg-tunnel
Всё. Если обе стороны настроены зеркально, туннель оживёт. Проверяю я командой /interface/wireguard/peers print: там время последнего рукопожатия, свежее значение в пределах пары минут означает, что связь есть.
Фаервол и маршрутизация: без этого не поедет
Вот раздел, из-за которого мне пишут чаще всего. Туннель поднялся, рукопожатие проходит, пинг не идёт, человек перенастраивает пира, потом ключи, потом пересоздаёт интерфейс — а причина почти всегда одна. Вернее, всегда одна. Фаервол. RouterOS строг по умолчанию, и новый интерфейс привилегий не получает.
Первое. Разрешите входящие пакеты WireGuard на роутере с белым адресом — порт должен совпадать с listen-port.
/ip/firewall/filter add chain=input action=accept protocol=udp dst-port=13231 comment="WireGuard in"
Правило должно стоять выше запрещающих. RouterOS идёт сверху вниз, первое совпадение выигрывает, так что в конце списка, после общего запрета, оно не сработает никогда. Классические грабли, я наступал не раз: правило есть, глазами видно, толку ноль.
Второе. Разрешите транзитный трафик через туннель в обе стороны.
/ip/firewall/filter add chain=forward action=accept in-interface=wg-tunnel comment="from tunnel"
/ip/firewall/filter add chain=forward action=accept out-interface=wg-tunnel comment="to tunnel"
[Изображение: список правил фаервола в WinBox с подсвеченным порядком цепочки]
Правила широкие, и для боевой сети их стоит сузить до конкретных подсетей и портов — но сначала добейтесь, чтобы заработало вообще. Обратный порядок, скажем так, редко кончается хорошо. Я пробовал.
Третье, и тут внимательно. Проверьте, не попадает ли туннельный трафик под правило маскарадинга. Типовая настройка MikroTik содержит srcnat с action=masquerade на выход в интернет, и если написано оно широко, без исходящего интерфейса, адреса офисной сети подменятся и на пути в туннель: сосед увидит пакеты не от 192.168.10.5, а от адреса туннеля, ответы уйдут не туда, а вы будете смотреть на симметричную конфигурацию и не понимать, почему работает она несимметрично. Лечится явным указанием интерфейса. А для выхода в интернет через сервер провайдера маскарадинг, наоборот, нужен:
/ip/firewall/nat add chain=srcnat out-interface=wg-tunnel action=masquerade
Разница принципиальная: между офисами адреса подменять не надо, а при выходе в интернет надо.
Когда подсети офисов совпадают
Самая частая причина неработающего Site-to-Site и самая обидная: вылезает после того, как всё остальное настроено и вы морально готовились закрывать задачу. Выглядит так: в обоих офисах сеть 192.168.88.0/24, туннель поднят, рукопожатие есть, маршруты прописаны, а до соседей не достучаться. Причина очевидная. Компьютер в первом офисе обращается к 192.168.88.50, роутер видит, что подсеть его собственная, и отправляет пакет внутрь своего офиса, где такой адрес тоже есть. До туннеля дело не доходит. Аналогия простая: в двух филиалах кабинеты пронумерованы одинаково, курьеру говорят «отнеси в сто пятый» — и он относит в тот, что в его здании.
Правильное решение — развести подсети. Один офис на 192.168.10.0/24, второй на 192.168.20.0/24, третий на 192.168.30.0/24. Проблемы нет. Сеть небольшая и статических адресов немного — переадресуйте: час работы, зато дальше живёте спокойно, а любая альтернатива, на мой взгляд, сложнее в поддержке. Но бывает, что нельзя: полсотни устройств с прошитыми адресами, оборудование с привязкой по IP, софт с захардкоженными настройками, а объединить офисы надо было вчера.
Тогда — трансляция адресов. Идея в том, чтобы выдать каждому офису «псевдоним»: виртуальную подсеть, под которой его видит сосед. Первый офис для второго выглядит как 10.99.1.0/24, второй для первого — как 10.99.2.0/24. Реальные адреса остаются, наружу торчат подменённые. В RouterOS для этого есть netmap: транслирует подсеть в подсеть с сохранением последнего октета, так что 192.168.88.50 становится 10.99.1.50. Нужны два правила на каждой стороне. Исходящее подменяет свой адрес на псевдоним:
/ip/firewall/nat add chain=srcnat src-address=192.168.88.0/24 dst-address=10.99.2.0/24 action=netmap to-addresses=10.99.1.0/24
Входящее — разворачивает псевдоним обратно в реальный адрес:
/ip/firewall/nat add chain=dstnat dst-address=10.99.1.0/24 action=netmap to-addresses=192.168.88.0/24
На втором роутере зеркально, с переставленными номерами. Маршрут прописывается не на реальную сеть соседа, а на псевдоним — про это тоже забывают.
Работает. Но честно про цену: обращаться к соседям придётся по подменённым адресам, а это объяснять пользователям, фиксировать в документации и через год выяснять, почему сервер в филиале отвечает на два адреса — причём выяснять будете, если честно, уже не вы. Плюс протоколы, которые передают IP внутри данных, ходят через такую схему плохо.
[Изображение: схема трансляции при совпадающих подсетях — реальные адреса и псевдонимы с обеих сторон]
Ещё раз, и это моя главная просьба: есть возможность развести подсети — разводите. NAT тут не решение, а обезболивающее.
Мониторинг: узнать о падении раньше сотрудников
Туннель упадёт. Не «может упасть», а именно упадёт: провайдер переподключится, у сервера сменится адрес, мигнёт питание. Вопрос в том, узнаете вы это от системы или от бухгалтера, у которого не открывается 1С, и второй вариант, по моему опыту, дороже. Простейший способ в RouterOS — netwatch: пингует адрес с заданным интервалом и запускает скрипт при изменении состояния.
/tool/netwatch add host=10.99.0.2 interval=30s
Пинговать надо адрес на дальнем конце туннеля, а не сервер в офисе соседа — иначе поймаете ложные срабатывания из-за выключенного на ночь компьютера. В netwatch есть поля для скриптов на «упал» и «поднялся»: лог, уведомление, пересоздание интерфейса.
А про автовосстановление скажу осторожно. WireGuard обычно восстанавливается сам: постоянной сессии он не держит, а возобновляет обмен, когда связь вернулась. Скриптовое пересоздание интерфейса помогает редко и иногда делает хуже, срабатывая на сетевую икоту. Сначала разберитесь, из-за чего падает, потом автоматизируйте. Кстати, отсутствие persistent-keepalive отвечает, по моему опыту, за большую часть жалоб вида «отваливается по ночам». Где точек больше трёх, ручного netwatch мало. Что собирать — в статье про мониторинг VPN-подключений.
На чём спотыкаются чаще всего
Неполный allowed-address. Указали служебный адрес пира, забыли локальную сеть. Туннель работает, соседняя сеть недоступна. Я проверяю это первым.
Правило фаервола ниже запрета. Разрешающее есть, но лежит после общего drop. Проверяйте порядок в цепочке, а не только наличие правила.
Маскарадинг съедает туннельный трафик. Широкое srcnat без интерфейса подменяет адреса на пути в туннель. Симптом: пинг идёт в одну сторону и не идёт обратно.
Нет keepalive на стороне за NAT. Работает, пока есть трафик, и умирает в тишине. Мой любимый случай.
Совпадающие подсети. Разобрано выше. Проверяйте до настройки, а не после.
Порт закрыт у провайдера. Некоторые фильтруют UDP на нестандартных портах. Рукопожатия нет, настройки трижды проверены — пробуйте другой порт, мне это помогало.
RouterOS 6. WireGuard там нет. Проверьте версию прежде, чем искать раздел в меню.
Ключи скопированы с потерей символа. Длинные строки, мессенджер, обрезанный хвост. Мне такое попадалось не раз — копируйте через текстовый файл.
Коротко для тех, кто настраивает завтра
Перед началом проверьте две вещи: версию RouterOS (нужна седьмая) и адресацию во всех офисах. Эти два пункта, по моему опыту, экономят больше времени, чем всё остальное вместе. Дальше порядок такой: интерфейс, адрес, пир с полным allowed-address, маршрут, правила фаервола, keepalive, netwatch. Пропущенный фаервол — причина номер один, по которой «туннель есть, а связи нет». И не городите NAT там, где можно развести подсети.
Строите сложнее пары туннелей — выделенный сервер под вашу сеть снимает половину головной боли: белый адрес, готовые конфиги под каждую точку, поддержка, которая вашу топологию уже видела. Разница между корпоративным и потребительским подходом разобрана отдельно, и она не только в цене. Конфиг под свою схему запрашивайте у поддержки ещё на тесте.
Частые вопросы
Как настроить WireGuard на MikroTik?
Создайте интерфейс командой /interface/wireguard add, повесьте адрес из служебной подсети, добавьте пира с публичным ключом второй стороны и полным allowed-address, пропишите маршрут до удалённой сети и откройте порт в фаерволе. Стороне за NAT задайте persistent-keepalive.
Как объединить два офиса через VPN?
Поднимите WireGuard-интерфейс на обоих роутерах, пропишите их друг другу как пиров, выделите служебную подсеть и добавьте маршруты до сетей соседа. Хотя бы у одной стороны нужен белый IP. Нет ни у кого — соединяйте через промежуточный сервер с постоянным адресом.
Что делать, если подсети совпадают?
Лучший вариант — сменить адресацию в одном из офисов: час работы и никаких последствий. Если нельзя, используйте трансляцию через netmap: каждому офису назначается подсеть-псевдоним, под которой его видит сосед. Работает, но усложняет поддержку и ломает протоколы, передающие IP внутри данных.
Какая версия RouterOS нужна?
Седьмая или новее — в шестой ветке WireGuard отсутствует и не появится. Версию смотрят командой /system/resource/print. Обновление делайте с бэкапом и запасом времени: часть синтаксиса и поведение фаервола изменились.
