WireGuard с минимальными AllowedIPs

Минимальные AllowedIPs проектируют не от готового примера, а от списка потоков. Для одного участника WireGuard сначала записывают, к каким туннельным адресам, отдельным узлам и удалённым сетям он действительно должен обращаться, а какие локальные и внешние направления обязаны остаться вне туннеля. Затем назначают этому участнику уникальный туннельный префикс узла и добавляют только те удалённые префиксы, для которых есть записанное назначение. Маршрут по умолчанию используют лишь тогда, когда полный туннель выбран осознанно отдельно для IPv4 или IPv6.

Причина такой осторожности в двойной роли AllowedIPs. При отправке этот список помогает интерфейсу выбрать участника по адресу назначения, а при приёме проверяет, допустим ли заявленный адрес источника для его открытого ключа. Поэтому широкая запись одновременно расширяет выбор маршрута и область принимаемых источников. Она не заменяет межсетевой экран, пересылку пакетов, проверку пользователя в приложении, настройку DNS или доступность выхода в другие сети.

Сначала схема сети и матрица потоков

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

После схемы составьте матрицу потоков. Для каждой строки укажите источник, назначение, семейство адресов, направление и ожидаемый результат. Формулировка «нужен доступ к удалённой сети» слишком широка. Лучше записать, нужен ли конкретный удалённый узел, вся подсеть или только туннельный адрес второго участника. Отдельно перечислите то, что должно остаться локальным: домашний шлюз, локальные устройства, обычный доступ в интернет или другие известные направления.

• Разрешённый поток: от какого устройства к какому адресу он должен проходить через туннель.
• Запрещённый поток: какой адрес не должен выбираться через этого участника и должен блокироваться при попытке доступа.
• Локальное исключение: какая сеть обязана продолжать обслуживаться локальным маршрутом.
• Семейство адресов: относится запись к IPv4, IPv6 или требует двух независимых проверок.
• Признак успеха: что именно наблюдается — маршрут, ответ удалённого узла или доступность приложения.

Риски, которые нужно записать до настройки

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

Запись по умолчанию для выбранного семейства охватывает любые назначения при отправке и любые заявленные источники при приёме от этого участника. Поэтому её нельзя считать только удобным способом добавить маршрут: она одновременно меняет границу выбора участника и границу проверки источника.

• Широкий префикс направляет к участнику больше назначений, чем указано в матрице потоков.
• Та же широкая запись допускает от участника больше адресов источника при приёме.
• Пересечение префиксов между участниками мешает однозначно объяснить, какой ключ связан с нужным направлением.
• Повторяющиеся частные IPv4-сети могут обозначать разные реальные сегменты по обе стороны туннеля.
• Отсутствие полного маршрута для IPv4 ничего не говорит о поведении IPv6, и наоборот.
• Успешное рукопожатие WireGuard не доказывает доступность нужного приложения.
• DNS-запросы могут идти по пути, отличному от ожидаемого пути прикладного трафика.
• Запись в AllowedIPs без отдельного правила межсетевого экрана может оставить лишний поток открытым.

Уникальный туннельный адрес для каждого участника

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

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

Как собрать минимальный список AllowedIPs

Список удобно собирать снизу вверх. Сначала внесите туннельный префикс самого участника. Затем добавляйте отдельные удалённые узлы, к которым нужен доступ. Если несколько нужных узлов образуют одну сеть и через участника должна быть доступна вся эта сеть, можно записать её префикс, но рядом в журнале следует указать назначение. Формулировка «на всякий случай» является причиной остановиться, а не расширять список.

1. Запишите уникальный туннельный префикс участника.
2. Добавьте точные префиксы удалённых узлов, подтверждённые матрицей потоков.
3. Заменяйте несколько узких записей подсетью только при необходимости доступа ко всей подсети.
4. Проверьте, не захватывает ли новая запись локальную сеть или направление другого участника.
5. Рассмотрите IPv4 и IPv6 как две отдельные задачи.
6. Маршрут по умолчанию добавляйте только после явного решения о полном туннеле для выбранного семейства.

У каждой записи AllowedIPs должно быть короткое объяснение: какой поток она обслуживает, почему её нельзя сузить и что должно остаться за её пределами.

Такой подход делает изменение проверяемым. Если назначение записи исчезло, её можно удалить и повторить проверки. Если появляется новый сервис, сначала добавляют строку в матрицу, затем минимальный префикс, а не расширяют существующую сеть до неопределённой границы.

IPv4 и IPv6 проверяют раздельно

Разделённый туннель нельзя оценивать только по одному семейству адресов. Отсутствие маршрута по умолчанию для IPv4 не ограничивает IPv6, если там задана широкая запись, и обратная ситуация столь же возможна. В матрице потоков должны быть отдельные строки для обоих семейств, даже когда приложение обычно открывается по одному имени.

Проверка строится по фактическому адресу назначения. Сначала фиксируют семейство и адрес, использованный для соединения, затем смотрят, как он сопоставляется с AllowedIPs и маршрутами системы. Если в схеме присутствуют оба семейства, одного успешного теста недостаточно: он подтверждает только проверенный путь, а второй путь остаётся неизвестным до отдельного наблюдения.

Пересечения между участниками и локальными сетями

Перед применением конфигурации соберите все префиксы AllowedIPs со всех участников одного интерфейса и сравните их между собой. Нужно найти полные совпадения, вложенные сети и слишком широкие записи. Отдельно сравните их с адресами локальных интерфейсов и сетей, доступных без туннеля. Цель проверки — увидеть, какой участник станет кандидатом для каждого назначения и не потеряется ли локальный путь.

