LINUX.ORG.RU
ФорумAdmin

IPv6 в энтерпрайзе

 , ,


3

3

Есть у кого истории успешного внедрения IPv6 в существующих компаниях?

Предположим есть средний бизнес, около 30 офисов по стране и один центральный. Сейчас все работает на L2TP/IPsec+OSPF. Когда-нибудь придет время все это переводить на IPv6, ну допустим договоримся с ISP чтобы в региональные офисы по префиксу /64 выделили, в центральный /56 (там много подсетей). Но маршрутизаторах настраивается шифрование транзитного трафика транспортным IPsec, потребность в L2TP и OSPF отпадает (хотя, OSPF наверное в центральном останется).

А что дальше? Сейчас за пользовательскими компами закреплены IPv4 и есть фильтры по IP на маршрутизаторах и оконечных серверах. Получается, что SLAAC не подходит и надо будет IA_NA раздавать по DHCP. Но DHCPv6 не умеет раздавать def. route, типа надо использовать LinkLocal адрес маршрутизатора и вот тут мой мозг ломается, к каким проблемам это может привести? Из очевидно в трассировке не будет видно часть хопов (или в IPv6 стек умный и должен отвечать с Global адреса, а если их несколько, как он поймет с какого?)

Дальше, есть указание скрывать внешние IP при выходе в «дикий» интернет, т.к. IPv6 привязывается к юр. лицу префиксом, то надо скрывать целиком префикс...ну окей, покупаем VPN с /56, делаем до него туннельный IPsec и либо надеемся что vpn провайдер будет dhcpv6-pd в туннель пускать, либо статикой.

Окей у нас раздается на ПК конечного пользователя два адреса: один для внутренних сервисов (по dhcp), второй для внешних (по slaac). Все ПК на Windows (это от меня не зависит) т.к. там 1c и прочая порнография. Как оконечным приложениям объяснить какой адрес использовать в качестве src? И как убедиться, что трафик не «утечет» с неправильного.

А еще есть firewall...в схеме с NAT можно было сделать простой firewall, который lan-to-wan пропускает новые соедиения, а обратно только установленные, получается дополнительная линия защиты...IPv6 говорит нам о том, что между двумя хостами должна быть полная связанность, получается на маршрутизаторах надо разрешать входящие соединения wan-to-lan иначе часть сервисов может не заработать и остается надеяться на нормально работающий firewall на оконечных устройствах.

Это все пока просто размышления на фоне изучения IPv6 и я думаю что до реальной ситуации IPv6 не дойдет в виду консервативности руководства...

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

это вроде как нельзя, назначать адреса надо одним способом

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

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

NAT6:6? Ну да в принципе можно попробовать на VPN делать NAT, но это не по философии V6 получается.

А такое есть? философия V6 ? Вы делаете так как вам нужно. А V4 или V6 разницы не имеет.

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

Какая философия имеется ввиду? Глобально уникальный адрес для каждого устройства?

Ну типа того, это сейчас софт проектируется для работы с NAT, а в «идеальном мире с ipv6» никакого NAT быть недолжно и неизвестно как софт написанный в эпоху v6 будет на nat реагировать.

Kolins ()

Почему, кстати, миграция вызывает столько проблем - там же трансляцию адресов замутить можно. Т. е. v4 -> v6 проходит гарантированно, v6 -> v4 проходит, если никто в период миграции не будет за диапазон v4 своими адресами вылазить

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

Я не знаю, почему насчёт nat-а так много негатива. Ну то есть понятно, что приложения в server-mode отваливаются, но это уже сколько лет решено проксями для протоколов более высокого уровня. Адресовать человека даже по уникальному белому ипшнику всё равно проблематично(в случае смены подсети этим человеком)

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

Адресовать человека даже по уникальному белому ипшнику всё равно проблематично

Это позиция компании, что белые адреса (оформленные на юр. лицо) светиться не должны.

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

Я не знаю, почему насчёт nat-а так много негатива.

Большая нагрузка, записи conntrack как бэ «не добавляют снижения» нагрузки, в отличии от простого роутинга.
Но с учетом указанного в топике, что сейчас робит на v4, разницы не будет и на v6.

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

Да там не только conntrack, надо в заголовок лезть и менять адрес+порт+чексуммы, а если ALG включен, то и транспортные заголовки читать...так что ненависть не на пустом месте.

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

Ну может станет как v4, когда поймут что адреса могут закончится отойдут от идеи EUI-64 и /64 на подсеть и будут более вменяемые, типа /112 выдавать...2^16 адресов для конечной квартиры или офиса - это более чем дофига.

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

Кто-то тут из хэйтеров v6 писал, что когда внедрят v6 по всей планете уже будет разработан v10. Судя по «скорости» внедрения v6 у провов нам до него ещё очень далеко. Так что имхо это правильное высказывание.

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

