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

Между интерфейсами не бегают пакеты по IPv6

 , , ,


0

1

Друзья, что-то за длинное и жаркое лето отупел в край и никак не могу сообразить, почему между двумя интерфейсами не ходят пакеты Ipv6.

Система Ubuntu 22.04

Есть основной интерфейс, с /64 префиксом от провайдера. Хочу на нем один адрес взять для сервера, остальное отдаю в туннель Wireguard.

Основной интерфейс:

ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::5054:ff:fe0e:f46a  prefixlen 64  scopeid 0x20<link>
        inet6 2a10:9200:1::  prefixlen 64  scopeid 0x0<global>

WG:

wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420
        inet6 2a10:9200:1::  prefixlen 64  scopeid 0x0<global>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)

Если делаю ping -6 ya.ru, то все пингуется. Если ping -6 -I wg0 ya.ru, то адрес недоступен. С удаленного конца WG туннеля, ситуация аналогичная. Уходит по туннелю до интерфейса wg0 и на нем все умирает, дальше никуда не идет.

Sysctl по поводу форвардинга дает вот такое вот:

net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.mc_forwarding = 0
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.default.mc_forwarding = 0
net.ipv6.conf.ens3.forwarding = 1
net.ipv6.conf.ens3.mc_forwarding = 0
net.ipv6.conf.lo.forwarding = 1
net.ipv6.conf.lo.mc_forwarding = 0
net.ipv6.conf.wg0.forwarding = 1
net.ipv6.conf.wg0.mc_forwarding = 0

Маршрутизация такая:

ip -6 route
2a10:9200:1::/64 dev wg0 proto kernel metric 200 pref medium
2a10:9200:1::/64 dev ens3 proto kernel metric 256 pref medium
2a10:9200:1::/64 dev wg0 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
default via fe80::1 dev ens3 proto static metric 1024 onlink pref medium

IPTables - ничего криминального:

ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Где я не прав?



Последнее исправление: kvv213 (всего исправлений: 1)
← Cloud print
Значения ключей в кавычках для параметра mntoptions allow при настройки pam_mount →

Не знаю что у тебя не так. Я просто клиентам в туннель отдаю серые адреса ipv4 и ipv6 через маскарад.
И все замечательно работает. Зачем туда пропихивать реальные ip?
Хотя, может у тебя такой случай что и нужно.

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

Я просто клиентам в туннель отдаю серые адреса и ipv4 и ipv6 через маскарад.

Через маскарад понятно, но нужно именно префикс раздать. На другом сервере у меня это работает, а тут не пойму, что не так.

kvv213
() автор топика

С удаленного конца WG туннеля, ситуация аналогичная. Уходит по туннелю до интерфейса wg0 и на нем все умирает

Как определил, что на нем? ip -6 route get 2a02:6b8::2:242 iif wg0 from 2a10:9200:1::1234 что скажет?

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

Вот что сказал chatgpt :) 

Покажи пример настройки wireguard с пробросом ipv6 подсети 2a10:9200:1::/64 клиентам.
ChatGPT сказал:
ChatGPT
Чтобы настроить WireGuard с пробросом IPv6 подсети (например, 2a10:9200:1::/64) клиентам, нужно выполнить следующие шаги:

1. Настройка сервера WireGuard
Предположим, что у вас есть сервер с IPv6-адресом 2a10:9200:1::1/64. Ваша цель — раздать клиентам адреса из подсети 2a10:9200:1::/64.

Конфигурация WireGuard на сервере (wg0.conf):
ini
Копировать код
[Interface]
Address = 2a10:9200:1::1/64    # IPv6-адрес сервера
PrivateKey = <PrivateKey>       # Приватный ключ сервера
ListenPort = 51820              # Порт, на котором будет слушать WireGuard

# Включение пересылки пакетов для IPv6
PostUp = sysctl -w net.ipv6.conf.all.forwarding=1

