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

Сначала определите список префиксов

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

Если в списке есть 0.0.0.0/0 или ::/0, вы построили полный туннель и должны это сказать, потому что режимы отказа и ожидания от DNS различаются.

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

Конфигурация клиента: пир, AllowedIPs, DNS

Блок интерфейса клиента содержит его собственный адрес туннеля и закрытый ключ. Блок пира содержит открытый ключ сервера, конечную точку и префиксы из первого шага:

[Interface]
Address = 10.9.0.2/32
PrivateKey = <client-private-key>
DNS = 10.20.0.53

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16, 10.30.0.0/24
PersistentKeepalive = 25

AllowedIPs на клиенте — это набор удалённых назначений, а не собственный адрес клиента. Строка DNS действует только через интеграцию резолвера в wg-quick, поэтому хост без поддержки resolvconf или systemd-resolved проигнорирует её. PersistentKeepalive поддерживает сопоставление NAT живым и не нужен на прямом пути.

Прокомментируйте каждый префикс сервисом, которому он служит, иначе следующая правка станет догадкой.

Конфигурация сервера: противоположный взгляд

На сервере запись пира представляет клиента, поэтому её AllowedIPs — это адрес туннеля клиента, обычно /32. Это не офисная подсеть. Копирование списка клиента в запись сервера — самая частая ошибка раздельного туннеля, и она либо расширяет доступ, либо ломает внутреннюю проверку источника при рукопожатии.

Собственный адрес интерфейса сервера и маршруты, которые ему нужны в сторону офиса, отделены от любой записи пира.

Два файла, два взгляда, один набор префиксов, разделённый между ними.

Поднимите его и прочитайте маршруты

Запустите интерфейс поддерживаемым менеджером, а затем посмотрите, что он установил, а не что вы задумали. wg-quick выводит маршруты из AllowedIPs; если профиль задаёт Table = off, ничего не устанавливается и маршрутизация остаётся за вами. Прочитайте маршрут для каждого префикса и убедитесь, что он указывает на интерфейс WireGuard. Пустой список маршрутов обычно означает, что применённый профиль — не тот, который вы редактировали.

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

Запишите точную команду, которую использовали, потому что следующий человек запустит её под давлением.

Проверьте обе стороны, затем зафиксируйте откат

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

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

Держите одного владельца конфигурации, потому что два менеджера, создающие один и тот же интерфейс, рано или поздно разойдутся. Руководство wg-quick описывает поведение маршрутов и DNS, которое он обеспечивает.

Похожие статьи