LINUX.ORG.RU
Форум — Admin  

Не получается выдать белый ipv6 с vpn сервера клиенту

 , , ,


2

3

Хостер отдаёт мне /125 подсеть. Шлюз хостера находится в /48. Конфиг systemd-networkd на сервере (касающееся ipv6):

[Match]
Name=ens3

[Network]
Address=2a0c::120/48
Gateway=2a0c::1

Конфиг wireguard:

[Interface]
Address = 2a0c::121/125
ListenPort = 5000
MTU = 1500
PrivateKey = xx

[Peer]
PublicKey = xx
AllowedIPs = 2a0c::122/128

net.ipv6.conf.all.forwarding=1

В ip6tables всё открыто.

$ ip -6 r s
::1 dev lo proto kernel metric 256 pref medium
200::/7 dev ygg proto kernel metric 256 pref medium
2a0c::120/125 dev wg6 proto kernel metric 256 pref medium
2a0c::/48 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ygg proto kernel metric 256 pref medium
default via 2a0c::1 dev ens3 proto static metric 1024 pref medium

$ ip -6 a
ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a0c::120/48 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe2c:1d4b/64 scope link
       valid_lft forever preferred_lft forever
wg6: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
    inet6 2a0c::121/125 scope global
       valid_lft forever preferred_lft forever

Конфиг WG клиента:

[Interface]
Address = 2a0c::122/125
PrivateKey = xx
MTU = 1500

[Peer]
AllowedIPs = ::/0
Endpoint = xx
PersistentKeepalive = 21
PublicKey = xx

В ip6tables всё открыто.

$ ip -6 r s
::1 dev lo proto kernel metric 256 pref medium
200::/7 dev ygg proto kernel metric 256 pref medium
2a0c::120/125 dev wg6 proto kernel metric 256 pref medium
2000::/3 via 2a0c::121 dev wg6 metric 1024 pref medium
fe80::/64 dev ygg proto kernel metric 256 pref medium
fe80::/64 dev eno1 proto kernel metric 1024 pref medium

$ ip -6 a
wg6: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
    inet6 2a0c::122/125 scope global
       valid_lft forever preferred_lft forever

$ ping -6 2a0c::121
64 bytes from 2a0c::121: icmp_seq=1 ttl=64 time=47.5 ms

$ ping -6 2a0c::120
64 bytes from 2a0c::121: icmp_seq=1 ttl=64 time=46.9 ms (DIFFERENT ADDRESS!)

$ ping -6 2a0c::1
From 2a0c::121 icmp_seq=1 Destination unreachable: Address unreachable

Сервер:

$ ping -6 2a0c::1
64 bytes from 2a0c::1: icmp_seq=1 ttl=64 time=1.14 ms

При пинге клиентом 2a0c::1, сервер передаёт следующее:

# ip6tables -t mangle -A POSTROUTING -j LOG
$ journalctl -f -g 'SRC='
kernel: IN=wg6 OUT=ens3 MAC= SRC=2a0c:0000:0000:0000:0000:0000:0000:0122 DST=2a0c:0000:0000:0000:0000:0000:0000:0001 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=920934 PROTO=ICMPv6 TYPE=128 CODE=0 ID=14 SEQ=1

Ещё присутствует такое:
kernel: IN=ens3 OUT=ens3 MAC=00:00:00:00:00:00:00:00:00:00:00:00:00:00 SRC=fe80:0000:0000:0000:5054:00ff:fe2c:1d4b DST=2a0c:0000:0000:0000:0000:0000:0000:0001 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0
kernel: IN=ens3 OUT=ens3 MAC=00:00:00:00:00:00:00:00:00:00:00:00:00:00 SRC=fe80:0000:0000:0000:5054:00ff:fe2c:1d4b DST=ff02:0000:0000:0000:0000:0001:ff00:0001 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0

Prerouting при том же пинге:

# ip6tables -t mangle -A PREROUTING -j LOG
$ journalctl -f -g 'SRC='
kernel: IN=wg6 OUT= MAC= SRC=2a0c:0000:0000:0000:0000:0000:0000:0122 DST=2a0c:0000:0000:0000:0000:0000:0000:0001 LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=920934 PROTO=ICMPv6 TYPE=128 CODE=0 ID=15 SEQ=1

Также без пинга есть это:
kernel: IN=ens3 OUT= MAC=33:33:00:00:00:12:00:00:5e:00:02:01:86:dd SRC=fe80:0000:0000:0000:327c:5e08:ae98:3c80 DST=ff02:0000:0000:0000:0000:0000:0000:0012 LEN=80 TC=224 HOPLIMIT=255 FLOWLBL=0 PROTO=112

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



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

