Не работает nat в wireguard

Может просто необходимые маршруты (10.9.0.0/24, 192.168.0.0/24) отсутствуют на какой-либо из сторон?

например ?
я уже весь мозг сломал и не представляю каких ещё маршрутов где может не хватать.

rp_filter ?

На проблемном интерфейсе точно не двушка ли нужна?

P.S. особо не вникал, по идее двушка не нужна. Но, тем не менее. Можно и нужно включать дебаг ядра. Я в своё время так только и отыскал что мне эта сраная двушка нужна была

Не эксперт, но вопрос доступа в lan тоже не мог осилить некоторое время. Мои конфиги с нормальным доступом в lan и wan:

Сервер

Address = 172.16.1.1/24
ListenPort = 41194
PrivateKey = ***
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o br0 -j MASQUERADE

[Peer]
# NameUser
PublicKey = ***
AllowedIPs = 172.16.1.3/32

Клиент

PrivateKey = ***
Address = 172.16.1.3/24
DNS = 172.16.0.1,1.1.1.1

[Peer]
PublicKey = ***
Endpoint = 22.23.24.25:41194
AllowedIPs = 0.0.0.0/0

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

Вы специально создавали бридж, чтобы это всё заработало или бридж к делу не относится ?

Мост к делу не относится. Он был добавлен позже(после того как решил вопрос с доступом в lan) для виртуальной машины. Сам же ‘сервер’ wireguard на основной системе.

net.ipv4.conf.all.rp_filter = 2 делу не помог.
или нужно включить только на отдельном интерфейсе ?

В таком случае, это ничем не отличается от того что у меня.
AllowedIPs = 0.0.0.0/0 на клиенте включать пробовал, это не помогает.

Кое что вспомнил, но это на арче всё крутится. Создал файл /etc/sysctl.d/wg.conf с единственной строчкой net.ipv4.ip_forward = 1.

это первым делом было включено в /etc/sysctl.conf.

В тему не вникал, так как не за компьютером. Если до завтра не решишь попробуем списаться и решить проблему. Вот тут моя история перехода на wg: https://habr.com/ru/post/486864/

может чем-то поможет

Ничего нового для меня там нет, так и же как и в статье из комментариев. Судя потому что у всех во всём мире это просто работает, решение должно быть весьма элементарным.
У меня это выглядит так, будто неполноценно работает маскарадинг.

Включай дебаг на уровне iptables (–LOG - с префиксом), включай логи ядра, включай по-возможности префиксы в логах что бы удобней искать было где теряется, я матерился капец, но вот до того что надо с сраной двойкой разбираться долго шел, и когда сюда постил логи, вот ребята на ЛОРе подсказали)

1. Существует способ логгировать вообще все события ? Я знаю только способ логгирования срабатывания конкретных правил.
2. В логах ядра будет много мусора, на что желательно обращать внимание, есть какие-то фишки, позволяющие упростить мою задачу ?

Если поставить логгрование только на forward и postrouting, то логов не появляется ни при каких обстоятельствах.

-A FORWARD -i wg0 -j LOG
-A POSTROUTING -o ens18 -j LOG

Если задать на клиенте 0.0.0.0/0 и мониторить построутинг wan порта, то начинают появляться пакеты. Но какого лешего wg привязался только к одному интерфейсу ?
Почему если у меня в системе указаны более одного шлюза, wg не работает ?

Сейчас не помню как я уже точно мониторил, но, обычно, я делаю примерно так: пытаютсь прогнать большой трафик, смотрю статистику в iptables, вижу что счетчик напр. в postrouting не растет, ну начинаю дебажить до построутинга… Как-то так.

А что значит более одного шлюза? Отличия в метриках есть по этим шлюзам?

Покажи мне маршруты на сервере и на клиенте, а также MTU на интерфейсах WG и интерфейсах с default gw

lan,wan - 1500
wg0 - 1420
на сервере

default via 200.0.0.1 dev ens19 proto kernel onlink
10.9.0.0/24 dev wg0 proto kernel scope link src 10.9.0.1
192.168.0.0/24 dev ens18 proto kernel scope link src 192.168.0.82
200.0.0.0/28 dev ens19 proto kernel scope link src 200.0.0.13

default via 192.168.88.1 dev wlp3s0 proto dhcp metric 600 
10.9.0.0/24 dev wg0-client scope link 
192.168.88.0/24 dev wlp3s0 proto kernel scope link src 192.168.88.215 metric 600 
192.168.0.0/24 dev wg0-client scope link