# Настройка маршрутизации для подсети 2a10:9200:1::/64
PostUp = ip6tables -A FORWARD -i wg0 -j ACCEPT
PostUp = ip6tables -A FORWARD -o wg0 -j ACCEPT
PostUp = ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

PostDown = ip6tables -D FORWARD -i wg0 -j ACCEPT
PostDown = ip6tables -D FORWARD -o wg0 -j ACCEPT
PostDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Пример конфигурации клиента
PublicKey = <ClientPublicKey>        # Публичный ключ клиента
AllowedIPs = 2a10:9200:1::2/128      # IPv6-адрес для клиента
Описание параметров:
Address: IPv6-адрес сервера, например, 2a10:9200:1::1/64.
PrivateKey: Приватный ключ сервера, который нужно сгенерировать командой wg genkey.
ListenPort: Порт, на котором WireGuard будет принимать соединения.
PostUp и PostDown: Команды, которые выполняются при поднятии и выключении интерфейса wg0 соответственно. Здесь мы включаем пересылку IPv6 и настраиваем правила ip6tables для проброса трафика.
2. Настройка клиента WireGuard
Теперь настроим клиент для получения IPv6-адреса из подсети 2a10:9200:1::/64.

Конфигурация WireGuard на клиенте (wg0.conf):
ini
Копировать код
[Interface]
Address = 2a10:9200:1::2/64    # IPv6-адрес клиента из подсети
PrivateKey = <ClientPrivateKey> # Приватный ключ клиента

[Peer]
PublicKey = <ServerPublicKey>     # Публичный ключ сервера
Endpoint = <ServerIPv6>:51820     # IPv6-адрес и порт сервера
AllowedIPs = ::/0                 # Все IPv6 маршруты через WireGuard
PersistentKeepalive = 25          # Поддержание соединения
Описание параметров:
Address: IPv6-адрес клиента, например, 2a10:9200:1::2/64.
PrivateKey: Приватный ключ клиента, который нужно сгенерировать командой wg genkey.
PublicKey: Публичный ключ сервера, полученный с сервера.
Endpoint: IPv6-адрес сервера и порт.
AllowedIPs: Указываем маршруты, которые будут отправляться через интерфейс WireGuard. В этом случае ::/0 означает, что весь IPv6-трафик будет идти через WireGuard.
PersistentKeepalive: Параметр, позволяющий поддерживать соединение активным, отправляя пустые пакеты через определенные промежутки времени.
3. Маршрутизация и NAT (если требуется)
Если ваш сервер находится за маршрутизатором, то нужно настроить маршрутизацию на вашем маршрутизаторе для подсети 2a10:9200:1::/64 на сервер.

4. Запуск WireGuard
После настройки конфигураций на сервере и клиенте, необходимо запустить WireGuard:

На сервере:

bash
Копировать код
wg-quick up wg0
На клиенте:

bash
Копировать код
wg-quick up wg0
5. Проверка подключения
После успешного запуска, проверьте, что клиенты получили IPv6-адреса из заданной подсети и могут пинговать сервер:

bash
Копировать код
ping6 2a10:9200:1::1
Если всё настроено правильно, то WireGuard должен раздавать IPv6-адреса клиентам и пробрасывать IPv6-трафик через VPN-туннель.






Вы сказали:
Сеть 2a10:9200:1::/64 я получаю от провайдера. Тогда как?
ChatGPT сказал:
ChatGPT
Если сеть 2a10:9200:1::/64 получена от провайдера, вам нужно правильно настроить маршрутизацию, чтобы эта сеть могла использоваться для клиентов WireGuard. В этом случае сервер WireGuard должен быть настроен как шлюз, который будет передавать этот диапазон клиентам.

1. Настройка сервера WireGuard
Конфигурация WireGuard на сервере (wg0.conf):
ini
Копировать код
[Interface]
Address = 2a10:9200:1::1/64    # IPv6-адрес сервера (например, первый адрес из полученной сети)
PrivateKey = <PrivateKey>       # Приватный ключ сервера
ListenPort = 51820              # Порт, на котором будет слушать WireGuard