Ответ на: комментарий от Anoxemian

По классике это proxy arp или proxy ndp без всякого nat.

Если бы у ТС был не wireguard, а какой-нибудь L2 туннель (L2TP, OpenVPN tap, и т.п.), он мог бы вообще не париться маршрутизацией на сервере, а просто назначать 2a0c::120/125 адреса на клиенте. Но wireguard не умеет L2 туннели, умеет только L3.

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

Сделал, но прогресса нет. На WG интерфейсе сервера поменял маску с 125 на 48, и ошибка клиента «(DIFFERENT ADDRESS!)» при пинге 2a0c::120 пропала. Может быть ещё где беда с масками? Должен ли сервер пинговать 2a0c::1 через wg6? $ ping 2a0c::1 -I wg6

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

Обычно, в случае IPv6, в другую сеть маршрутизируют целую подсеть. Для этого необходимо получить отдельную сеть от хостера, либо же разделить бо́льшую сеть (например, /56) на несколько меньших (например, /64), но эта сеть обязательно должна быть «заведена» на сервер в помощью маршрутизации, а не её назначением на интерфейс.

В вашем случае, полагаю, у вас всего одна /125-подсеть, из которой один из адресов уже назначен серверу. Это означает, что сеть назначена на интерфейс, а не настроена маршрутом на него. В этом случае оборудование хостера ожидает NDP-анонсы от каждого адреса (клиента). Необходимо настроить NDP proxy, либо тот, что встроен в Linux, либо отдельный демон на выбор: ndppd, ndp-proxy, ndproxy, autoneighxy.

Больше по теме:
https://www.geeklab.info/2013/05/ipv6-neighbour-proxy/
https://quantum5.ca/2019/03/08/ndp-proxy-route-ipv6-vpn-addresses/
https://mkaczanowski.com/ndppd-ipv6-ndp-proxy/

А прямой ответ на вопрос «Как правильно выдать ipv6?» — запросить у хостера дополнительную подсеть/подсети нужного размера, смаршрутизированные на сервер, и смаршрутизировать их дальше в VPN штатными средствами, без NDP Proxy.

P.S. в OpenWRT встроен собственный отличный NDP Proxy, работающий из коробки и не требующий дополнительных настроек.

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

Сделал стенд из трёх виртуалок и двух сетей:

  [gateway]
      |enp1s0 (2a0c::1/48)
(network: ext)
      |enp2s0 (2a0c::120/48)
   [server]
      |enp7s0 (link-local)
(network: int)
      |enp1s0 (link-local)
   [client]
      +--lo (2a0c::122/128)

Нестандартные настройки на server:

  • net.ipv6.conf.all.forward=1
  • net.ipv6.conf.enp2s0.proxy_ndp=1
  • ip ro add 2a0c::122 via <client-link-local> dev enp7s0 src 2a0c::120
  • ip nei add proxy 2a0c::122 dev enp2s0

Нестандартные настройки на client:

  • ip addr add 2a0c::122 dev lo
  • ip ro add ::/0 via <server-link-local> dev enp1s0 src 2a0c::122

Пинг 2a0c::1 с виртуалки client работает. Пинг 2a0c::122 с виртуалки gateway работает.

gateway:

# ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a0c::1/48 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::adfe:293:d3c1:96c5/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
# ip -6 r
::1 dev lo proto kernel metric 256 pref medium
2a0c::/48 dev enp1s0 proto kernel metric 100 pref medium
fe80::/64 dev enp1s0 proto kernel metric 1024 pref medium
# ip -6 nei
fe80::addf:da8a:ff64:152e dev enp1s0 lladdr 52:54:00:b1:9b:bd router REACHABLE
2a0c::120 dev enp1s0 lladdr 52:54:00:b1:9b:bd router DELAY
2a0c::122 dev enp1s0 lladdr 52:54:00:b1:9b:bd DELAY

server:

# ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a0c::120/48 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::addf:da8a:ff64:152e/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::5054:ff:fe07:64c4/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
# ip -6 ro
::1 dev lo proto kernel metric 256 pref medium
2a0c::122 via fe80::5054:ff:fe70:1a1a dev enp7s0 src 2a0c::120 metric 1024 pref medium
2a0c::/48 dev enp2s0 proto kernel metric 101 pref medium
fe80::/64 dev enp7s0 proto kernel metric 1024 pref medium
fe80::/64 dev enp2s0 proto kernel metric 1024 pref medium
# ip -6 nei show proxy
2a0c::122 dev enp2s0  proxy

