В настоящее время я работаю над добавлением возможностей IPv6 в нашу сеть, и у меня есть несколько вопросов о том, что считается лучшей практикой в 2020 году для преобразования некоторых концепций IPv4, к которым мы привыкли, в мир IPv6.
В текущих настройках, которые у меня есть, нам выделяется / 64 от интернет-провайдера, и маршрутизатор объявляет этот префикс для клиентов, чтобы настроить себя с помощью SLAAC. Кажется, это работает нормально, и, насколько я знаю, у всех есть доступ в Интернет по IPv6.
Однако нам нравится иметь возможность запрашивать вещи по имени, и я не уверен, что лучше всего предоставлять записи AAAA для клиентов.
Что я сделал, так это развернул DHCPv6 с отслеживанием состояния на экземпляре dnsmasq, который запускает наш DHCPv4, и приказал ему раздавать ULA из некоторого диапазона, который, естественно, предоставляет записи AAAA для всех, кто запрашивает адрес. Кажется, это тоже работает нормально, но я знаю, что DHCPv6 с отслеживанием состояния вызывает некоторую неприязнь. Это также помогает мне консолидировать назначение серверов, которые у нас есть на статических IP-адресах, точно так же, как я делаю для DHCPv4, эти серверы по разным причинам должны быть доступны по фиксированному IP-адресу, и мы хотели бы, чтобы это продолжалось в случае IPv6.
Единственный другой способ, который я могу придумать для создания записей AAAA, - это отправить машине dnsmasq префикс RA с маршрутизатора через одноадресную передачу, а затем использовать dnsmasq для рекламы префикса GUA для slaac с помощью ra-names
вариант. Это не решило бы статические назначения адресов, хотя, насколько я могу судить, и я не уверен, насколько это надежно на самом деле. Есть ли лучший способ обработки внутренних записей AAAA, чем ULA с сохранением состояния DHCPv6?
Наконец, поскольку все начинает работать, мы сейчас рассматриваем возможность переноса наших общедоступных сервисов на IPv6. Насколько я понимаю, для этого потребуется фиксированный GUA для серверов для предоставления общедоступных записей AAAA. Я не уверен, как добиться этого с помощью SLAAC от граничного маршрутизатора, если нет какого-либо эквивалента динамического DNS. Могу ли я снова использовать DHCPv6 или другой метод ручного назначения для выбора IP-адресов в назначенном префиксе? Я не решался сделать это, потому что думал, что это может столкнуться с адресом SLAAC, и я не уверен, что произойдет, если произойдет столкновение. В качестве альтернативы у меня есть возможность запросить у интернет-провайдера a / 48, следует ли мне это делать и рекламировать один / 64 для локальных клиентов, чтобы получить возможность подключения, и другой / 64 для статических серверов? Мне это показалось излишним, мы уже и близко не подошли к заполнению сингла / 64, но это может сбивать меня с толку мое мышление IPv4.
Мне это показалось излишним, мы уже и близко не подошли к заполнению сингла / 64, но это может сбивать меня с толку мое мышление IPv4.
Прекратите считать хосты, это мышление IPv4. Подсети бывают одного размера, огромны. A / 64 может адресовать любое когда-либо созданное IP-устройство, оставляя достаточно места.
Однако адресное пространство еще больше, так что один сайт может легко запросить / 48. 64 тысячи / 64 секунды, 4 шестнадцатеричных цифры, чтобы раздать в соответствии с желаемым адресным планом.
Для / 48 что именно мне с ним делать.
Все что ты хочешь! Будьте щедры и планируйте рост. Дайте / 64 каждой подсети, каждой VLAN, SSID Wi-Fi, зоне безопасности, облачным виртуальным частям и виртуальным частям удаленного доступа, каждому хосту контейнера, «все нули» / 64 для служебных адресов тщеславия и т. Д.
По возможности агрегируйте, чтобы избежать фрагментации. Так что, возможно, делегируйте / 60 или / 56 внутренним сетям, таким как ваш DHCP-сервер, назначенный вручную статический пул, контроллер Wi-Fi или систему оркестровки контейнеров. И тестовые среды для всего вышеперечисленного.
Не обязательно быть динамическим, например DHCP-PD, особенно если у вас есть статический префикс от вашего интернет-провайдера. Но как-то отслеживать вещи в системе IPAM.
Или есть изящное разрешение, если обнаруживается конфликт?
Узлы IPv6 должны делать обнаружение повторяющегося адреса на всех одноадресных адресах, без сохранения состояния, DHCPv6, вручную или иначе. Стандарт заключается в том, чтобы останавливаться на дубликатах, а не вызывать трудные для диагностики проблемы. Случайно сгенерированные адреса в / 64 имеют очень низкую вероятность конфликтов.
ULA
ULA нет Интернет-адресация. Поскольку стандартная политика выбора адресов по умолчанию не доступна глобально, они имеют более низкий приоритет, чем даже IPv4. См. Rfc6724. Таким образом, вам понадобятся глобально маршрутизируемые (не ULA) адреса на хостах, которые подключены к Интернету IPv6.
какой-то эквивалент dynamic-dns.
Да, нужен DNS. Имена проще для людей, чем IP.
Да, зная, что IP-адрес - это обычно выбор между сервером DHCPv6, имеющим состояние, и узлом SLAAC, настроенным с помощью клиента динамического DNS. Флаги рекламы маршрутизатора A и M сообщить клиенту с сохранением состояния или без состояния.
Узлы, присоединенные к AD DS, довольно просты, ожидается, что они добавятся в DNS.
Или, возможно, настройте серверные интерфейсы с адресами без сохранения состояния, но не с произвольными адресами на основе EUI-64. Затем вы можете заранее рассчитать адрес на основе MAC-адреса и поместить его в DNS.
И, возможно, не все устройства должны быть в DNS. Если личные устройства Android разрешены в гостевом Интернете, они не будут использовать DHCPv6. Если они не управляются MDM, вы не узнаете их IP-адреса.
Первое: получи это / 48. Для обеспечения безопасности и управляемости рекомендуется не размещать все в одном широковещательном домене (VLAN).
Второе: для серверов просто настройте адреса статически. При желании вы можете использовать SLAAC, DHCPv6 и статические адреса в одной сети.
Не очень часто помещать IPv6-адреса рабочих станций в DNS, но в некоторых случаях это может быть полезно. Для бизнеса со стабильными адресами я бы не рекомендовал использовать ULA.
Что я бы сделал в вашей ситуации, так это оставить SLAAC включенным, чтобы пользователи могли получать адреса конфиденциальности и т. Д. Добавьте сервер DHCPv6 на стороне, которая выдает фиксированные адреса и помещает их в DNS, если вам это нужно. Также установите флаг M в объявлениях маршрутизатора, чтобы клиенты знали, что присутствует сервер DHCPv6.
А поскольку IPv6 использует глобальные адреса для всего, убедитесь, что у вас есть надлежащая сетевая безопасность, например брандмауэр.
В качестве альтернативы у меня есть возможность запросить у интернет-провайдера / 48, следует ли мне это сделать и рекламировать один / 64 для локальных клиентов, чтобы получить возможность подключения, и другой / 64 для статических серверов?
Абсолютно спросите у вашего провайдера a / 48. Вы не можете подсеть для / 64 без нарушения всех видов вещей (включая SLAAC).
Ваша идея разместить серверы и локальных клиентов в другой сети - тоже очень хорошая идея (даже в IPv4). Конечно, иногда сетевая инфраструктура не позволяет вам это сделать (вам нужна либо отдельная проводка, либо возможность VLAN), но, поскольку вы задаете вопрос, я предполагаю, что это не проблема для вас.
Разделение сети позволяет установить между ними брандмауэр. Поскольку в IPv6 все является общедоступным IP-адресом, гораздо важнее, чем в IPv4, тщательно настроить брандмауэр; слишком легко случайно оставить систему прямо в Интернете; это одна из основных слабостей IPv6. Если вы разделите свою сеть, такая ошибка в одной сети не приведет к автоматическому обнаружению другой.
Кроме того, если вы разделяете сети, если это имеет смысл, вы можете реализовать подход с нулевым доверием в сети на стороне сервера (что может снизить потребность в брандмауэре), не делая то же самое во внутренней сети.
Или вы можете перенести свои серверы и оставить рабочие станции в сети только с IPv4; это снижает вашу рабочую нагрузку, поддерживает старые устройства, не поддерживающие IPv6, и имеет ряд других преимуществ (хотя некоторые сторонники IPv6 будут возражать против этого).
Итог: пока ваша инфраструктура поддерживает это, определенно разделяйте свою сеть, есть много плюсов и нет реальных недостатков.
Что касается вашего второго вопроса: похоже, вы работаете в корпоративной сети приличного размера. Я настоятельно рекомендую вам реализовать решение IPAM вместо того, чтобы пытаться накатить собственное.
Общий ответ для вашей ситуации такой, как вы предложили: DHCPv6 с отслеживанием состояния и автоматическим обновлением DNS-сервера. Большинство решений IPAM в основном представляют собой эти две технологии вместе с интерфейсом управления.
Отредактировано для добавления: просто для полноты, хотя это, вероятно, не подходит для вас, вы также можете использовать mdns (также известный как bonjour или zeroconf) для разрешения имен.
Поддержка для него несколько неоднородна. Apple обычно поддерживает его, Windows 10 частично поддерживает его, но вам нужно манипулировать реестром, чтобы он работал с традиционными приложениями Windows, а мне вообще не удалось заставить его работать на Android.
Конечно, mdns также не ответит на ваш вопрос об обновлении внешнего DNS-сервера.