mikrotik · vpn · amneziawg · container · dns
AmneziaWG на MikroTik с контейнером: весь не-РФ трафик через VPS
Практический гайд: VPS с Amnezia, MikroTik с поддержкой контейнеров, AWG Proxy Configurator и аккуратная настройка маршрутов и DNS.
Интересный рабочий вариант VPN для офиса: берем MikroTik с поддержкой контейнеров, поднимаем AmneziaWG на VPS, а сам MikroTik превращаем в VPN-шлюз. Клиентам в офисе не нужно ставить VPN на каждый компьютер: маршрутизацией занимается роутер.
В этой заметке фиксирую практический сценарий: весь не-РФ трафик через туннель, остальное напрямую.
Откуда идея
Идея с awg-proxy-контейнером для MikroTik не моя. За основу взят проект amneziawg-mikrotik-c и статья на Habr «Наконец-то: AmneziaWG в Mikrotik», где описана сама концепция: MikroTik использует штатный WireGuard, а контейнер преобразует обмен так, чтобы он работал с AmneziaWG.
Спасибо автору проекта и статьи за решение и конфигуратор.
Полезные ссылки:
- статья-источник: Наконец-то: AmneziaWG в Mikrotik
- конфигуратор из статьи: AWG Proxy Configurator
- проект: timbrs/amneziawg-mikrotik-c
Что понадобится
- MikroTik с RouterOS v7 и поддержкой containers.
- Включенный container package.
- Накопитель для контейнеров: USB / SSD / внутренний диск, в зависимости от модели.
- VPS, например u1host: u1host.com.
- AmneziaVPN на ПК.
- AWG Proxy Configurator для MikroTik.
Общая схема
офисные устройства
-> MikroTik
-> WireGuard interface на MikroTik
-> awg-proxy container
-> AmneziaWG tunnel
-> VPS
-> интернет
VPS выступает сервером AmneziaWG. MikroTik работает клиентом через контейнер.
Шаг 1. Подготовить VPS
Покупаем VPS. Для такого сценария обычно не нужен большой сервер: важнее нормальный канал, публичный IP и возможность подключиться по SSH.
Дальше на ПК ставим AmneziaVPN, добавляем новый сервер и указываем доступ к VPS. Amnezia сама подключится, установит нужные компоненты и поднимет VPN.
После настройки нужно получить клиентский .conf для AmneziaWG. Его потом вставляем в конфигуратор для MikroTik.
Шаг 2. Подготовить MikroTik
Проверяем, что MikroTik умеет запускать контейнеры и есть storage:
/system/resource/print
/system/package/print
/container/print
/disk/print
Если container package не включен или нет нормального хранилища, сначала решаем это. Без storage контейнер либо не установится, либо не переживет перезагрузку.
Шаг 3. Сгенерировать команды
Открываем конфигуратор из статьи:
https://awg-proxy-b2aa44.gitlab.io/configurator.html
Выбираем режим:
MikroTik + Container (Docker)
Вставляем .conf от AmneziaWG.
В сценарии маршрутизации выбираем:
All non-RU traffic through tunnel
или в русской версии:
Весь не-РФ трафик через туннель
Важное предупреждение про маршруты
В этом режиме маршрутизация идет по подсетям, а не “магически по странам” на уровне приложения. Конфигуратор добавляет набор маршрутов/address-list для не-РФ направлений.
Это удобно, но требует аккуратности:
- часть маршрутов может быть крупными подсетями;
- списки со временем могут устаревать;
- возможны ложные попадания или непопадания;
- можно случайно отправить через туннель больше трафика, чем ожидалось;
- FastTrack и старые firewall-правила могут мешать маршрутизации.
В конфигураторе есть предупреждение по этому поводу, его лучше не пролистывать на автомате.
Главное про DNS
DNS здесь критичен.
Если мы отправляем весь не-РФ трафик через туннель, то DNS-запросы тоже должны идти через туннель. Иначе получится утечка DNS: сайты будут открываться через VPN, а запросы имен останутся у провайдера или локального DNS.
Правильная идея:
клиент -> DNS на MikroTik -> DNS через туннель -> внешний DoH/DNS
А не так:
клиент -> DNS провайдера напрямую
Что проверить на MikroTik:
/ip/dns/print
/ip/dns/cache/print
/ip/firewall/address-list/print
/ip/route/print
Если клиенты получают DNS по DHCP, нужно проверить DHCP Network:
/ip/dhcp-server/network/print
Для офисных клиентов MikroTik должен выдавать себя как DNS-сервер либо выдавать DNS, который гарантированно уходит через туннель.
Шаг 4. Загрузить конфиг в MikroTik
Конфигуратор выдаст команды RouterOS. Их лучше применять по шагам:
1. Step 1: установка контейнера, veth, WireGuard и базовых правил.
2. Дождаться, что контейнер установился и запустился.
3. Step 2: применить routing setup.
В самом конфигураторе есть подсказка: routing setup вставлять после завершения первого шага.
Шаг 5. Проверить контейнер и туннель
Проверяем контейнер:
/container/print
/container/logs/print
Проверяем WireGuard:
/interface/wireguard/print
/interface/wireguard/peers/print
У peer должен появиться last-handshake.
Проверяем маршруты:
/ip/route/print
/ip/firewall/address-list/print
Шаг 6. Проверить с клиента
С клиента в офисной сети проверяем внешний IP:
curl -4 ifconfig.me
Для не-РФ направления должен быть IP VPS.
Отдельно проверяем DNS:
nslookup example.com
Потом открываем:
Запускаем Extended test. Если в результате виден DNS провайдера офисного интернета, значит DNS-запросы уходят мимо туннеля и настройку нужно исправлять.
Типовые проблемы
- MikroTik не поддерживает containers;
- контейнер не стартует из-за storage;
- выбран не тот образ под архитектуру;
- клиенты получают DNS провайдера;
- DNS идет напрямую, а не через туннель;
- FastTrack обходит нужные правила;
- routing setup применили до запуска контейнера;
- маршруты по подсетям зацепили лишний трафик;
- после перезагрузки не поднялся контейнер;
- весь офис случайно отправили в туннель без проверки.
Итог
Схема рабочая: Amnezia поднимает VPN на VPS почти автоматически, конфигуратор превращает .conf в команды для MikroTik, а роутер становится офисным VPN-шлюзом.
Но главный момент не в том, чтобы просто вставить команды. В режиме «весь не-РФ трафик через туннель» нужно внимательно проверить маршруты, FastTrack и особенно DNS. DNS-запросы должны идти через туннель, иначе получится некрасивый гибрид: трафик вроде бы через VPS, а имена резолвятся напрямую у провайдера.