client:

# ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 2a0c::122/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::5054:ff:fe70:1a1a/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
# ip -6 r
::1 dev lo proto kernel metric 256 pref medium
2a0c::122 dev lo proto kernel metric 256 pref medium
fe80::/64 dev enp1s0 proto kernel metric 1024 pref medium
default via fe80::5054:ff:fe07:64c4 dev enp1s0 src 2a0c::122 metric 1024 pref medium
iliyap ★★★★★
()
Ответ на: комментарий от ValdikSS

Спасибо за такой ёмкий ответ.

Получается, что в идеальном случае у хостера должен быть прописан маршрут 2a0c::/125 via 2a0c::120? Но в моём случае маршрута до моей сети у хостера нет, и он по NDP запросу каждого хоста создаёт маршрут до этого хоста? По запросу 2a0c::122 он должен создать маршрут 2a0c::122/128 via 2a0c::120?

Ситуация на сервере сейчас: Конфиг ens3

[Match]
Name=ens3

[Network]
Address=2a0c::120/48
Gateway=2a0c::1
IPv6ProxyNDP=1

sysctl

net.ipv4.ip_forward=1

net.ipv6.conf.all.forwarding=1
net.ipv6.conf.ens3.accept_ra = 2
net.ipv6.conf.ens3.proxy_ndp=1

net.ipv6.conf.wg6.accept_ra = 2
net.ipv6.conf.wg6.autoconf = 1

ip -6 a

ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a0c::120/48 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe2c:1d4b/64 scope link
       valid_lft forever preferred_lft forever

ip -6 r s

::1 dev lo proto kernel metric 256 pref medium
2a0c::/48 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
default via 2a0c::1 dev ens3 proto static metric 1024 pref medium

ip -6 n s

2a0c::1 dev ens3 lladdr 00:00:5e:00:02:02 router REACHABLE
2a0c::ffff:ffff:ffff:ffff:fffe dev ens3 FAILED
fe80::fc54:ff:fe2c:1d4b dev ens3 lladdr fe:54:00:2c:1d:4b STALE

При этом состояние 2a0c::1 dev ens3 lladdr 00:00:5e:00:02:02 router меняется по циклу

2a0c::1 dev ens3 lladdr 00:00:5e:00:02:02 router REACHABLE
2a0c::1 dev ens3 lladdr 00:00:5e:00:02:02 router STALE
2a0c::1 dev ens3 lladdr 00:00:5e:00:02:02 router DELAY
2a0c::1 dev ens3 lladdr 00:00:5e:00:02:02 router PROBE
2a0c::1 dev ens3 router FAILED

Что не так?

================

Согласно этому описанию https://extremeportal.force.com/ExtrArticleDetail?an=000086141 , циркуляция между этими состояниями является нормой. Вот только кроме FAILED

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

Бро, не будет у тебя ничего работать. Единственный вариант - туннель+dnat. Все что про ndp написано, это не твой случай. Житуха у тебя бы была, если бы тебе выдали маршрутизируему сеть не менее /64 - можно использовать механизм ndp + slaac. На худой конец маршрутизируемую /125 - можно использовать ndp или статическую маршрутизацию. Твой случай это условный vlan с шлюзом на одном конце и /125 на другом. Поднимай nat, нет пути.

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

Потому что для того, чтобы работал механизм ndp, ему нужна маршрутизируемая сеть, либо превратить vps в хаб, т.е. обеспечить L2 связанность сети между провайдером и vps и сети между vps и клиентами. Ни первое, ни второе условие невыполнимо.

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

Разве ядро не само отвечает на NDP-запросы при настройке NDP-прокси? Если настроено статически, то, мне кажется, само и отвечает. На OpenVPN в TUN(L3)-режиме такая конфигурация работает, не вижу причин, почему не должно заработать с WireGuard.

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

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

Proxy ARP и Proxy NDP работают одинаково – когда на интерфейс, на котором включён proxy_arp или proxy_ndp приходит ARP или NDP запрос к адресу, к которому у хоста есть маршрут через другой интерфейс, хост отвечает на этот ARP или NDP запрос своим link-layer адресом.

