OPNsense как VPN-шлюз: настройка WireGuard

MAATRIX

Если у вас уже стоит OPNsense как основной файрвол — заводить отдельный VPN-сервер рядом бессмысленно: WireGuard встроен в дистрибутив и поднимается прямо в веб-интерфейсе, без консоли и правки конфигов вручную. Но интерфейс OPNsense устроен иначе, чем у pfSense, и если вы переходите с одного на другой по памяти — легко потеряться в терминологии. Ниже — рабочая настройка WireGuard-шлюза на OPNsense с объяснением, где и почему GUI ведёт себя не так, как в pfSense.

Local и Endpoint вместо Tunnel и Peer — разная терминология, похожая суть

В OPNsense вся настройка WireGuard живёt в разделе VPN → WireGuard и делится на две сущности:

• Local — это локальный интерфейс WireGuard на самом OPNsense: свой приватный ключ, порт, адрес в тоннельной подсети. Условно это аналог [Interface] из обычного wg0.conf.
• Endpoint — удалённый пир: его публичный ключ, разрешённые адреса (AllowedIPs), опционально — адрес и порт, если он сам инициирует соединение. Это аналог блока [Peer].

В pfSense (пакет pfSense-pkg-WireGuard) те же сущности называются Tunnels и Peers, и логика похожая: тоннель — это локальный интерфейс, пир — удалённая сторона. Разница не в смысле, а в деталях реализации, и первая заметная — это то, как оба продукта группируют интерфейсы для файрвола.

В OPNsense все Local-инстансы автоматически становятся членами одного виртуального интерфейса WireGuard (Group) — на него можно повесить один общий набор правил файрвола сразу для всех WireGuard-тоннелей. В pfSense такого группового интерфейса нет: каждый Tunnel нужно вручную assign'ить как отдельный интерфейс (Interfaces → Assignments) и заводить правила для каждого отдельно. Если у вас несколько WireGuard-шлюзов (например, для сотрудников и отдельно для site-to-site с другим офисом), в OPNsense управлять общими правилами проще — либо один groupinterface на всё, либо всё равно assign'ите Local отдельно, если нужны разные политики.

Установка и выбор бэкенда: ядро или wireguard-go

Плагин os-wireguard в современных версиях OPNsense идёт в комплекте с системой — отдельно ставить пакет обычно не нужно, но включить сам модуль VPN нужно вручную:

1. VPN → WireGuard → Settings → включите Enable WireGuard.
2. Там же выберите бэкенд: kernel (модуль if_wg в ядре FreeBSD) или wireguard-go (userspace-реализация на Go).

Это стоит объяснить отдельно, потому что решение здесь не всегда очевидное. Родная реализация WireGuard в ядре FreeBSD — это не код оригинального проекта WireGuard, а отдельная переработка под FreeBSD, и в своё время независимые исследователи указывали на проблемы в её качестве. Команда OPNsense в ответ добавила поддержку wireguard-go — эталонной userspace-реализации на Go от самого проекта WireGuard — как более консервативный по безопасности вариант. Практическое следствие: kernel-бэкенд обычно быстрее (меньше накладных расходов на переключение контекста), wireguard-go — медленнее, но ближе к оригинальному коду. Точных цифр по разнице производительности не привожу — она сильно зависит от процессора сервера и профиля трафика; если для вас критична пропускная способность, стоит просто прогнать оба варианта на своём железе и сравнить самостоятельно. Для большинства сценариев (доступ сотрудников, site-to-site между офисами) разница на практике не ощущается.

В pfSense такого выбора бэкенда в интерфейсе нет — там используется одна реализация, без переключателя kernel/userspace.

Создаём сервер: Local-инстанс

Идём в VPN → WireGuard → Local, нажимаем +:

• Name — произвольное имя, например wg-office.
• Public Key / Private Key — оставьте пустыми, OPNsense сгенерирует пару автоматически при сохранении (публичный ключ появится в списке — его нужно будет передать клиентам).
• Listen Port — порт UDP, по умолчанию предлагается 51820, если ставите несколько инстансов — разносите порты.
• Tunnel Address — адрес интерфейса в тоннельной подсети, например 10.10.20.1/24.
• DNS Servers — если хотите раздавать клиентам конкретный DNS через тоннель.

Сохраняете — интерфейс wg0 (или следующий свободный) появляется в системе. Дальше идите в Interfaces → Assignments, найдите WireGuard-инстанс в списке, назначьте ему имя (например WG_OFFICE) и включите — без этого шага правила файрвола на конкретный тоннель вешать не получится, а именно этот момент чаще всего забывают при первой настройке. Общую логику установки самого WireGuard как протокола — независимо от платформы — разбирали в статье про установку WireGuard на VPS, если нужен более низкоуровневый разбор ключей и wg-quick.

Добавляем пиров: клиенты и site-to-site

