AllowedIPs в WireGuard: понятное объяснение с примерами
Обновлено: октябрь 2026
AllowedIPs — самый важный и самый недооценённый параметр WireGuard: именно он решает, какой трафик уйдёт в туннель, а какой из туннеля будет принят. Разбираем, как он работает с двух сторон соединения, что означают типовые значения и как их подобрать для небольшой компании. Примеры — в формате wg-quick (WireGuard 1.0, актуальные Linux-дистрибутивы).
ВАШЕЙ ИНФРАСТРУКТУРЫ
Что делает AllowedIPs: маршрутизация и фильтр входящего
У AllowedIPs две роли одновременно, и это главная причина путаницы. На отправке параметр работает как маршрут: пакет уходит тому пиру, в чей список AllowedIPs попадает адрес назначения. На приёме — как фильтр: от пира принимаются только те пакеты, чей адрес отправителя входит в его AllowedIPs, всё остальное молча отбрасывается.
Такая схема в документации WireGuard называется cryptokey routing: система знает не «куда идёт маршрут», а «какому ключу принадлежит какой адрес». Поэтому нельзя «добавить маршрут в обход» — пакет просто не будет принят пиром, если его источник не входит в AllowedIPs этого пира. И наоборот: если адрес назначения есть в AllowedIPs, ядро отправит пакет именно этому пиру, даже если где-то в системе прописан другой маршрут.
На клиентах с wg-quick есть практическое следствие: утилита не только передаёт AllowedIPs интерфейсу, но и создаёт по ним системные маршруты — поэтому на клиенте список выглядит и ведёт себя как таблица маршрутизации. На сервере роль другая: там AllowedIPs каждого пира отвечает на вопрос «адреса каких клиентов я признаю за этим ключом».
Стоит понимать, что двойная роль — не баг интерфейса, а сознательный дизайн: WireGuard принципиально не выдаёт трафик пиру, чей ключ не подтверждён, и не принимает чужое. Из этого следует и простое правило чтения любого конфига: сначала смотрите на AllowedIPs обеих сторон, и только потом на остальное. Девять из десяти «WireGuard не работает» заканчиваются на строке, где вместо офисной подсети стоит 0.0.0.0/0 или забыт адрес клиента.
Разбор типовых значений
Одни и те же записи встречаются почти в каждом конфиге, смысл у них стоит один раз проговорить.
/32 для клиента. На сервере каждый пир получает AllowedIPs с единственным адресом — туннельным адресом этого клиента. Запись 10.8.0.10/32 означает: пакеты с адресом отправителя 10.8.0.10 принимаются только от этого ключа, а пакеты для 10.8.0.10 уходят ему. Двум пирам один адрес дать нельзя — последний в списке «победит», первый молча перестанет работать.
0.0.0.0/0 — полный туннель. Все адреса назначения уходят в туннель: весь трафик устройства идёт через офис. Применяется, когда нужен контроль всего трафика — на служебных ноутбуках, в недоверенных сетях. Цена: интернет-трафик сотрудника расходует канал офиса, а локальные устройства — домашний принтер, камера — остаются вне туннеля и перестают быть доступны напрямую.
Split-tunnel по RFC1918. Список частных сетей — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — отправляет в туннель только «серые» адреса: офисные подсети и туннельную. Интернет идёт напрямую, мимо туннеля. Для небольшой компании это чаще всего золотая середина: доступ к ресурсам есть, канал не греется, но стоит помнить, что защита при этом распространяется только на офисный трафик.
Точечный вариант того же принципа — перечислить только нужные подсети офиса: 192.168.10.0/24 для файлового сегмента и туннельную 10.8.0.0/24. Чем короче список, тем предсказуемее поведение, и собрать такой список из разрозненных подсетей помогает калькулятор — о нём ниже.
Отдельного упоминания заслуживает вариант «всё, кроме» — полный туннель, из которого вычтены домашние или служебные сети. Запись получается длинной: дополнение к исключённой подсети — это несколько десятков диапазонов, которые вручную не считают. Калькулятор в режиме «всё, кроме» делает ровно это: вычитает список из 0.0.0.0/0 и возвращает готовые префиксы для блока [Peer].
Типовые сценарии небольшой компании
Две конфигурации закрывают большинство запросов «настроить WireGuard в офисе». Допустим для обеих: офисная сеть 192.168.10.0/24, туннельная — 10.8.0.0/24.
Сотрудник из дома: учётная база и файлы. На клиенте туннель поднимает wg-quick-конфиг:
[Interface]
PrivateKey = <закрытый ключ сотрудника>
Address = 10.8.0.10/32
[Peer]
PublicKey = <публичный ключ сервера>
Endpoint = vpn.company.ru:51820
AllowedIPs = 10.8.0.0/24, 192.168.10.0/24На сервере этому сотруднику соответствует ровно одна строка:
[Peer]
PublicKey = <публичный ключ сотрудника>
AllowedIPs = 10.8.0.10/32Сотрудник открывает 1С и сетевые папки по офисным адресам — этот трафик идёт через туннель; остальное ходит напрямую. На сервере строка 10.8.0.10/32 гарантирует: никто с чужим ключом не притворится этим сотрудником.
Честная оговорка про split-tunnel: защита распространяется только на офисный трафик. В дороге, из кафе или гостевого Wi-Fi устройство само остаётся открытым локальной сети, в которую попало. Для личных ноутбуков сотрудников это приемлемый компромисс; для служебных машин с чувствительными данными обычно выбирают полный туннель.
Обратите внимание: в списке клиента стоит и туннельная сеть 10.8.0.0/24, хотя про неё обычно вспоминают в последнюю очередь. Без неё клиент не сможет обратиться к серверу по его туннельному адресу — а с ней вся диагностика сводится к простым пингам.
Подрядчик видит только один сервис. Пир подрядчика на сервере получает адрес 10.8.0.50/32 — как и любой другой. Разница на его стороне: в AllowedIPs попадает адрес одного сервиса, например 192.168.10.20/32 для сервера видеонаблюдения. Даже без файрвола подрядчик физически не отправит в туннель трафик ни к чему другому — маршрут ведёт только туда. Это не отменяет файрвол на самом сервисе, но сужает поверхность ещё на входе.
Частые ошибки и как их ловить
- Один и тот же AllowedIPs у двух пиров. Классика: скопировали блок конфига, забыли поменять адрес. Симптом — один из клиентов «то работает, то нет»: пакет уходит последнему добавленному пиру. Лечится дисциплиной «адрес — один на пир».
- Клиент не вписан в AllowedIPs на сервере. Handshake проходит, обмен идёт, но ответы до клиента не доходят — сервер отбрасывает их по проверке источника. В логе WireGuard это выглядит как отказ по allowed ips.
- Ожидание, что AllowedIPs на сервере «открывает» клиенту ресурсы. На сервере параметр про адреса клиентов, а не про их права доступа. Что клиент увидит внутри офиса после туннеля — определяют маршруты и файрвол, AllowedIPs там лишь закрывает направление.
- 0.0.0.0/0 там, где нужен split-tunnel. Симптом появляется в быту: «дома через VPN медленный интернет и принтер не работает». Проверьте список на клиенте.
- RouterOS: ждать маршруты от allowed-address. В RouterOS v7 параметр allowed-address выполняет обе роли WireGuard, но системные маршруты по нему не создаются — их вносят отдельно в /ip route. Первое, что стоит проверить, когда «туннель есть, а офис не пингуется».
Базовая диагностика собирается тремя командами: wg show
показывает свежесть handshake и счётчики передачи, wg show
wg0 allowed-ips — что реально применено к интерфейсу, а
проверка «пингую туннельный адрес сервера, затем офисный ресурс»
отделяет работающий туннель от работающих маршрутов. Если первое
пингуется, а второе нет — проблема в AllowedIPs или файрволе, а
не в ключах.
| Проверка | Если не работает |
|---|---|
| Пинг туннельного адреса сервера | Ключи, Endpoint или AllowedIPs клиента — туннель не установлен |
| Пинг офисного ресурса за сервером | AllowedIPs клиента без нужной подсети, маршруты или файрвол на сервере |
| Интернет при полном туннеле | NAT или пересылка на сервере — трафик доходит, но не выходит |
Калькулятор AllowedIPs
Аккуратная строка AllowedIPs — это битовая математика: подсети объединяются, пересечения убираются, дополнение к списку считается через инверсию. Делать это руками незачем: в нашем калькуляторе AllowedIPs список подсетей собирается в готовую строку конфига — режим «включить» сливает смежные блоки, режим «всё, кроме» вычитает список из полного туннеля. Вычисление идёт в браузере, конфиг никуда не отправляется.
Оба режима повторяют сценарии из этой статьи: «включить» — для split-tunnel со списком офисных подсетей, «всё, кроме» — для полного туннеля с исключениями. Результат копируется в блок [Peer] как есть; перед боевой настройкой его, как и любой конфиг, стоит проверить на отдельной тестовой машине.
Собрать строку AllowedIPs
Вставьте подсети списком — калькулятор вернёт минимальную строку для блока [Peer] в конфиге WireGuard. Открыть калькулятор.
Частые вопросы
Чем AllowedIPs отличается от обычных маршрутов?+
Маршрут говорит, куда отправить пакет; AllowedIPs вдобавок отвечает, какому ключу этот пакет доверять — и в обе стороны. Поэтому «просто добавить маршрут» нельзя: пир отбросит пакет, если источник не входит в его AllowedIPs.
Можно ли менять AllowedIPs без разрыва туннеля?+
Да. Изменение через wg set применяется к живому
интерфейсу мгновенно. Перечитывание всего конфига через
wg-quick пересоздаёт интерфейс — это короткий разрыв, на
практике незаметный для файловых операций, но не для
удалённой сессии.
Что будет, если AllowedIPs двух пиров пересекаются?+
При точном совпадении префикса работает только один из пиров — предсказуемость теряется, поэтому пересечения в конфиге не допускают. Частичное перекрытие решается выбором наиболее специфичного префикса, но опираться на это сознательно не стоит: чище разнести адресацию заранее.
AllowedIPs заменяет файрвол?+
Нет, это разные слои. AllowedIPs решает, каким ключом какой адрес достанется, и не знает про порты и пользователей. Файрвол на ресурсе решает, что делать с тем, кто уже добрался. Рабочая связка — суженный AllowedIPs плюс правила на самом сервисе, а не одно вместо другого.
А как же IPv6?+
Точно так же: IPv6-префиксы перечисляются в том же списке через запятую, полный туннель записывается как ::/0. Забытый IPv6 при полном туннеле — частая дыра: трафик просто уходит мимо туннеля по «обычному» маршруту.
Связанные материалы
Если туннель ещё не поднят или список адресатов растёт — от схемы адресации до сервера и политик доступа это направление VPN и удалённого доступа. Пошаговая настройка самого сервера — от установки и ключей до раздачи доступа сотрудникам — в статье о настройке WireGuard-сервера.