AllowedIPs — это список маршрутизации, а не правило брандмауэра
Он выбирает пира для исходящего трафика и проверяет входящие источники. Это не список доступа, и отключение управления маршрутами не исправляет разделённый туннель.
Большинство читают AllowedIPs как список разрешений — набор адресов, которым можно подключаться к пиру, примерно как правило брандмауэра, написанное для туннеля. Это не так. Поле — таблица маршрутизации, работающая в обоих направлениях: она выбирает пира для исходящего пакета и проверяет источник входящего. Чтение его как списка доступа создаёт конфигурации, которые направляют трафик, которого никто не просил.
Одно поле, два читателя: выбор исходящего и проверка источника
На клиенте префиксы решают, какие назначения идут к этому пиру, а какие остаются в обычной сети. Поэтому запись для 0.0.0.0/0 захватывает каждое назначение IPv4, и поэтому импорт профиля полного туннеля отправляет обычный просмотр через удалённую машину. Узкие записи делают наоборот: маршрутизируют только перечисленные сети, а всё остальное оставляют на месте. Раздел о маршрутизации криптоключей в документации WireGuard излагает обе задачи в одном месте: выбор исходящего пира и проверку входящего источника.
На сервере то же поле описывает, какие адреса источника может использовать каждый пир. Это криптографическая проверка, а не фильтр пакетов: пакет, внутренний источник которого не совпадает со списком пира, отбрасывается внутри WireGuard ещё до того, как его увидит любой брандмауэр хоста. Обе задачи делят один список, и именно поэтому список, скопированный откуда-то ещё, ведёт себя неправильно там, где вы этого не учли.
Блок клиента — это место, где начинается большая часть этой путаницы. Разделённый туннель перечисляет удалённые сети, а полный туннель — то же поле с префиксом по умолчанию:
[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24
[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0
Обе формы самодостаточны, и это альтернативы, а не шаги. Первая отправляет через туннель только те две сети; вторая отправляет каждое назначение, а запись ::/0 добавляет IPv6 к стандартному IPv4. Какую бы вы ни выбрали, эти префиксы — всё решение о маршрутизации для этого пира, как только wg-quick начнёт устанавливать маршруты.
Хабу нужен другой список
Хаб перечисляет адрес туннеля каждого клиента как префикс хоста, плюс любую сеть, которая действительно находится за этим клиентом. Копирование широкого списка клиента на каждого пира хаба сообщает хабу, что многие пиры могут использовать одни и те же адреса как источник, а это не план адресации. Поле Endpoint относится совсем к другому уровню: оно называет внешний адрес и порт пира, но никогда — назначение внутри туннеля.
[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24
Префикс хоста несёт адрес туннеля, а префикс сети несёт то, что находится за клиентом, и нужны оба. Без префикса хоста хаб не может вернуть собственный трафик клиента, а без префикса сети LAN за ним остаётся недоступной; пир, за которым ничего нет, получает только префикс хоста.
Пропуск установки маршрутов оставляет разрыв
wg-quick, помощник, поднимающий интерфейс из файла конфигурации, устанавливает адреса интерфейса и маршруты как часть этой работы. Установка Table = off говорит помощнику пропустить работу с маршрутами, которая не устанавливает замены и не делает частную сеть доступной. Когда автоматические маршруты уже выполняют работу, указание нужных префиксов — более ясная конфигурация. Отключить управление маршрутами и оставить замену ненаписанной — это не дизайн, а упущение.
Базовый инструмент wg ведёт себя иначе: он настраивает интерфейс и никогда не трогает маршруты, поэтому установке, построенной прямо на нём, нужны собственные команды маршрутов. Инструкции, написанные для одного инструмента, могут выглядеть неверно, когда их выполняют с другим. Успешный ping — тоже слабое доказательство, потому что он проверяет один путь, а не каждый нужный путь приложения.
DNS и IPv6 решаются отдельно
Проверьте адрес DNS-сервера, который объявляет туннель, и убедитесь, что через выбранные префиксы существует маршрут к этому адресу. Настройка резолвера не делает резолвер доступным, а сужение туннеля может тихо убрать маршрут, который к нему вёл. Осмотрите и IPv6 отдельно, потому что корректное разделение IPv4 ничего не говорит о маршруте по умолчанию IPv6, который по-прежнему указывает на физическое соединение. Три отдельных решения могут измениться сразу, когда вы правите один блок пира.
Затем откройте один частный ресурс и один обычный сайт из известной начальной конфигурации. Если ресурс отвечает и просмотр по-прежнему выходит через локальное соединение, разделение делает то, что вы просили. Если просмотр ломается в тот же момент, туннель забрал маршрут по умолчанию, и список префиксов — это место, где нужно смотреть.