# Включение пересылки пакетов для IPv6
PostUp = sysctl -w net.ipv6.conf.all.forwarding=1

# Настройка маршрутизации для подсети 2a10:9200:1::/64
PostUp = ip6tables -A FORWARD -i wg0 -j ACCEPT
PostUp = ip6tables -A FORWARD -o wg0 -j ACCEPT

PostDown = ip6tables -D FORWARD -i wg0 -j ACCEPT
PostDown = ip6tables -D FORWARD -o wg0 -j ACCEPT

[Peer]
# Пример конфигурации клиента
PublicKey = <ClientPublicKey>        # Публичный ключ клиента
AllowedIPs = 2a10:9200:1::2/128      # IPv6-адрес для клиента
2. Маршрутизация на сервере
Поскольку вы получили сеть от провайдера, вам необходимо настроить правильную маршрутизацию, чтобы клиенты могли использовать выделенный вам диапазон IPv6-адресов.

Добавление маршрута на сервере
Если ваш сервер WireGuard получает сеть 2a10:9200:1::/64 через основной интерфейс (например, eth0), нужно убедиться, что трафик для этой сети будет передаваться через интерфейс WireGuard.

Команда для добавления маршрута может выглядеть так:

bash
Копировать код
ip -6 route add 2a10:9200:1::/64 dev wg0
Эта команда устанавливает маршрут для сети 2a10:9200:1::/64, направляющий трафик через интерфейс wg0.

3. Настройка клиента WireGuard
Теперь на клиенте нужно настроить получение IP-адреса из подсети 2a10:9200:1::/64.

Конфигурация WireGuard на клиенте (wg0.conf):
ini
Копировать код
[Interface]
Address = 2a10:9200:1::2/64     # IPv6-адрес клиента из подсети
PrivateKey = <ClientPrivateKey>  # Приватный ключ клиента

[Peer]
PublicKey = <ServerPublicKey>     # Публичный ключ сервера
Endpoint = <ServerIPv6>:51820     # IPv6-адрес и порт сервера
AllowedIPs = ::/0                 # Все IPv6 маршруты через WireGuard
PersistentKeepalive = 25          # Поддержание соединения
4. NAT (если требуется)
В случае если сервер WireGuard не является устройством с глобальным IPv6-адресом, а получает его через маршрутизатор, возможно, потребуется настроить маршрутизацию на вашем маршрутизаторе, чтобы трафик из сети 2a10:9200:1::/64, отправленный через WireGuard, корректно маршрутизировался обратно в Интернет.

5. Проверка конфигурации
После настройки всех компонентов, убедитесь, что сервер и клиенты корректно обмениваются данными по IPv6. Вы можете проверить доступность с клиента до сервера и далее в Интернет:

bash
Копировать код
ping6 2a10:9200:1::1  # Проверка соединения с сервером
ping6 google.com      # Проверка соединения с Интернетом через сервер
Если всё настроено правильно, трафик от клиентов должен маршрутизироваться через сервер WireGuard и иметь возможность выходить в Интернет через предоставленный диапазон IPv6.

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

Как определил, что на нем?

Выдает адрес сервера, как конечную точку.

ip -6 route get 2a02:6b8::2:242 iif wg0 from 2a10:9200:1::1234 что скажет?

2a02:6b8::2:242 from 2a10:9200:1::1234 via fe80::1 dev ens3 proto static metric 1024 iif wg0 pref medium

Может если у тебя на ens3 inet6 2a10:9200:1::, то на wg0 должно быть что-то типа inet6 2a10:9200:1:1:.

На это я тоже думал, но по идее это не нарушение.

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

Вот что сказал chatgpt :)

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

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

Кто выдает? ping с клиента wg. Но тут, на мой взгляд, проблема на стороне сервера, даже не клиента.