Вообще хотел попробовать метрики навесить, но руки не дошли. Но у openvpn нет проблем в такой конфигурации.

А ip addr можешь ещё там и там показать?

Сервер:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.82/24 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 fe80:xx:xx:xx:xx:xx:xx/64 scope link
       valid_lft forever preferred_lft forever
3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 200.0.0.13/28 scope global ens19
       valid_lft forever preferred_lft forever
    inet6 fe80:xx:xx:xx:xx:xx:xx/64 scope link
       valid_lft forever preferred_lft forever
4: ens20: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.9.0.1/24 scope global wg0
       valid_lft forever preferred_lft forever

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.88.215/24 brd 192.168.88.255 scope global dynamic noprefixroute wlp3s0
       valid_lft 2590700sec preferred_lft 2590700sec
    inet6 fe80:xx:xx:xx:xx:xx:xx/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
7: wg0-client: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.9.0.3/32 scope global wg0-client
       valid_lft forever preferred_lft forever

Попробуй клиенту в конфиг в Address прописать не /32, а /24.

Пробовал - не помогло.

В PostUP разве не должно быть что-то в духе iptables -A FORWARD -o %i -j ACCEPT помимо iptables -A FORWARD -i %i -j ACCEPT. А то у тебя получается какой-то односторонний форвардинг.

Так же не совсем понятно причем тут нат и маскарад, если ты просто пересылаешь пакеты между подсетями клиента WG и своей LAN позади VPN-сервера.

почему у тебя на сервере AllowedIP 10.9.0.2/32, когда у клиента он 10.9.0.3/32 ?

о, сорян. на самом деле, в конфиге 2 клиента описано.

iptables -A FORWARD -o %i -j ACCEPT

не помогло

причем тут нат и маскарад

сервер не является шлюзом по умолчанию, маршруты на машинах пока не правил, кроме одной.

Зачем нужен nat если как я понял нужно две локалки соединить. Не проще на клиенте прописать что за этим маршрутом идти в тунель, а на сервере прописать что подсеть клиента находится за этим адресом.

Без ната так же не работает.

Форвардинг пакетов включен.

как на клиенте так и на сервере надеюсь. Тогда доставай tcpdump

Доставал - результат наблюдений описан в стартовом посте. Фактически, обратный пакет из lan не доходит в wg0.

Поднимал через systemd-networkd на сервере, клиенты у меня openwrt.

/etc/systemd/network/99-wg0.netdev

[NetDev]
Name = wg0
Kind = wireguard
Description = WireGuard

[WireGuard]
ListenPort = ${port}
PrivateKey = ${private.key}

[WireGuardPeer]
PublicKey = ${client.public.key}
PresharedKey = ${preshared.key}
AllowedIPs = 172.16.231.2/32
PersistentKeepalive = 25

/etc/systemd/network/99-wg0.network

[Match]
Name = wg0

[Network]
Address = 172.16.231.1/24

[Route]
Gateway = 172.16.231.1/24
Destination = 172.16.231.0/24

На клиенте выглядит так:

peer: ${public.key}
  preshared key: (hidden)
  endpoint: ${server.ip}:${port}
  allowed ips: 0.0.0.0/0
  latest handshake: 1 minute, 57 seconds ago
  transfer: 2.09 MiB received, 2.03 MiB sent
  persistent keepalive: every 25 seconds

Не верю, что этого должно быть достаточно для доступа в lan.

Правилщ iptables на сервере:

-A POSTROUTING -s 172.16.231.0/24 -o eth0 -j SNAT --to-source ${server.ip}

Маскарадинг не делал.

Маршрутами на openwrt заведует mwan3, ибо нужен policy based routing по ipset'ам.

No chain/target/match by that name.

впрочем с -t nat это тоже не работает

Это таки из таблицы nat.

Дело было в том, что у меня в конфиге сети стояла настройка allow-hotplug, что в свою очередь приводило к тому, что net.ipv4.ip_forward = 1 не наследовался для реальных интерфейсов.
замена на auto решило проблему.

Ох жесть. Пока такие отдебажишь пол жизни мимо пройдет

Самое странное, что без модуля wg хотплаг работает нормально. Отрицание, гнев, депрессия .. я все это прошел, братишки.