Раздел VPN → WireGuard → Endpoints, кнопка + — здесь два разных сценария заводятся одинаковым способом, разница только в полях.

Клиент (remote access) — сотрудник с телефоном или ноутбуком:

• Name — например laptop-ivan.
• Public Key — публичный ключ, сгенерированный на стороне клиента.
• Allowed IPs — 10.10.20.2/32: клиенту разрешён только его собственный адрес в тоннеле.
• Endpoint Address/Port — оставляем пустым, клиент подключается сам, инициатор — он.

Site-to-site с другим офисом или сервером:

• Allowed IPs — не /32, а вся сеть на той стороне, например 10.20.0.0/24.
• Endpoint Address/Port — публичный адрес и порт удалённого шлюза, если инициатором должен выступать этот OPNsense.
• Keepalive Interval — 25 секунд, если удалённая сторона может быть за NAT.

После создания Endpoint возвращаетесь в Local-инстанс и добавляете этот Endpoint в список Peers — в OPNsense привязка делается именно так, через редактирование Local, а не автоматически при создании Endpoint. Общий разбор разницы между схемой с одним клиентом на /32-адрес и схемой с целой подсетью — в статье про site-to-site VPN между офисами на WireGuard.

Firewall-правила и NAT

WireGuard в OPNsense не открывает порт сам по себе — нужны явные правила, и здесь два места, где их обычно не хватает новичкам:

1. WAN — правило, разрешающее входящий UDP на порт, указанный в Local (например 51820). Без этого пир снаружи вообще не достучится до сервера.
2. Группа WireGuard (или конкретный assigned-интерфейс) — правило, разрешающее трафик из тоннеля дальше в локальную сеть. По умолчанию OPNsense, как и pfSense, блокирует всё, что не разрешено явно.

Пример: правило на WAN — IPv4 UDP, source any, destination WAN address, destination port 51820, allow. Правило на WG_OFFICE (или на группе WireGuard) — IPv4, source WG_OFFICE net, destination any, allow, если клиентам нужен полный доступ в локалку и в интернет через шлюз.

Если клиентам нужен доступ в интернет через тоннель (полный туннелинг), включите NAT-маскарадинг для тоннельной подсети — Firewall → NAT → Outbound, режим Hybrid или Manual, добавьте правило с source 10.10.20.0/24 и interface WAN. В pfSense этот шаг идентичен по смыслу, но название вкладок NAT местами отличается — логика outbound NAT в обоих продуктах унаследована от общего предка (m0n0wall/pfSense), так что при переходе с pfSense эта часть покажется знакомой почти один в один.

Отдельно проверьте флажок Disable Route Configuration в настройках Local — если он снят, OPNsense сам добавит системные маршруты по Allowed IPs пиров. Обычно это удобно и его стоит оставить включённым (маршруты создаются автоматически), но если вы вручную управляете таблицей маршрутизации через отдельные статические маршруты — галку стоит взвести, чтобы не было конфликтов.

Мониторинг, диагностика и типичные грабли

Несмотря на GUI, под капотом это обычный WireGuard, поэтому диагностика через консоль работает так же, как на Linux-сервере:

wg show

В выводе смотрите на latest handshake — если время растёт (соединение "протухло") или строки нет вообще, тоннель не поднимается на уровне UDP: чаще всего это закрытый порт на WAN-правиле, неверный публичный ключ у пира или NAT провайдера, который блокирует нестандартный UDP-порт.

Перезапустить сервис из консоли без пересборки конфига через GUI:

configctl wireguard restart

Частые грабли именно на OPNsense:

• Забыли assign интерфейс. Local создан, ключи сгенерированы, но правила файрвола на вкладке для этого интерфейса просто не существует в списке — потому что интерфейс не назначен в Interfaces → Assignments.
• Endpoint не привязан к Local. Создали пира, но забыли добавить его в список Peers внутри Local-инстанса — тоннель молчит, хотя обе стороны настроены вроде бы верно.
• NAT/Outbound не тронут после смены режима. Если раньше стоял Automatic outbound NAT, а вы переключились на Hybrid ради других задач — правило для WireGuard-подсети нужно добавить руками, иначе клиенты потеряют выход в интернет через тоннель.
• DNS не резолвится у клиентов, хотя пинг по IP работает — не указан DNS Server в Local или клиентское приложение не применяет DNS из конфига (актуально для некоторых мобильных клиентов).

Если хендшейк есть, а трафик всё равно не ходит — это почти всегда про Allowed IPs или файрвол, а не про сам WireGuard; разбор похожей логики (применимой и к OPNsense, раз протокол один и тот же) — в статье про случай, когда хендшейк есть, а трафика нет. Для постоянного контроля состояния портов и хендшейков полезно вынести отдельный внешний мониторинг, а не полагаться только на дашборд самого OPNsense — если сервер целиком станет недоступен, его собственный интерфейс мониторинга тоже отвалится вместе с ним.

Частые вопросы