ping -6 ya.ru
PING ya.ru (2a02:6b8::2:242) 56 data bytes
From host-2a10-9200-1.macloud.host (2a10:9200:1::) icmp_seq=1 Destination unreachable: Address unreachable

Это пинг с клиента WG

kvv213
() автор топика
Ответ на: комментарий от kvv213
  1. Маршрутизация и NAT (если требуется) Если ваш сервер находится за маршрутизатором, то нужно настроить маршрутизацию на вашем маршрутизаторе для подсети 2a10:9200:1::/64 на сервер.

У тебя вот это условие, по-ходу, не выполнено. Марщрутизатор тебе выделил не префикс, а адрес в сети ::/64. Он не знает, что всю подсеть надо маршрутизировать через твой сервер.

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

У тебя вот это условие, по-ходу, не выполнено. Марщрутизатор тебе выделил не префикс, а адрес в сети ::/64. Он не знает, что всю подсеть надо маршрутизировать через твой сервер.

Перепроверил следующим образом: Вместо /64 на интерфейс ens3 повесил /128 и не ::, а ::1.

ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::5054:ff:fe0e:f46a  prefixlen 64  scopeid 0x20<link>
        inet6 2a10:9200:1::1  prefixlen 128  scopeid 0x0<global>

Пинг идет, соответственно выдана все же подсеть /64, а не единичный адрес.

Замечу, что пинг идет следующим образом:

ping -6 ya.ru
PING ya.ru (2a02:6b8::2:242) 56 data bytes
From v980074.macloud.host (2a10:9200:1:141::1) icmp_seq=1 Destination unreachable: Address unreachable
From v980074.macloud.host (2a10:9200:1:141::1) icmp_seq=2 Destination unreachable: Address unreachable
From v980074.macloud.host (2a10:9200:1:141::1) icmp_seq=3 Destination unreachable: Address unreachable
From v980074.macloud.host (2a10:9200:1:141::1) icmp_seq=4 Destination unreachable: Address unreachable
64 bytes from ya.ru (2a02:6b8::2:242): icmp_seq=6 ttl=60 time=4.86 ms
64 bytes from ya.ru (2a02:6b8::2:242): icmp_seq=7 ttl=60 time=5.00 ms
64 bytes from ya.ru (2a02:6b8::2:242): icmp_seq=8 ttl=60 time=4.93 ms

потому что в маршрутах такое:

ip -6 route
2a10:9200:1::/64 dev wg0 proto kernel metric 200 pref medium
2a10:9200:1::/64 dev ens3 proto kernel metric 256 pref medium

Т.е. сначала кидает пакет в wg0,т.к. у него метрика меньше, потом, когда понимает, что пакеты не уходят куда надо, маршрутизирует пакеты куда следует, на ens3

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

Ничего не смущает?

вообще не очень сильно, но переделал

ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::5054:ff:fe0e:f46a  prefixlen 64  scopeid 0x20<link>
        inet6 2a10:9200:1::1  prefixlen 128  scopeid 0x0<global>
        ether 52:54:00:0e:f4:6a  txqueuelen 1000  (Ethernet)

wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420
        inet6 2a10:9200:1::2  prefixlen 128  scopeid 0x0<global>

ip -6 route show
2a10:9200:1::1 dev ens3 proto kernel metric 256 pref medium
2a10:9200:1::2 dev wg0 proto kernel metric 256 pref medium
2a10:9200:1::/64 dev wg0 metric 1024 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
default via fe80::1 dev ens3 proto static metric 1024 onlink pref medium

ping -6 ya.ru
PING ya.ru (2a02:6b8::2:242) 56 data bytes
64 bytes from ya.ru (2a02:6b8::2:242): icmp_seq=1 ttl=60 time=4.82 ms

ping -6 -I wg0 ya.ru
ping: ya.ru: Address family for hostname not supported

ping -6 -I wg0 2a02:6b8::2:242
ping: connect: Network is unreachable