Однако IPv4 подсети обычно маленькие, а IPv6 подсети обычно большие. Если у хоста есть маршрут к /64 подсети, он будет отвечать на NDP запросы ко всем /64 адресам. Это может переполнить neighbor таблицы других хостов подсети. Поэтому ядро отвечает только на NDP запросы к адресам, для которых явно созданы ip neighbor proxy записи.

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

NDP-прокси не нужен, если сеть маршрутизируемая. В маршрутизируемые сети не отправляются NDP-запросы. Вы что-то путаете.

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

а как пихать/принимать l2 анонсы в l3 сети без прокси?

Их и не нужно «пробрасывать» до клиента VPN, сервер сам должен отвечать на анонс провайдера, как будто от имени клиента. Сервер VPN точно знает, какие клиенты VPN подключены и что им нужно маршрутизировать: в WireGuard все настройки и так производятся статически, а для OpenVPN сотоварищи пишутся up-скрипты.

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

сервер сам должен отвечать на анонс провайдера, как будто от имени клиента.

Звучит как магия. Мой опыт говорит о том, что без явного анонса с помощью прокси, прокинуть маршрутизируемую сеть в l3 невозможно. Ну, т.е. я делал slaac через wg.

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

Телефон

ip wg 2002:6to4:6to4::1:2:131/64
ноута AllowedIPs 2000::/3, 2002:6to4:6to4::1/128

Ноут

ip wg 2002:6to4:6to4::1/64
тел AllowedIPs = 2002:6to4:6to4::/64
proxy sit_ppp0 {
 rule 2002:6to4:6to4::/64 {
  iface wg0
 }
}
+ sysctl ndp

Но проблема был еще br0 с 2002:6to4:6to4::1/64 и не работало

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

Правильно понимаю, что если клиент отправляет ndp запросы, то в ip -6 n s у него по любому что-то да должно быть? Если так, то там пусто. Так же, должна ли у сервера появиться запись о клиенте в ip -6 n s? Её там тоже нет. После выполнения ip neigh add proxy 2a0c::121 dev wg6 ничего не меняется

На данный момент у сервера убрал адрес с wg6, тк назначенного на ens3 2a0c::120/48 видимо достаточно, а 2a0c::121/125 теперь назначен на клиентском wg6.

Верны ли следующие утверждения?

  • net.ipv6.conf.all.forwarding=1 - разрешает форвардинг между всеми интерфейсами и автоматически отключает accept_ra по умолчанию.
  • net.ipv6.conf.ens3.accept_ra = 2 - разрешает автонастройку маршрутов с узлами, доступными на ens3, через ndp.
  • net.ipv6.conf.ens3.proxy_ndp=1 - разрешает проксирование ndp с любого интерфейса на узлы ens3 (как именно это работает? Звучит несколько размыто)
  • net.ipv6.conf.wg6.accept_ra = 2 - нужно ли добавлять это?
  • net.ipv6.conf.wg6.autoconf = 1 - что именно оно меняет, и нужно ли оно?
  • net.ipv6.conf.wg6.proxy_ndp=1 - нужно?
stripwire
() автор топика
Ответ на: комментарий от stripwire

Правильно понимаю, что если клиент отправляет ndp запросы, то в ip -6 n s у него по любому что-то да должно быть?

У тебя клиент считает, что подсеть за wg6 это 2a0c::120/125. Клиент шлёт NDP запросы c wg6 к адресам 2a0c::120/125, а у сервера на wg6 таких адресов нет. Вот сервер и не отвечает, на клиенте записи не появляются. Пути два:

Либо 1) Включить на сервере proxy_ndp на wg6 и добавить ip -6 nei add proxy 2a0c::120 dev wg6. Тогда сервер начёт отвечать на NDP запросы к 2a0c::120 с wg6.

Либо 2) Добавить на клиенте маршрут ip -6 ro add 2000::/3 via <server-wg6-link-local> dev wg6. Тогда клиент будет маршрутизировать пакеты не через 2a0c::120, а через link-local адрес сервера на wg6. И будет посылать NDP-запросы с wg6 к link-local адресу сервера на wg6. На них север отвечать будет.

Так же, должна ли у сервера появиться запись о клиенте в ip -6 n s? Её там тоже нет.

На серверном wg6 только link-local адрес fe80::xxxx/64, поэтому сервер шлёт NDP запросы с wg6 только к адресам fe80::/64. Соответственно запись о 2a0c::121 появится и не может.

Чтобы сервер слал NDP запросы к адресу 2a0c::121, надо добавить на сервере directly connected маршрут к этому адресу через wg6: ip -6 ro add 2a0c::121 dev wg6.

