Добрый день. Да — такое можно реализовать. Смысл решения в том, чтобы трафик, который приходит к вашему роутеру на его WireGuard‑сервер (внешние клиенты), был переадресован (направлен) через исходный WireGuard‑клиент (тот, который подключается к удалённому серверу). Для этого нужно 3 вещи:
1) обеспечить маршрутизацию трафика с подсети WG‑сервера через интерфейс WG‑клиента (policy routing или сделать WG‑клиент «дефолтным» шлюзом);
2) разрешить форвардинг между интерфейсами в фаерволе;
3) при необходимости выполнить NAT (masquerade) исходящих пакетов на интерфейсе WG‑клиента, если удалённый сервер не знает маршрута назад к подсети клиентов.
Ниже — пошагово с примерами команд и пояснениями.
Пример условий (подставьте свои):
- wg0 — интерфейс WireGuard (клиент), который CONNECT к удалённому серверу;
- wg1 — интерфейс WireGuard (сервер) на вашем роутере, в который подключаются клиенты;
- подсеть wg1 peers: 10.66.66.0/24 (клиенты, которые приходят к вашему WG‑серверу).
1) Включить форвардинг (обычно уже включён в Keenetic):
- net.ipv4.ip_forward = 1
2) Организовать маршрутизацию из подсети 10.66.66.0/24 через интерфейс wg0.
Вариант A — если вы хотите направлять только трафик от клиентов wg1 через туннель:
- добавить правило политики маршрутизации:
ip rule add from 10.66.66.0/24 table 200
- добавить маршрут в эту таблицу через wg0:
ip route add default dev wg0 table 200
Вариант B — если вы установили в настройках соединения wg0 «Use this connection to access the Internet» (или AllowedIPs = 0.0.0.0/0 на стороне клиента), тогда маршруты могут добавляться автоматически и можно не делать ip rule.
3) Разрешить форвардинг в iptables (пример):
iptables -A FORWARD -i wg1 -o wg0 -s 10.66.66.0/24 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wg0 -o wg1 -d 10.66.66.0/24 -m conntrack --ctstate ESTABLISHED -j ACCEPT
4) NAT (если удалённый сервер не знает маршрут к 10.66.66.0/24 и вы не хотите/не можете добавлять маршрут на стороне удалённого сервера):
iptables -t nat -A POSTROUTING -o wg0 -s 10.66.66.0/24 -j MASQUERADE
Без NAT нужно, чтобы удалённый сервер WG знал маршрут назад к 10.66.66.0/24 (например, в AllowedIPs удалённого сервера указать 10.66.66.0/24 и чтобы удалённый сервер маршрутизировал их через ваш peer‑IP). Тогда MASQUERADE не нужен.
5) Настройки в Web‑интерфейсе Keenetic:
- В разделе WireGuard проверьте имена интерфейсов и подсети.
- В «Маршрутизация / Маршруты по правилам» (Policy routing) можно добавить правило «источник = подсеть wg‑сервера -> использовать соединение wg‑клиент». Это GUI‑аналог ip rule + ip route.
- В разделе «Фаервол / Правила доступа» добавьте разрешения на форвард между зонами/интерфейсами (vpn → internet / vpn → wg0 и обратно).
- Если Keenetic позволяет включить «masquerade» для конкретного соединения — включите для wg0, иначе используйте командный iptables.
6) Сохранение правил:
- На Keenetic команды ip/iptables из консоли не будут сохраняться после перезагрузки, поэтому добавьте нужные команды в «Startup script» (Система → Скрипты/Startup) либо реализуйте через GUI (правила фаервола/маршрутизация по правилам/маскарадинг), чтобы изменения были постоянными.
Итоговые примерные команды (подставьте свои интерфейсы и подсети):
ip rule add from 10.66.66.0/24 table 200
ip route add default dev wg0 table 200
iptables -A FORWARD -i wg1 -o wg0 -s 10.66.66.0/24 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wg0 -o wg1 -d 10.66.66.0/24 -m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o wg0 -s 10.66.66.0/24 -j MASQUERADE
Если хотите — пришлите конкретные подсети/имена интерфейсов (какой интерфейс у WG‑клиента и WG‑сервера, какие подсети у клиентов), и я подготовлю точный набор команд/настроек для вашего Keenetic.