Slaac rdnss что это
Автоконфигурация в IPv6
В IPv6 появился новый механизм автоконфигурации узла. Называется он Stateless Address Autoconfiguration или SLAAC. Используется он для автоматического получения IP адреса и сетевого префикса узлом, без использования DHCPv6 сервера, или совместно с ним.
Действительно, когда мы создаём некоторую сеть, мы прописываем адрес шлюза и префикс этой сети на маршрутизаторе. Этой информации достаточно, чтобы выдавать адреса устройствам. Механизм SLAAC позволяет маршрутизатору назначать устройствам адреса даже если в сети нет DHCPv6.
Маршрутизатор Cisco с рабочим IPv6 интерфейсом рассылает в сеть информацию об этой сети, включающую в себя сетевую часть IP адреса и длину префикса. Кроме того, в этом сообщении содержится адрес шлюза по умолчанию для сети. Подробнее о структуре IPv6 адреса можно прочитать здесь. Сообщение это называется Router Advertisement (RA) и отправляется обычно раз в 200 секунд на мультикастовый адрес FF02::1 (подробнее об этом адресе можно прочитать в статье про мультикаст в IPv6).
Если в сети появилось новое устройство, которому необходим адрес, ему необязательно ждать 200 секунд до ближайшей рассылки, оно может направит запрос маршрутизатору (Router Solicitation или RS) и попросить его выслать настройки немедленно. Запрос маршрутизатору выполняется на адрес FF02::2.
Оба сообщения RA и RS отправляются посредством протокола ICMPv6, с мультикастовым адресом получателя в IP пакете.
Для того чтобы маршрутизатор начал полноценно обслуживать сеть (рассылать в неё RA и отвечать на RS), мало настроить IPv6 адрес на интерфейсе, необходимо так же включить режим маршрутизации для IPv6 сетей, введя команду ipv6 unicast routing в режиме глобальной конфигурации.
Существует три способа назначения адреса:
В случае использования третьего варианта, DHCP сервер выдаёт клиенту полный IPv6 адрес – все 128 бит, который назначается на интерфейсе клиента. В случае использования первых двух вариантов, маршрутизатор сообщает клиенту только сеть, в которой он находится, шлюз и префикс. Таким образом, клиенту недостаёт второй половины IP адреса (идентификатора интерфейса). Напомню, что адрес состоит из 128 бит, а маршрутизатор выдаёт максимум, только первые 64. Оставшиеся 64 бита, где должна находиться информация о хосте, должны быть заполнены самим устройством, маршрутизатору не важно, что именно устройство туда поместит, важно, чтобы первые 64 бита (сеть) были правильными. Для генерации правой половины IP адреса используется алгоритм EUI-64 или вообще генерируется случайный набор цифр.
Slaac rdnss что это
SLAAC — это способ, который позволяет устройству получить свой префикс, длину префикса и адрес шлюза по умолчанию от маршрутизатора IPv6 без помощи DHCPv6-сервера. При использовании SLAAC для получения необходимой информации устройства полагаются на сообщения «Объявления маршрутизатора ICMPv6».
IPv6-маршрутизаторы периодически отправляют сообщения «Объявления маршрутизатора ICMPv6» всем устройствам в сети под управлением IPv6. По умолчанию маршрутизаторы Cisco отправляют такие сообщения каждые 200 секунд на адрес групповой передачи всем IPv6-узлам. IPv6-устройству, находящемуся в сети, не нужно ждать этих периодических сообщений. Устройство может отправить сообщение «Запрос маршрутизатора ICMPv6», который использует адрес групповой передачи всем IPv6-узлам. Когда маршрутизатор IPv6 получает такое сообщение, он сразу же отправляет в ответ объявление маршрутизатора.
IPv6-маршрутизация не включена по умолчанию. Чтобы маршрутизатор работал как IPv6-маршрутизатор, необходимо использовать команду глобальной конфигурации ipv6 unicast-routing.
Сообщение «Объявления маршрутизатора ICMPv6» содержит префикс, длину префикса и другие сведения IPv6-устройства. Кроме того, такое сообщение указывает IPv6-устройству, как ему получить информацию по адресации. Сообщение «Объявления маршрутизатора» может выглядеть в одном из следующих 3 вариантов.
Вариант 1 (только SLACC): «Я предоставляю все необходимые вам данные (префикс, длину префикса и шлюз по умолчанию)».
Вариант 2 (SLACC и DHCPv6): «Вот моя информация, но вам понадобятся и другие данные, например, об DNS-адресах с сервера DHCPv6».
Вариант 3 (только DHCPv6): «Я не могу вам помочь. Запросите необходимую информацию у сервера DHCPv6».
Общие сведения о SLAAC
Автоматическая настройка адреса без отслеживания состояния (SLAAC) — это способ получения устройством глобального IPv6-адреса одноадресной рассылки без использования DHCPv6-сервера. В основе SLAAC лежит протокол ICMPv6. Протокол ICMPv6 аналогичен ICMPv4, но при этом он имеет дополнительные функциональные возможности и демонстрирует большую устойчивость к ошибкам. SLAAC использует ICMPv6-сообщения запроса маршрутизатора и объявления маршрутизатора, чтобы предоставить информацию об адресации и другую информацию о конфигурации, обычно предоставляемую DHCP-сервером.
Как видно из термина, SLAAC не отслеживает состояние адреса. Служба без отслеживания состояния говорит о том, что ни один из серверов не поддерживает информацию о сетевом адресе. В отличие от сервера DHCP, сервер SLAAC не знает, какие IPv6-адреса используются, а какие доступны.
На рисунке 3 показан принцип работы SLACC + DHCPV6 без отслеживание состояния.
Рис.3. SLACC + DHCPV6 без отслеживание состояния
Для отправки маршрутизатором сообщений RA, на нём предварительно необходимо настроить работу IPv6-маршрутизации. Для активации IPv6-маршрутизации необходимо выполнить следующие команды:
Существует способ создания PC1 собственного уникального IID:
EUI-64, генерация случайным образом.
Поскольку SLAAC — это процесс без отслеживания состояния, перед использованием PC1 этого вновь созданного IPv6-адреса, необходимо проверить его уникальность., PC1 посылает по протоколу ICMPv6 сообщение запроса поиска соседа с собственным адресом в качестве IPv6-адреса назначения. Если другие устройства не отвечают сообщением запроса поиска соседа, значит, адрес является уникальным и может быть использован PC1. Если сообщение запроса поиска соседей получено PC1, значит, адрес не уникален и операционная система должна установить новый идентификатор интерфейса для использования.
Этот процесс является частью процесса обнаружения соседних устройств ICMPv6 и известен как обнаружение адресов-дубликатов (DAD).
Настроен ли клиент на автоматическое получение информации об IPv6-адресации с использованием SLAAC, DHCPv6 или сочетанием обоих вариантов, зависит от настроек, содержащихся в сообщении RA. ICMPv6 сообщения RA содержат два флага, обозначающих, какой из вариантов должен быть использован клиентом.
Этими флагами являются флаг управляемой конфигурации адресов (M) и флаг другой конфигурации (O).
Рис.3.1. Варианты сообщений от RA
Функции SLAAC,DHCPV6+SLAAC,DHCPV6
Рассмотрим все три способа, изменение флагов.
1. SLAAC — Этот вариант указывает клиенту использовать только информацию из сообщения RA. Сюда входит информация о префиксе, длине префикса, DNS-сервере, MTU и информация о шлюзе по умолчанию. Далее клиент не получает никакой информации от сервера DHCPv6. Глобальный индивидуальный IPv6-адрес создаётся путём объединения префикса, полученного в сообщении RA, и идентификатора интерфейса, полученного с помощью EUI-64 или сгенерированного случайным образом.
Сообщения RA настроены на отдельном интерфейсе маршрутизатора. Для повторной активации режима SLAAC на интерфейсе, на котором мог быть установлен другой вариант работы, флаги M и O необходимо сбросить на их первоначальные значения, равные 0. Для этого применяются следующие команды режима конфигурации интерфейса:
2. DHCPV6+SLAAC — Для DHCPv6 без отслеживания состояния значение флага O установлено равным 1, а значение флага M остается со значением по умолчанию, равным 0. Значение флага O, равное 1, используется для информирования клиента о том, что на DHCPv6-сервере без отслеживания состояния доступна дополнительная информация о конфигурации.
Для того чтобы изменить сообщение RA, отправляемое на интерфейс маршрутизатора для указания использования DHCPv6 без отслеживания состояния, используйте следующие команды:
3. Протокол DHCPv6 с отслеживанием состояния (только DHCPv6)
Флаг M указывает, используется ли DHCPv6 с отслеживанием состояния. Флаг O не используется. Для того чтобы изменить значение флага М с 0 на 1 для объявления DHCPv6 с отслеживанием состояния, применяются следующие команды:
Рис.3.4. Протокол DHCPv6 с отслеживанием состояния
Процессы DHCPV6
В случае если в сообщении RA указан вариант работы DHCPv6 (с отслеживанием состояния или без), инициируется работа DHCPv6. Сообщения протокола DHCPv6 посылаются через протокол UDP. Сообщения DHCPv6 от сервера к клиенту используют UDP порт назначения 546. Клиент отправляет сообщения на сервер DHCPv6 через UDP порт назначения 547.
Клиенту — теперь DHCPv6-клиенту — необходимо определить местоположение сервера DHCPv6. клиент передаёт сообщение DHCPv6 SOLICIT на зарезервированный IPv6-адрес многоадресной рассылки FF02::1:2, используемый всеми DHCPv6 серверами. Этот адрес многоадресной рассылки действует в рамках канала link-local, это означает, что маршрутизаторы не направляют сообщения в другие сети.
Один или несколько серверов DHCPv6 отвечают DHCPv6-сообщением ADVERTISE. Сообщение ADVERTISE сообщает DHCPv6-клиенту, что сервер доступен для предоставления службы DHCPv6.
Клиент отвечает серверу DHCPv6 сообщением REQUEST или INFORMATION-REQUEST, в зависимости от того, является ли DHCPv6-сервер сервером с отслеживанием состояния или без него.
IPv6 SLAAC Attack
Прочитал недавно статью «IPv6 под прицелом» и решил написать более подробно об атаке SLAAC (SLAAC Attack), т.к. эту атаку я уже давно в голове держу, развернутого материала на русском не нашел, да и самому интересно ее было повторить.
Суть атаки
В чем суть атаки? Во-первых, она очень простая и надежная, т.к. использует стандартные технологии и инструменты ОС. По сути, вы просто становитесь единственным IPv6-маршрутизатором в сети и раздаете клиентам IPv6-подсеть, из которой клиенты берут себе адреса либо автоматически генерируя их (SLAAC), либо спрашивая у вашего же DHCPv6-сервера. Напомню, что IPv6 включен по умолчанию во всех современных десктопных, мобильных и серверных ОС, имеет приоритет над IPv4 (кроме некоторых случаев), адрес IPv6, в отличие от IPv4, может быть получен в любой момент, а не только в момент совершения подключения, и крупные веб-сайты уже давно доступны через IPv6. Атака работает как в проводных сетях, так и в беспроводных. Не все свитчи, даже современные, поддерживают фильтрацию Router Advertisement, и, как я полагаю, не все включают эту функцию, даже если она поддерживается свитчем, полагая, что раз в сети нет IPv6, то и фильтровать ничего не нужно. К слову, на данный момент, фильтр Router Advertisement можно обойти на всех свитчах, использовав недостатки реализации.
Я смог придумать две реализации атаки:
Реализация №1
С помощью этого способа, вы сможете перехватывать только реальный IPv6-трафик к хостам, которые имеют AAAA-запись. Вам понадобится IPv6-подсеть длиной /64 и какой-либо софт для Router Advertisement, я использовал dnsmasq. IPv6-подсеть 6to4 не подойдет, т.к. все 6to4-адреса имеют приоритет ниже, чем IPv4, так что нужно использовать туннельный брокер. Клиентам будем раздавать только сам диапазон адресов, без DNS, и не используя DHCPv6.
Демон dnsmasq умеет брать подсеть прямо с интерфейса, для этого достаточно указать в конфигурационном файле следующую строку:
Где wlp3s0 — сетевой интерфейс, в моем случае, беспроводной. Устанавливаем глобально маршрутизируемую подсеть 2001:470::/64 на интерфейс, запускаем dnsmasq, смотрим в wireshark:
Все компьютеры в сети сразу же назначили себе IPv6-адрес и установили маршрут по умолчанию:
Не забудьте включить маршрутизацию!
Недостаток этой реализации в том, что через ваш маршрутизатор пойдет только IPv6-трафик. Опять же, вероятнее всего, IPv4-адрес вашего компьютера будет за NAT, а значит получить IPv6-подсеть может быть не так-то просто, т.к. самый популярный протокол туннелирования — SIT — не работает за NAT. Нужно использовать либо туннелирование по протоколу AYIYA, который поддерживается у меньшинства туннельных брокеров, либо придумывать свои схемы проброса. Атака может быть замечена, если атакуемый использует какой-либо сайт с привязкой по IP. Зато, эта атака технически очень простая и применить ее можно буквально за минуту.
Реализация №2
Что же делать, если у необходимого нам хоста нет IPv6-адреса, а нам так хочется совершить незаметную MITM-атаку? Есть замечательный выход из этой ситуации — NAT64+DNS64. NAT64 позволяет вам сделать отображение всего диапазона IPv4 в /96-диапазон адресов IPv6, а DNS64 сможет отдавать такие адреса клиентам.
Под Linux существует три NAT64-демона: TAYGA (userspace) и Ecdysis (kernelspace), Jool (kernelspace), а поддержка DNS64 есть в Bind9, Unbound и специальном демоне totd, который заброшен, но все еще компилируется и работает.
Первым делом, мы должны выбрать какие-то 2 подсети, которые будем раздавать нашим клиентам. Первая подсеть нужна для отображения адресов, а вторая для маршрутизации. Я решил использовать 2001:db8:1:ffff::/96 (из диапазона «для документации») в качестве первой подсети, а в качестве второй — fde4:8dba:82e1:ffff::/64 (IPv6 ULA, аналог внутрисетевых диапазонов в IPv4).
Перенастраиваем dnsmasq:
Указываем наши настройки в TAYGA:
И в totd:
И запускаем все демоны. В итоге, получается как-то так:
Весь трафик, отправленный на диапазон 2001:db8:1:ffff::/96, фактически пойдет через IPv4.
К сожалению, DNS устанавливается только при подключении, т.к. Router Advertisement принимает ядро, а для получения DNS нужен DHCPv6, чем ядро уже не занимается. Аналогичное поведение наблюдается в Windows 7 (другие версии не пробовал).
IPv6 — прекрасный мир, стоящий скорого перехода на него
Практически все статьи, которые я видел на тему «чем хорош IPv6 и почему на него стоит пошустрее переходить», говорят только о просто более широком адресном пространстве. В лучшем случае, упомянут автоматическую конфигурацию адресов и маршрутов (stateless address autoconfiguration (SLAAC)). Это удручает, а ведь IPv6 имеет много ещё других неявных плюшек, являясь очень продуманным стеком протоколов (IPv6 + ICMPv6 + NDP)! Создаётся впечатление, что IPv6 это просто тупо про расширение адресов, а дальше то особо никакого профита. Или же некоторые статьи плачутся о том, что они не видят сиюминутного профита от внедрения/перехода. Простоту и удобство, гибкость и расширенные возможности (из-за одного только избавления от NAT-а) не так то легко измерить, как какие-нибудь задержки и пропускную способность. Решил поэтому собрать моё видение прекрасного мира IPv6 протокола и его плюсы в этой статье.
Не использовать IPv6 для построения чего-то нового, новых сетей — просто не имеет смысла, так как лишаемся массы удобств и возможностей, получая кучу геморроя от лишения этой массы удобств и возможностей. IPv6 поддерживается даже с Windows XP версии. Последний раз я проверял пять лет назад, но уже тогда SLAAC+RDNSS/DNSSL поддерживали и iOS и Android и даже Windows 10 устройства, не говоря о GNU/Linux и BSD системах.
IPv4 не является плохим протоколом. Его проблема только в том, что он никогда не задумывался для создания большой глобальной сети, где почти у каждого человека на Земном шаре будет доступ к ней прямиком из штанов (где лежит смартфон). Он создавался во времена, когда компьютеры были более быстрыми чем сети (странное сравнение?) и с кучей памяти. Сейчас наоборот: сделать 10 Gb канал связи можно тривиально и дома, но из коробки ни одна из массово используемых ОС не сможет эффективно коммутировать или маршрутизировать трафик на такой скорости.
Конечному пользователю сложно представить получаемые преимущества, так как Интернета, по факту, уже давно мало кому дают: преобладающая часть людей всегда сидела за NAT-ом и считает, что изобретение протоколов типа WebSocket, есть нечто штатное, нормальное, логичное и разумное, и ничего кроме TCP, UDP и ICMP у нас особо-то и не ходит поверх IP.
Сетевому инженеру, чисто психологически, сложно будет пересиливать себя в понимании того, что адресов и сетей реально очень много выдаётся и не имеет смысла (и даже будет только вредить удобству и простоте обслуживания) экономить на их использовании. Большая проблема — осознание того, что IP адреса уже не являются дефицитным ресурсом и думать приходится чаще всего в понятиях не единичных адресов, а целых огромных сетей минимум с /64 префиксом.
IPv6 имеет более серьёзные требования (эту часть можно обозвать недостатками):
Но нет. на практике оказалось, что для работы SLAAC нужно запускать отдельного демона (radvd в linux) у которого есть конфиг, в котором нужно указывать префикс для раздачи, тоесть получили вы префикс по dhcpv6-pd, будте добры добавить его в конфиг (скриптами конечно). Тоесть фактически отдельная сущность для раздачи IP адресов остается, причем SLAAC не умеет раздавать ничего кроме IP адресов и битового префикса (есть rfc про раздачу dns, но вроде его мало кто реализовал) и для полноценной работы рядом с ним должен быть запущем DHCPv6 сервер, который будет отдавать все остальные опции.
Это уже детали реализации, на самом деле. Авторы radvd могли бы запросто сделать и так, как ты описал. Попробуй им реквест заслать, чтобы добавить опциональное поведение.
рядом с ним должен быть запущем DHCPv6 сервер, который будет отдавать все остальные опции.
и всеравно работает совместно с новой?
сущность, может, и не нужна, но, чует мое сердце, что DHCPv6 тебе не нужен.
из популярного DNS, NTP например
то есть в 90+% сетапов нафиг не нужен.
Тоесть ты предлагаешь dns руками вбивать? Ну ок. Я сейчас говорю не про текущий DualStack, когда у тебя может быть DNS от IPv4, а про IPv6 only конфигурацию, если что.
Я предлагаю во всех некорпоративных сценариях гонять DNS-over-TLS с глобального well-known адреса.
Очевидно, что такие задачи проще решать в отрыве от основного DHCP демона. Всё-таки линуксовый софт должен быть модульным и создаваться по принципам KISS. Также, очевидно, нельзя внедрять логику SLAAC демона прямо в ядро.
По этим причинам, нужен дополнительный демон в довесок к DHCPv6. Так или иначе, ресурсов на роутере он много не жрёт.
А потом приходит товарищ майор, делает bgp hijack и все твои «мокрые киски скачать без СМС» как на ладони.
RDNSS таки уже реализовали многие. Это сильно проще чем нормальный dhcpv6 который хоть как-то на массовых устройствах начал лишь пару-тройку лет назад.
Что-что делает товарищ майор и откуда у него сертификат на cloudflare-dns.com?
нельзя внедрять логику SLAAC демона прямо в ядро
Я так понял, что речь была о сервере.
Можно ведь юзать Privacy Extensions
Можно, но по умолчанию они не включены.
И айпишник всучается без каких бы то ни было настроек, просто по поднятию интерфейса
А ты в DNS ходишь по DNS имени?
Нет, мне заранее известны IP-адреса от него.
А ты думаешь, что TLS без DNS не работает?
А ты думаешь что если тебе сделали bgp-hijack тебе tls поможет?
PKI мне поможет, естественно, иначе нафиг бы это все нужно было.
SLAAC проще и удобнее, чем DHCPv6. Он работает и в случаях, когда в сети более одного шлюза. Опция DNS есть, и прекрасно работает. Если кто-то ее еще не использует, ССЗБ.
MAC-адрес в правой части не обязателен. Сейчас принято использовать псевдослучайные квазистабильные адреса, номер RFC по памяти не скажу. В продукции Apple это появилось давно, Linux тоже поддерживает, как минимум при использовании Network Manager. Ну и Privacy Extensions никто не отменял.
как минимум при использовании Network Manager
не нужно, просто надо записать сид в /proc/sys/net/ipv6/conf/eth0/stable_secret перед поднятием интерфейса
Но речь про поведение в ядре по умолчанию.
Так если можно брать не MAC, то что все так ноют, что меньше /64 на подсеть это плохо? Ну будет подсеть /72, а в ней стабильные псевдослучайные адреса.
что все так ноют, что меньше /64 на подсеть это плохо?
есть rfc про раздачу dns, но вроде его мало кто реализовал
Как уже справедливо заметили, RDNSS через RA уже давно раздаются и понимаются, Linux, MacOS, iOS, Android (который, кстати, напротив не использует DHCP6 и эта принципиальная позиция служила источником многих эпичных перебранок), Windows 10, начиная с creator update.
Конечно, DHCP позволяет передать загружаемому хосту намного больше информации: не только NTP, но и syslog, next-server (необходимый для бездисковой загрузки или инсталляции) и кучу другого. Когда это необходимо, придётся использовать DHCP, хотя некоторые ребята пользуются DNS SRV, насколько я слышал.