Не знаю, если отбросить фигню вида «адресов хватит всем и ещё останется» и никакую скорость миграции, v6 вполне хорош. Тот же v4 с расширением адресов и некоторыми небольшими доработками

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

Ну если посчитать, то таких подсетей около 6млр вроде выйдет (это не вычитая мультикаст и прочие служебные), на каждого жителя по подсети не получится, но всеравно дофига и думаю мы до кризиса адресов v6 не доживем даже с /64.

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

/64

Давно пилиться. Но все ещё есть проблемы по отзывам. У меня дома туннельный /64 распилин, на современных дистрах и устройствах уже норм робит. Ранее были проблемы, здесь создавал тему.

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

А еще есть firewall…в схеме с NAT можно было сделать простой firewall, который lan-to-wan пропускает новые соедиения, а обратно только установленные, получается дополнительная линия защиты…IPv6 говорит нам о том, что между двумя хостами должна быть полная связанность, получается на маршрутизаторах надо разрешать входящие соединения wan-to-lan иначе часть сервисов может не заработать и остается надеяться на нормально работающий firewall на оконечных устройствах.

тут всё неправильно, представь себе, что для ipv4 не изобрели NAT. NAT никак не отменяет необходимость иметь firewall, и вообще это 2 разных понятия.

ukr_unix_user ★★★★ ()

в региональные офисы по префиксу /64 выделили

тут тоже неправильно. /64 выделяют конечному устройству. и её делёж хоть и возможен, но считается дурным тоном.

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

NAT никак не отменяет необходимость иметь firewall

Да это понятно. Я к тому что приложения делаются с учетом nat и того что напрямую не связаться с конечным хостом. И на firewall можно считать все NEW подключения из вне враждебными.

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

Не, выделяется /64 на оконечную подсеть, а уже в ней устройства выбирают себе адреса по EUI-64 (ну или dhcp). Выделять по 2^64 адресов на каждое устройство - это перебор...

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

Выделять по 2^64 адресов на каждое устройство - это перебор…

даже для связи маршрутизаторов между собой выделяют по /64. тут дело вовсе не в количестве адресов в подсети /64 а в удобстве управления префиксами на маршрутизаторах в том числе.

ukr_unix_user ★★★★ ()

У вас есть, как мне кажется, некоторые заблуждения касательно IPv6.

Окей у нас раздается на ПК конечного пользователя два адреса: один для внутренних сервисов (по dhcp), второй для внешних (по slaac).

DHCPv6, в общем случае, не может работать сам по себе, как в IPv4. Первичная настройка осуществляется с помощью Route Advertisement, и уже внутри Route Advertisement может быть указан флаг, чтобы клиент обратился к DHCP и запросил себе адрес.

Внутренняя сеть может быть организована полностью на публичных адресах, может быть на публичных адресах + ULA (аналог приватных диапазонов типа 10.0.0.0/8 в IPv4), либо как-нибудь ещё, причем количество разных диапазонов на одном ПК не ограничено, у меня вполне бывает, что на одном интерфейсе по 10+ адресов, причем маршрутизация между ними работает корректно автоматически (как правило), в отличие от IPv4, где нужно настраивать таблицы и правила маршрутизации.

Я рекомендую вам на каждый офис запрашивать диапазон /56, как рекомендует RIPE. В IPv6, в общем случае, минимальная единица адресации — /64, и если вы будете запрашивать у провайдера только одну /64, вам будет очень неудобно настраивать маршрутизацию и логическую сегрегацию сегментов, а с /56 вы сможете, например, выделить /64 под публичный интернет, /64 для внутренних ресурсов конкретного филиала, /64 для серверов, /64 для административных нужд, и по каждой /64 будет удобно настраивать общие правила доступа на межсетевом экране, а не для каждого отдельного адреса.
Одну /64 банально нельзя «легко» раздать в локальную сеть: если сеть direct connected, а не routed (когда настроена на провайдерском маршрутизаторе непосредственно на интерфейсе, и используется ND, а не маршрутизация) вам придётся применять костыли в виде nd-proxy (аналог arp-proxy), а если сеть routed, то будут проблемы с назначением глобального адреса самому маршрутизатору, на котором настраивается IPv6.

Если вам не нравится идея маршрутизации по глобальным адресам, и вы мыслите категориями NAT в IPv4, то не стоит беспокоиться: любые современные межсетевые экраны можно настроить на блокировку входящего трафика, но при этом разрешить любой исходящий, при этом не будет происходить трансляция адресов.
Либо можно использовать только stateless-экран, с блокировкой портов ниже 1024, как это делает мобильный МТС по умолчанию (да, у МТС в РФ есть IPv6 на всю страну, включена по умолчанию).