Стало несколько иначе :)

Характерно, что 2a10:9200:1::1 пингуется извне, а не 2a10:9200:1::2 нет.

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

Еще несколько упростил ситуацию: пинги между двумя интерфейсами, с назначенными руками адресами не ходят, на эти самые адреса.

ping -6 -I ens3 2a10:9200:1::2

не идетъ

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

Освежить память)

Не думаю, что вопрос тут в ND или его проксировании. Т.к. то больше для автоматической маршрутизации и автоматической адресации. А до этого пока не дошло :)

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

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

Почему нельзя просто назначить разным интерфейсам разные подсети? Как я понял, тебе аж целую /32 выдали, из нее можно выбрать аж 4294967296 /64 сетей так, чтобы адреса не пересекались.

Выдали все же /64, а не /32 (0 в IPv6 вполне себе адрес рабочий). На сервере достаточно 1 адреса, а вот в туннель к локальной сети хочу завернуть все остальное. Т.к. там нет IPv6.

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

Сделал еще небольшой финт, чтобы точнее локализовать проблему. Добавил фейковый интерфейс test, добавил ему произвольный ipv6.

ifconfig
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::5054:ff:fe0e:f46a  prefixlen 64  scopeid 0x20<link>
        inet6 2a10:9200:1::1  prefixlen 128  scopeid 0x0<global>
        ether 52:54:00:0e:f4:6a  txqueuelen 1000  (Ethernet)

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 568  bytes 57984 (57.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 568  bytes 57984 (57.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

test: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        inet6 fe80::cad7:4aff:fe4e:4750  prefixlen 64  scopeid 0x20<link>
        inet6 2001::5  prefixlen 64  scopeid 0x0<global>
        ether c8:d7:4a:4e:47:50  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420
        inet6 2a10:9200:1::2  prefixlen 128  scopeid 0x0<global>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)

Добавил на него маршрут персональный:

ip -6 route
2001::5 dev test metric 1024 pref medium
2001::/64 dev test proto kernel metric 256 pref medium
2a10:9200:1:141::1 dev ens3 proto kernel metric 256 pref medium
2a10:9200:1:141::2 dev wg0 proto kernel metric 256 pref medium
2a10:9200:1:141::/64 dev wg0 metric 1024 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev test proto kernel metric 256 pref medium
default via fe80::1 dev ens3 proto static metric 1024 onlink pref medium


ip -6 route get 2001::5 iif ens3
local 2001::5 from :: dev lo table local proto kernel metric 0 iif ens3 pref medium

ip -6 route get 2001::5 iif ens3 from 2a10:9200:1::1
local 2001::5 from 2a10:9200:1::1 dev lo table local proto kernel metric 0 iif ens3 pref medium

Пинг не проходит на адрес 2001::5.

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

Маршрутизатор сначала послал ndp-запрос, чтобы узнать у кого есть твой ip, после чего переправил тебе пакеты. В случае wg он не знает, кому принадлежит этот IP, а через ndp ему никто не отвечает, поэтому ping будет похерен маршрутизатором.

Смотри трафик tcpdumpом. Скорее всего запрос от wg-кликета уходит через твой сервак маршрутизатору, но так как тот выделил тебе не префикс, а один IP, то начинает слать ndp-запросы, чтобы узнать, кому принадлежит этот IP. Не получает ответ и херит твой запрос.

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

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

Это моё видиние ситуации. Так-то надо смотреть трафик.

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

В 2024 году 90% VPS префикс не роутят, даже если иногда про это пишут.

Чтобы это работало — надо у хостера в панельке спецом натыкать себе кучку IPV6 адресов если такое там есть. И потом конкретно эти адреса клиентам назначать.

Ну и ndp proxy конечно должен быть настроен.

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

Это очень странно, никогда не видел, чтобы выдавали /64 с таким количеством нулей. Если это так, то 2a10:9200:1:1::/64 это сеть которая будет выдана уже следующему пользователю.
Каким именно образом ты получаешь ipv6?

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

я вообще предполагал, что маршрутизация будет проходить целиком у меня на сервере. Т.е. из WG не идет к маршрутизатору VPS, а обрабатывается на моем сервере. Там же маршруты прописаны.

Но уточню у провайдера - маршрутизируемая сеть или нет.

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

Это очень странно, никогда не видел, чтобы выдавали /64 с таким количеством нулей. Если это так, то 2a10:9200:1:1::/64 это сеть которая будет выдана уже следующему пользователю. Каким именно образом ты получаешь ipv6?

Некоторые циферки удалены в адресе для приватности.

Сеть получается через спец-заказ у провайдера.

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

В 2024 году 90% VPS префикс не роутят, даже если иногда про это пишут.

Да, такое есть. Иногда пишут, что дали префикс, но по факту пользоваться можно только одним адресом.

Ну и ndp proxy конечно должен быть настроен.

Думаю, что это не проблема будет настроить (хотя по треду выше, я указал, что включил прокси-ND для всех интерфейсов и прописал один адрес туда сразу, но это как-то не помогло), но для начала надо убедиться в том, куда физически бежит пакет (TCPDump мне в руки).

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

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

Я всегда думал, что линукс не пересылает пакеты между интерфейсами, если источником пакетов является локальная программа. Т.е. когда ты указываешь ping -I wg0, он выставляет адрес источника с интерфейса wg0, и дальше смотрит, какие марштурты доступны на этом интерфейсе. Т.к. дефолта нет, отправлять пакет некуда, а на другой интерфес он его отправить не может.
Скорее всего я понимаю это не правильно.

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

Я всегда думал, что линукс не пересылает пакеты между интерфейсами, если источником пакетов является локальная программа.

Мы для этого включаем форвардинг, вроде бы как. В этом случае обработка пакетов (маршрутизация между интерфейсами) должна проходить InHouse.

Поднапряг TCPDump, получил много интересного :)