После выполнения ip neigh add proxy 2a0c::121 dev wg6 ничего не меняется

Во-первых, чтобы такая запись работала, должен быть включен proxy_ndp на wg6. Во-вторых, адреса в этих записях должны находиться с другой стороны от wg6. Вот запись proxy 2a0c::120 dev wg6 имеет смысл – адрес находится 2a0c::120 с другой стороны от wg6, на ens3.

На данный момент у сервера убрал адрес с wg6, тк назначенного на ens3 2a0c::120/48 видимо достаточно, а 2a0c::121/125 теперь назначен на клиентском wg6.

Это надо было бы написать в начале поста.

На мой взгляд в этой схеме конфигурация должна быть такая. На сервере:

net.ipv6.conf.ens3.proxy_ndp=1
net.ipv6.conf.wg6.proxy_ndp=1
ip nei add proxy 2a0c::120 dev wg6
ip nei add proxy 2a0c::121 dev ens3
ip ro add 2a0c::121 dev wg6
ip addr add 2a0c::120/48 dev ens3

На клиенте:

ip addr add 2a0c::121/125 dev wg6
ip ro add 2000::/3 via 2a0c::120
iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Ну хоть немного исчезла путаница в понимании этих конфигов.

Использовал вашу конфигурацию. После этого клиент стал пинговать 2a0c::1 (мир по прежнему address unreachable), но через пару минут у сервера в ip -6 n s 2a0c::1 начинает вываливаться в incomplete и failed, а клиент получает на пинг Address unreachable. Таким образом, соединение восстанавливается несколько раз, и затем либо статус начинает меняться между incomplete и failed, либо даже при нормальном статусе пинга нет. Дальше нужно перезапустить сервер, прописать ip nei a proxy...2x (позже вставлю в wg6 IfUp), начать пинговать и снова ловить отвал.

Может ли быть, что я начинаю бомбордировать шлюз ~ndp запросами к примеру, и он меня просто банит? Как это проверить?

Серверу такой отвал никакого зла не делает. Как пинговал даже мир, так и пингует. Это из-за того, что серверу не нужен ndp по причине соединения по L2?

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

клиент стал пинговать 2a0c::1 (мир по прежнему address unreachable)

На клиенте нет маршрута в ::/0, есть маршрут в 2000::/3. Так было написано в стартовом посте. Я думал это какой-то хитрый план не добавлять дефолтный маршрут на клиента. Если дефолтный маршрут на клиенте всё-таки нужен, то надо заменить 2000::/3 via 2a0c::120 на 0::/0 via 2a0c::120.

Это из-за того, что серверу не нужен ndp по причине соединения по L2?

Нет, серверу нужен NDP. Как раз таки из-за соединения по L2. NDP как раз используется для определения link-local адреса directly connected пира.

даже при нормальном статусе пинга нет.

Видимо обрыв на первом хопе (на wg-туннеле). Кроме ping есть ещё traceroute, он показывает на каком хопе обрыв. Рекомендую.

Я прочитал что такое wireguard. Он создаёт point-to-point линки. По этим линкам передаются пакеты без link-layer заголовков, соответственно link-layer адресов нет и NDP не используется. Поэтому включать proxy_ndp на серверном wg6 смысла не имело.

Попробуйте вот так на сервере:

net.ipv6.conf.ens3.proxy_ndp=1
net.ipv6.conf.wg6.proxy_ndp=0
ip nei add proxy 2a0c::121 dev ens3
ip addr add 2a0c::120/48 dev ens3
ip ro add 2a0c::120/125 dev wg6 src 2a0c::120

На клиенте:

ip addr add 2a0c::121/125 dev wg6
ip ro add ::/0 via 2a0c::120
iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Видимо NdpProxy не работает без включения IPv6ProxyNDP в конфиге systemd-networkd ens3.

Пока не понял каким именно образом, но получилось пинговать мир (вроде всё же маршрут к ::/0 помог, но нужно будет потом порыть, тк это решение возможно не устраивает меня).

С использованием новых конфигов ничего не изменилось (за исключением ::/0 наверно). После перезагрузки сервера могу пинговать мир, потом прерывисто, а дальше вообще падает. По traceroute обрыв после сервера.

Только что обнаружил такую связь. Если Пинговать шлюз и с клиента, и с сервера, то у обоих периодически пропадает пинг на 2-4 сек. Это происходит в то время, когда в ip -6 n s шлюз находится в статусах incomplete/failed. Если прекратить пинг шлюза с сервера, то через некоторое время шлюз окончательно валится в incomplete/failed, и редко восстанавливается секунд на 15-40 (всё это время клиент пытается пинговать шлюз, и только в эти 15-40 сек пинг доходит).

