Comments 22
Извините, но зачем подсеть /56? Вполне можно и /64 выдаваемую серверу распределить. В чём принципиальная проблема?
Плюс на самом деле SLAAC не гарантирует "статичности" IPv6, по той простой причине что EUI-64 может (и очень часто устройствами таки это делается, причём это где-то даже в спеке прописано) быть рандомизирован.
Как вариант (который я к слову практиковал) можно вполне пробросить те же IPv6 туннельного брокера на свой VPS (tunnelbroker так то вообще позволяет /40 получить).
Ещё надо быть очень аккуратным с net.ipv6.conf.all.forwarding=1 - эта штука на самом деле отключает приём Router Advertisement-ов на уровне ядра на всех интерфейсах, так что если у вас перенаправляющий роутер должен конфигурироваться тоже на основе SLAAC/DHCPv6 - то для интерфейса который так конфигурируется - его надо обязательно отключать (например как net.ipv6.conf.ens5.forwarding=0), а то IP вы не получите.
>быть рандомизирован
Нет, не должен быть рандомизирован. Можно выбрать любой адрес, какой вам нравится из /64.
Это называется ip token. https://serverfault.com/questions/968641/configure-ipv6-address-on-interface-with-static-iid
Я скорее имел ввиду https://datatracker.ietf.org/doc/html/rfc4941. Большинство устройств реализуют что-то подобное. Да, при большом желании можно зафиксировать EUI, но по умолчанию большинство устройств его таки рандомизируют.
Вполне можно и /64 выдаваемую серверу распределить.
Предлагаете нарезать её на более мелкие подсети?
можно вполне пробросить те же IPv6 туннельного брокера на свой VPS
Только если очень не хочется менять хостера. Ещё один туннель неминуемо увеличит пинг.
если у вас перенаправляющий роутер должен конфигурироваться тоже на основе SLAAC/DHCPv6 - то для интерфейса который так конфигурируется - его надо обязательно отключать
Не в моём случае. Отключать не обязательно, можно воспользоваться опцией accept_ra=2.
A зачем нарезать на более мелкие подсети-то? В чём проблема прямо её и распределять?
Уточните, о какой именно /64 подсети идёт речь?
Вы предлагаете одну подсеть давать разным устройствам?
У вас VPS исключительно для IPv6 VPN, я не вижу проблем выдавать конечным устройствам конфигурироваться на основе /64 подсети выдаваемой хостером. На самом деле даже если не исключительно для VPN, всё равно, вероятность что настроенный на самом VPS X:X:X:X::1 сконфликтует со сгенеренным X:X:X:X::/64 по SLAAC-у настолько мала, что практически отсутствует (если только вы там статические адреса не настроили кому-то. Но даже если настроили, то опять таки вероятность конфликта SLAAC-а с каким-нибудь статическим X:X:X:X::1:Y чуть выше, но всё равно исчезающе мала).
А кто будет заниматься маршрутизацией на уровне VDS? Если на случайный interface id придёт трафик, кому он достанется?
В смысле? Объедините все wg* интерфейсы в bridge, вы итак уже systemd-networkd используете, там это делается тривиально. Или вы про что?
Объедините все wg* интерфейсы в bridge
У меня только 1 wg0 интерфейс.
Тогда я не понял вашего последнего вопроса.
Под interface id я понимал правую часть IPv6 адреса.
В случае, если одна /64 IPv6 подсеть будет роздана двум устройствам, которые (например) выберут себе IP ::2 и ::3, откуда VDS узнает кому какой трафик слать? Теоретически, в этом случае, пиры смогут общаться между собой, чего мне хотелось бы избежать.
Эм, вы итак предоставляете глобальные IPv6 адреса своим пирам, они в любом случае смогут общаться между собой.
А так эта проблема с роутингом решается бриджем на OpenWRT стороне, сбриджить вайргвардовский интерфейс в основной (можно прописать ebtables правила чтобы IPv4 не просачивался куда не надо), и настроить на сервере router advertisement в сторону вайргварда (radvd или dnsmasq в помощь).
Посмотрите, как работает раздача мобильного интернета с IPv6, когда оператор выделяет только одну /64 подсеть. Раздающее устройство берёт себе один адрес из подсети на внешнем интерфейсе, и запускает radvd с этой /64 на внутреннем.
И не очень понятно, зачем на wireguard нужен slaac, когда можно адрес в конфиге статически прописывать из подсети меньшего размера. Хотя он может понадобиться тогда, если вы хотите раздать по Wi-Fi с роутера IPv6, полученный по VPN с вашего VPS (андроид телефоны по wifi иначе получать IPv6 не могут). Тогда придётся выделять из /56 уже две подсети: одну на линк сервер-роутер, другую для раздачи, и прописать маршруты.
Интересно, с одной /64 будет работать в таком случае? наверное, да, если на линке сервер-роутер прописать статически маленькую подсеть вроде /126. Это не рекомендуется, но сойдёт, если хостер жадный на адреса или неохота переплачивать за отдельную подсеть. А вот если роутеров с раздачей за сервером будет несколько, одна /64 уже никак не подойдёт.
И не очень понятно, зачем на wireguard нужен slaac
Задача стояла в том, чтобы через wireguard раздать целиком /64 подсеть, а не 1 статический адрес.
Но механизм SLAAC реально не используется при этом, вы в конфиге адрес из /64 указываете. Заголовок статьи неправильный.
Попробуйте сделать, как я написал, подключить по VPN к серверу роутер и с него уже раздать IPv6 по Wi-Fi. Вот там уже понадобится SLAAC.
вы в конфиге адрес из /64 указываете.
Исключительно конфиге клиента, заметим, а не сервера. На сервере только префикс указывается.
Заголовок статьи неправильный.
В данном случае под SLAAC понимается, что клиент получает от сервера только префикс, а далее сам выбирает себе interface id и, таким образом, создаёт себе IPv6 адрес. Тут нет Router Advertisement, поскольку его заменяет сам WireGuard предоставляя префикс и его длину клиенту.
Попробуйте сделать, как я написал, подключить по VPN к серверу роутер и с него уже раздать IPv6 по Wi-Fi.
На OpenWRT это возможно и это работает.
А интересно, можно сделать так, чтобы на Wireguard действительно был SLAAC, то есть автоконфигурация адресов? То есть если у нас поменяется выданная на сервере или от провайдера сеть, на клиенте конфиг не нужно было править, ему прилетел бы новый адрес. На сервере при этом пришлось бы запустить какие-то скрипты (через dhclient, который запрашивает по prefix delegation эту сеть).
Мне кажется, что wg так не умеет. Хотя есть идея: а что, если в конфиге указать только link local адрес, и запустить на сервере radvd, возьмёт ли клиент адрес из RA сообщения? Можно попробовать так.
То есть если у нас поменяется выданная на сервере или от провайдера сеть, на клиенте конфиг не нужно было править, ему прилетел бы новый адрес.
К сожалению, пуши в wg пока не завезли.
Хотя есть идея: а что, если в конфиге указать только link local адрес, и запустить на сервере radvd, возьмёт ли клиент адрес из RA сообщения?
Не сработает. NPD работает на более низком, канальном уровне. А WG - на сетевом.
А PPP похож на Wireguard, и то, и другое предоставляет среду для передачи IP-пакетов по двухточечному каналу с аутентификацией пользователя. Как именно организован канал (serial, ethernet, IP) — не очень важно, от этого зависят некоторые параметры (MTU, например), но не сам принцип работы.
Так PPP это тоже канальный уровень.
Маршрутизация IPv6 через WireGuard с поддержкой SLAAC