Дальше, есть указание скрывать внешние IP при выходе в «дикий» интернет, т.к. IPv6 привязывается к юр. лицу префиксом, то надо скрывать целиком префикс…ну окей, покупаем VPN с /56, делаем до него туннельный IPsec и либо надеемся что vpn провайдер будет dhcpv6-pd в туннель пускать, либо статикой.

Ничего не понял. Что имеется в виду под скрытием адреса?

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

никто подсеть /64 не дает.

говорить за всех не нужно. мой провайдер даёт, scaleway даёт, he вообще раздаёт по /48 на брата один ipv4. а вот тех кто даёт меньше чем /64 на устройство действительно мало или нет вообще или они ССЗБ.

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

Учитывают что за 1 ip может быть несколько пользователей и что просто так нельзя в обратку отправить.

вот тут вообще непонятно о чём идёт речь, пример такого приложения можно увидеть?

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

Первичная настройка осуществляется с помощью Route Advertisement, и уже внутри Route Advertisement может быть указан флаг, чтобы клиент обратился к DHCP и запросил себе адрес.

Это от клиента зависит как я понял. Можно как в v4 запускать dhcp6c на интерфейсе и он получит адрес. В идеале да, должен запускать только когда M-flag.

Внутренняя сеть может быть организована полностью на публичных адресах

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

и по каждой /64 будет удобно настраивать общие правила доступа на межсетевом экране, а не для каждого отдельного адреса.

Увы, но сейчас правила фильтрации на серверах завязаны на конкретные компы сотрудников. А насчет /56 в каждый регион...ну конечно можно взять с запасом, но объективно сейчас все ресурсы сконцентрированы в одном офисе и не думаю что в офисе из 3 сотрудников появится серверная подсеть.

Одну /64 банально нельзя «легко» раздать в локальную сеть

Мне по IA_PD приходит префикс (/64), я беру из него адрес назначаю на LAN, остальные по SLAAC или DHCP раздаю клиентам. На WAN беру адрес из IA_NA или SLAAC. Так ведь? Там где приходит префикс /56 я его разбиваю и по DHCP6-PD раздаю на нижестоящие роутеры более мелкие подсети.

Если вам не нравится идея маршрутизации по глобальным адресам

Не, в этом и вся суть, чтобы все ходили по глобальным адресам и убрать VPN между офисами.

Ничего не понял. Что имеется в виду под скрытием адреса?

Сейчас, когда у провайдера покупается IP он покупается на юр. лицо, у СБ от этого жопа горит и требуют чтобы адрес не светился, поэтому используем vpn где он миксуется с трафиком других пользователей.

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

he вообще раздаёт по /48 на брата один ipv4.

Ну да т.к. в теории может быть множество подсетей /64 за одним роутером. Я не понимаю откуда вы взяли что на каждое оконечное устройство полагается по 2^64 адресов?

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

вот тут вообще непонятно о чём идёт речь, пример такого приложения можно увидеть?

Которые не переваривают NAT? Ну банальные ftp, sip (да для них есть костыли которые лезут в пакет дальше сетевого заголовка и подменяют адреса там), ipsec(без nat-t).

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

Это от клиента зависит как я понял. Можно как в v4 запускать dhcp6c на интерфейсе и он получит адрес. В идеале да, должен запускать только когда M-flag.

Чистый DHVPv6, без RA, поддерживается, вроде бы, только в Android. Ну и в Linux, если вручную демон запустить, наверное.

Мне по IA_PD приходит префикс (/64), я беру из него адрес назначаю на LAN, остальные по SLAAC или DHCP раздаю клиентам. На WAN беру адрес из IA_NA или SLAAC. Так ведь? Там где приходит префикс /56 я его разбиваю и по DHCP6-PD раздаю на нижестоящие роутеры более мелкие подсети.

Да, верно. Не обязательно назначать адрес из IA_PD на LAN-интерфейс маршрутизатора, всё будет работать и через link-local-адрес.

Сейчас, когда у провайдера покупается IP он покупается на юр. лицо, у СБ от этого жопа горит и требуют чтобы адрес не светился, поэтому используем vpn где он миксуется с трафиком других пользователей.

Вы скамом занимаетесь, что ли? Зачем вам, в таком случае, вообще внешние диапазоны и глобальная адресация, если можно везде VPN сделать, а уже на VPN-сервере заказать /56 и настроить?

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

Которые не переваривают NAT? Ну банальные ftp, sip

ну так да, эти разработывались с упором на то что никаких натов нет и коммуникация происходит напрямую. с переходом на ipv6 можно будет вдохнуть в эти протоколы вторую жизнь.

ukr_unix_user ★★★★ ()