Частные IPv4-диапазоны не являются глобально уникальными. Одинаковая сеть может существовать дома и на удалённой стороне, но обозначать разные устройства. Широкий префикс в AllowedIPs тогда не создаёт способа различить эти сегменты. До устранения неоднозначности нельзя считать настройку завершённой: требуется изменить адресный план, сузить доступ до различимых адресов или отказаться от потока, который невозможно однозначно направить.

Проверка отправки и приёма

После изменения нужно проверить обе стороны поведения AllowedIPs. Для отправки фиксируют адрес назначения и наблюдают, выбирается ли ожидаемый участник и маршрут. Для приёма проверяют, что пакет от участника принимается только с разрешённым адресом источника. Эти проверки связаны, но не взаимозаменяемы: правильный исходящий путь не доказывает, что входящий источник ограничен должным образом.

Журнал проверки должен связывать тест с конкретной строкой матрицы. Запишите семейство адресов, исходное устройство, назначение, ожидаемый путь, фактический результат и изменение конфигурации. Не ограничивайтесь отметкой «туннель работает». Такая отметка ничего не говорит о лишних маршрутах, запрещённых источниках, локальных исключениях или доступности нужного сервиса.

Межсетевой экран и пересылка настраиваются отдельно

AllowedIPs определяет связь адресных диапазонов с ключом и участвует в выборе участника, но не выражает всю сетевую политику. Если удалённому участнику нужен доступ только к одному сервису, межсетевой экран должен разрешить именно этот поток, а не всю сеть, которая оказалась достижима через маршрут. Проверка пользователя и его полномочий внутри приложения также остаётся отдельным уровнем.

Когда пакет должен пройти через узел WireGuard дальше в другую сеть, отдельно проверяют пересылку. Наличие удалённого префикса в AllowedIPs лишь делает участника кандидатом для соответствующего адреса; оно не включает пересылку и не создаёт выход в целевую сеть. Поэтому в журнале должны быть разные пункты: выбор участника, разрешение межсетевого экрана, пересылка и фактический ответ назначения.

DNS и транспортная точка не смешиваются с туннельным маршрутом

DNS проверяют как самостоятельный поток. Запрос имени может уйти вне туннеля, даже если последующее соединение идёт через него, или наоборот. Для каждого используемого сервера имён нужно определить ожидаемый путь и проверить оба семейства адресов. Нельзя выводить поведение DNS только из того, что веб-адрес открылся через нужного участника.

Транспортная точка WireGuard также находится на отдельном пути от туннельного назначения. Система должна доставлять транспортный пакет до неё по внешнему маршруту, а адреса за участником выбирать по правилам туннеля. Поэтому в схеме и журнале транспортный маршрут отмечают отдельно и проверяют, что изменение AllowedIPs не захватило его как обычное туннельное назначение.

Проверка после каждого изменения

Минимальная проверка включает не только положительный результат. Сначала подтвердите доступ к каждому разрешённому адресу. Затем попытайтесь обратиться к адресам, которые должны быть запрещены, и убедитесь, что ожидаемого доступа нет. После этого проверьте локальные исключения: домашние устройства и другие сети, оставленные вне туннеля, должны по-прежнему использовать локальный путь.

1. Проверить туннельный адрес участника.
2. Проверить каждый разрешённый удалённый узел или подсеть.
3. Проверить запрещённое направление, расположенное рядом с разрешённым по адресному плану.
4. Проверить локальную сеть, которую широкий префикс мог бы перехватить.
5. Повторить наблюдения отдельно для IPv4 и IPv6.
6. Проверить DNS-путь отдельно от прикладного соединения.
7. Убедиться, что транспортный путь до точки связи остаётся доступным вне туннеля.
8. Сопоставить результат с правилами межсетевого экрана и пересылки.

Один успешный обмен или наличие криптографической связи не является критерием завершения. Настройка принята только тогда, когда разрешённые потоки проходят, запрещённые не проходят, локальные исключения сохранены, оба семейства проверены, а каждая запись AllowedIPs имеет записанное назначение.

Критерии остановки и восстановления

Изменение следует остановить, если найдено пересечение, которое нельзя однозначно объяснить; если частная сеть совпадает на обеих сторонах; если неизвестно, каким семейством адресов пользуется приложение; если транспортный путь к точке связи начинает зависеть от туннеля; или если для расширения префикса нет конкретного потока. В такой ситуации не добавляют ещё более широкий маршрут, а возвращаются к схеме и адресному плану.

Для восстановления храните предыдущий список AllowedIPs, матрицу потоков и журнал последней успешной проверки. Откат должен возвращать не абстрактно «рабочий туннель», а известное состояние с подтверждёнными разрешёнными и запрещёнными потоками. После отката повторяют те же наблюдения: доступ к нужным адресам, отсутствие доступа к лишним, сохранность локальных маршрутов, отдельное поведение IPv4, IPv6 и DNS.

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

Итоговая схема решения

Минимальные AllowedIPs — это набор точных утверждений о том, какие адреса связаны с конкретным открытым ключом. Начните с уникального туннельного префикса узла, затем добавьте только необходимые удалённые узлы и сети. Перед применением найдите пересечения, сравните записи с локальными частными сетями и отдельно оцените IPv4 и IPv6. Маршрут по умолчанию считайте осознанным переходом к полному туннелю для соответствующего семейства, а не удобной строкой из примера.

Завершает работу не успешное рукопожатие, а журнал доказательств: ожидаемый участник выбирается при отправке, недопустимый источник не принимается, межсетевой экран разрешает только нужные потоки, пересылка включена лишь там, где она требуется, DNS идёт по задуманному пути, а локальные исключения остаются локальными. Такая последовательность сохраняет разделённый туннель разделённым и делает восстановление воспроизводимым.