17:10:56.420359 IP v98007.macloud.host > security.criminalip.com: ICMP v98007.macloud.host udp port 5683 unreachable, length 57
17:12:54.352069 IP v98007.macloud.host > scanner-23.ch1.censys-scanner.com: ICMP v98007.macloud.host udp port 12481 unreachable, length 59
17:13:13.232723 IP v98007.macloud.host > scanner-14.ch1.censys-scanner.com: ICMP v98007.macloud.host udp port 6881 unreachable, length 92
17:13:14.857657 IP v98007.macloud.host > mail.callaway-golf.cn: ICMP v980074.macloud.host udp port sunrpc unreachable, length 76
17:17:05.581589 IP v98007.macloud.host > azpdwgc6.stretchoid.com: ICMP v98007.macloud.host udp port 8080 unreachable, length 61

Сканируют черти…

Но отвлекся. TCPDump не ловит исходящие с VPS ICMP-пакеты в сторону IPv6 маршрутизатора провайдера. Однако, как оказалось, пакеты замечательно бегают между интерфейсами в рамках одного VPS. Если не указывать интерфейс.

Т.е. если я беру просто ping -6 IPv6 адрес - то все работает, а если указываю интерфейс, то ничего не пингуется:

ping -6 -I ens3 ya.ru
PING ya.ru (2a02:6b8::2:242) from 2a10:9200:1::1 ens3: 56 data bytes
From 2a10:9200:1::1 icmp_seq=1 Destination unreachable: Address unreachable
From 2a10:9200:1::1 icmp_seq=2 Destination unreachable: Address unreachable
From 2a10:9200:1::1 icmp_seq=3 Destination unreachable: Address unreachable
From 2a10:9200:1::1 icmp_seq=4 Destination unreachable: Address unreachable

Я могу даже пропинговать от удаленного клиента на wg Ipv6-адрес на ens3.

Если указать не интерфейс, а адрес, то работает:

