LINUX.ORG.RU
решено ФорумAdmin

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

 , , , ,


0

4

Уже неделю бьюсь с доступом в lan из wireguard.
Коннект есть, с клиента адрес wg интерфейса и lan интерфейса сервера пингуется успешно. При попытке пинга компов в lan сети, пинг с клиента успешно уходит -> доходит до компа в lan -> возвращается на lan интерфейс сервера и там пропадает. Если на компе в lan сети прописать роут до адресов wg, то пинг на адрес сервера wg ходит успешно, трейс до клиента wg выглядит печально - ни одного хопа с ответами.
На сервере два интерфейса : wan - ens19 и lan - ens18.
Конфиг сервера :

[Interface]
PrivateKey = xxx
Address = 10.9.0.1/24
ListenPort = 1195
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens18 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens18 -j MASQUERADE

[Peer]
PublicKey = xxx
AllowedIPs = 10.9.0.2/32

Iptables-save :
# Generated by iptables-save v1.8.4 on Wed Apr 15 13:03:58 2020
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i wg0 -j ACCEPT
COMMIT
# Completed on Wed Apr 15 13:03:58 2020
# Generated by iptables-save v1.8.4 on Wed Apr 15 13:03:58 2020
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -o ens18 -j MASQUERADE
COMMIT

Конфиг клиента :
[Interface]
Address = 10.9.0.3/32
PrivateKey = xxx

[Peer]
PublicKey = xxx
Endpoint = server:1195
AllowedIPs = 10.9.0.0/24, 192.168.0.0/24
PersistentKeepalive = 25

Форвардинг пакетов включен.
Пробовал дистры debian 10 и 11, ubuntu 18.04. Пробовал собирать из сорцов.
Очень нужна помощь экспертов.
Решение - Не работает nat в wireguard (комментарий)

Deleted

Ответ на: комментарий от DALDON
sysctl -a | grep rp_filter
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.ens18.arp_filter = 0
net.ipv4.conf.ens18.rp_filter = 0
net.ipv4.conf.ens19.arp_filter = 0
net.ipv4.conf.ens19.rp_filter = 0
net.ipv4.conf.ens20.arp_filter = 0
net.ipv4.conf.ens20.rp_filter = 0
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.wg0.arp_filter = 0
net.ipv4.conf.wg0.rp_filter = 0
Deleted ()
Ответ на: комментарий от Deleted

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

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

DALDON ★★★★★ ()
Последнее исправление: DALDON (всего исправлений: 1)

Не эксперт, но вопрос доступа в 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
JekaSs ()
Ответ на: комментарий от DALDON

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

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

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

JekaSs ()

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

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

r0ck3r ★★★★★ ()
Последнее исправление: r0ck3r (всего исправлений: 1)
Ответ на: комментарий от r0ck3r

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

Deleted ()
Ответ на: комментарий от Deleted

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

DALDON ★★★★★ ()
Ответ на: комментарий от DALDON

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

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)

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

Deleted ()
Ответ на: комментарий от Deleted

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

DALDON ★★★★★ ()
Ответ на: комментарий от r0ck3r

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

видно по трейсу, что запросы на 192.168.0.0/24 идут через 10.9.0.1

Deleted ()
Ответ на: комментарий от nebularia

Сервер:

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

Deleted ()

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

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

BOOBLIK ★★ ()
Ответ на: комментарий от BOOBLIK

iptables -A FORWARD -o %i -j ACCEPT

не помогло

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

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

Deleted ()

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

anonymous ()

Поднимал через 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

pekmop1024 ★★★★★ ()

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

Deleted ()