Итог: соединение периодически рвётся, но по инициативе сервера относительно быстро восстанавливается. Если самому серверу передавать нечего, но клиент хочет передавать, то соединение иногда восстанавливается.

Ещё заметил, что если клиент не пытается пинговать шлюз, то incomplete/failed статусы особо не влияют на доступность шлюза серверу.

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

Видимо NdpProxy не работает без включения IPv6ProxyNDP в конфиге systemd-networkd ens3.

Параметр IPv6ProxyNDP это не магия, он просто присваивает net.ipv6.conf.<iface>.proxy_ndp.

Есть ещё параметр IPv6ProxyNDPAddress. С его помощью можно задавать адреса, для которых этот хост становится законным представителем на этом линке. Параметр IPv6ProxyNDPAddress это тоже не магия, он добавляет ip -6 nei add proxy запись для указанного адреса. Имеет смысл использовать IPv6ProxyNDPAddress=2a0c::121 вместо ip -6 nei add proxy 2a0c::121 dev ens3.

По traceroute обрыв после сервера.

Имело бы смысл посмотреть на ICMPv6 сообщения, которых ходят на линке ens3 сервера. Вывод tcpdump -npe -i ens3 icmp6 за период (подключение клиента, успешные пинги, пропадание пингов, восстановление пингов) помог бы понять что происходит.

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

https://pastebin.com/raw/LUbsZuLQ

Видимо шлюз не хочет отвечать на fe80, а когда сервер всё же решает запросить с 2a0c::120, шлюз наконец просыпается. Когда пора переспросить адрес, начинается та же песня.

ip n d 2a0c::1 dev ens3 lladdr 00:00:5e:00:02:02
ip n a 2a0c::1 dev ens3 lladdr 00:00:5e:00:02:02 nud permanent

Такая статическая привязка к MAC безотказно помогает (правда всё ещё предстоит разобраться с пингом, периодически подскакивающем на 70-720ms для одного пакета).

Но правильнее было бы научить сервер не использовать fe80 для ndp. Можно ли так сделать, или можно просто убрать fe80 с интерфейса? Не вызовет ли это других неисправностей?

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

В RFC 4861, 7.2.2. Sending Neighbor Solicitations написано:

If the source address of the packet prompting the solicitation is the same as one of the addresses assigned to the outgoing interface, that address SHOULD be placed in the IP Source Address of the outgoing solicitation. Otherwise, any one of the addresses assigned to the interface should be used. Using the prompting packet’s source address when possible ensures that the recipient of the Neighbor Solicitation installs in its Neighbor Cache the IP address that is highly likely to be used in subsequent return traffic belonging to the prompting packet’s «connection».

Т.е. когда сервер хочет послать свой пакет, и у него в neighbor cache нет записи для 2a0c::1, он посылает neighbor solicitation с адреса 2a0c::120. А когда сервер хочет отфорвардить чужой пакет, он посылает neighbor solicitation с первого попавшегося адреса с интерфейса ens3 (с link-local адреса).

Гейтвей провайдера на neighbor solicitation от link-local адресов не отвечает. Не знаю почему. Это какой-то мисконфигурэйшн на его стороне. Может быть у гейтвея нет link-local адреса на этом линке? Странно, без link-local адресов не работает router advertisement. Может быть оператор ДЦ хитер или криворук и выключил router advertisement путём удаления link-local адреса специально? У него же сплошные несовместимости с SLAAC: /48 вместо /64, дефолт раут ручной, и т.д.

Можно попробовать удалить link-local адрес с ens3 (LinkLocalAddressing=no в .network). Что при этом сломается я не знаю. Возможно ничего не сломается.

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

Удаление local link с ens3 результатов не дало. Отправка neighbor solicitation просто не происходит, пока сервер внезапно не решит использовать global адрес.

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

Тем временем заметил, что при входящих на 2a0c::121 соединениях, моему серверу приходят ns пакеты с fe80 адресов, и когда сервер отвечает на них с fe80, ответы будто игнорируются, тк продолжают приходить такие же пакеты с поиском 2a0c::121.

Что это может быть?

Хм. А ведь мне могли заблокировать local link соединения, тк не исключено, а скорее всего такое даже было, что сервер спамил multicast’ом.

stripwire
() автор топика
Admin