ping -6 -I 2a10:9200:1::1 ya.ru
PING ya.ru (2a02:6b8::2:242) from 2a10:9200:1::1 : 56 data bytes
From 2a10:9200:1:141::1 icmp_seq=1 Destination unreachable: Address unreachable
From 2a10:9200:1:141::1 icmp_seq=2 Destination unreachable: Address unreachable
64 bytes from ya.ru (2a02:6b8::2:242): icmp_seq=3 ttl=60 time=799 ms
64 bytes from ya.ru (2a02:6b8::2:242): icmp_seq=4 ttl=60 time=4.67 ms

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

Осталось разобраться с маршрутизацией из wg во все остальные места, плюс с ND-Proxy, если потребуется. Т.е. из wg пока во внешнюю среду не пингуется.

Поэтому я не пропадаю.

PS. Почему у ping такое поведение - ХЗ.

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

2001::5

Извне его не даст пингануть, т.к. адрес совсем не мой, а был выдуман из головы.

Извне пингуется только :1, то, что привязано к ens3

Пустил ip -6 neigh add proxy 2a10:9200:1::2 dev ens3, это адрес на wg0, извне не пингуется (хотя и мог бы).

kvv213
() автор топика
Ответ на: комментарий от anonymous 
sysctl -a | grep ndp
net.ipv6.conf.all.proxy_ndp = 1
net.ipv6.conf.default.proxy_ndp = 0
net.ipv6.conf.ens3.proxy_ndp = 0
net.ipv6.conf.lo.proxy_ndp = 0
net.ipv6.conf.test.proxy_ndp = 0
net.ipv6.conf.wg0.proxy_ndp = 0

тут не очень понятно, all перебивает настройку конкретного интерфейса или нет.

Попробую позже подкрутить и задампить.

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

tcpdumpом смотрел? В примерно такой же ситуации я получал ответ на пинг, но видел это только tcodumpом, потому что мой роутер не пересылал ответ клиенту, а выдавал в ответ на респонс от яндекса destination unreachable. И я пока забил на эту хрень с ип6.

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

Пообщался с поддержкой провайдера. Они меня уверили, что префикс маршрутизируемый. Но раздать в туннель WG не выйдет. Почему так, пояснить не смогли.

Провел эксперимент:

  1. Навесил на ens3, предварительно убрав оттуда /64 адрес, несколько адресов из префикса с /128.
  2. Повесил на dummy интерфейс адрес из префикса с /128.

Попробовал пингануть извне. Все адреса пингуются. Попробовал пингануть адрес на WG - не пингуется. Добавил его в NDP на ens3, предварительно включил nd-proxy и на wg и на ens3. Не помогло, извне на него пинги не идут. По TCPDump-у ICMP6 пакеты не приходя на VPS (при пинге на другие адреса из префикса, они приходят). Маршрут на wg0 с тем адресом, на котором тестирую, есть, на wg0 идет…

Отсюда вопрос - что делать.

Пока есть две идеи:

  1. Использовать не WG, а другой туннель, который умеет. Вопрос - что брать? С двух сторон Ubuntu.
  2. Использовать не префикс, полученный от провайдера, а префикс, полученный по 6in4, там точно все маршрутизируется.
kvv213
() автор топика
Ответ на: комментарий от anonymous

Ну не совсем без пляски. WG сам обычно маршруты создает при запуске + маршруты при создании туннеля 6in4 (не обязательны).

На VPS получил /48 префикс (на самом деле достаточно и /64, т.к. те два адреса, что отожрет сам VPS и WG на VPS - ерунда) через 6in4 провайдера. Отрезал от него /64 префикс и завернул его в WG. В обделенной IPv6 сети настроил RA, клиенты получили адреса. Маршрутизация (созданная WG) вся поперла в туннель. Щастье.

kvv213
() автор топика
← Cloud print
Admin
Значения ключей в кавычках для параметра mntoptions allow при настройки pam_mount →