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 не дойдет в виду консервативности руководства...


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

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

Это пока не реальная задача, а просто размышления над темой с чем придется столкнуться

если можно везде VPN сделать, а уже на VPN-сервере заказать /56 и настроить?

Если в центр заказать /56, раскидать всем по vpn /64, то получится что они и в интернет должны будут через центр ходить, а это не то что хотелось бы получить.

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

Some operators also use /126, /127, /112 or an alternative prefix assignment instead of /64 for managed links where addresses on the link are manually configured, and according to RFC 6164, a /127 is suggested to prevent, among others, the Neighbor Discovery exhaustion attack (RFC 6583). Please note, that not all equipment currently supports this option, so /64 is still the safest approach and has the advantage of being future proof in the event that new standards make usage of the other 64 bits for other purposes or the link becomes point-to-multipoint, etc.

Тут вообще говорится про использование /64 для соединения двух устройств.

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

Если в центр заказать /56, раскидать всем по vpn /64, то получится что они и в интернет должны будут через центр ходить, а это не то что хотелось бы получить.

Т.е. сейчас у вас выделенные разные VPN для каждого офиса?

Уверен, вы занимаетесь тем или иным мошенничеством.

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

Т.е. сейчас у вас выделенные разные VPN для каждого офиса?

Не понял вопроса. Есть центр и офисы, офисы коннектятся к центру по vpn и получают доступ к внутренним сервисам по серым адресам.

У каждого офиса есть доп. vpn канал до общественного сервиса через который они ходят в дикий интернет.

Ничего криминального.

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

4.1.5. Summary Using a global /64 prefix for the WAN connection is the recommended choice.

Это не дает развернуть кастомеру сети, но для конечных устройств типа мобильника как раз норм. Сейчас провайдеры так и делают для домашних пользователей и /48 или хотя бы /56 не дают. По крайней мере там где я просил не дали. От этого и возникают мысли у обывателя поделить /64 на всех, ведь это так много адресов. Но так это не работает.

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

Окей, тоесть выдавать каждому по /56 или /48 дабы они могли делать несколько подсетей /64 у себя в подконтрольной сети, я вас правильно понял?

Вернемся сюда:

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

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

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

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

Да можно и поделить /64 на весь регион, только без костылей типа proxy neighbor discovery это не работает. Плюс не будут работать идеи с автоконфигурацией интерфейсов. Дхцпв6 тоже не предназначен для делегирования префиксов меньше чем /64. Андроид, например, вообще не может в дхспв6. Да и пацанам такой сетап не покажешь. Я рекомендую взять /64 + /48 у he и насетапить в тестовом окружении свою задумку с помощью одного лишь /64, а потом с использованием /48 и сравнить.

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

Да можно и поделить /64 на весь регион

Регион в моем контексте - это один роутер где-то в дали от центра. Так что не надо будет там /64 делить.

только без костылей типа proxy neighbor discovery это не работает.

nd не работает есть префикс не /64? Вот это уже интересный момент...

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

В поиске ответа на вопрос почему не работает нд на префиксах меньше /64 всплывет ответ, что производители сетевого оборудования придерживаются рекомендаций по раздаче на конечные устройства префикса не меньше /64. Ибо если взглянуть на текущие фулл вью в bgp, то станет понятно что если держать в таблицах маршрутизации префиксы типа /112 то никаких обьемов памяти не хватит.

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

Чистый DHVPv6, без RA, поддерживается, вроде бы, только в Android.

А например DNS как правильнее раздавать, через RA+RDNSS или отдавать O-flag и параллельно запускать dhcp6s который отдает dns? Или и то и другое.

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

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

Вот кстати эту идею с маршрутизацией через link-local я не совсем понимаю, нет ну понятно что пакет он с интерфейса на интерфейс перекинет без проблем. Но та же трассировка будет состоять из кучи неизвестных хопов т.к. link-local не маршрутизируются за пределы линка? Или стек IPv6 умный и будет использовать глобальные адреса с WAN интерфейса для ответа? Но на wan в принципе тоже может быть только link-local адрес по логике v6...

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

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

cobold ★★★ ()

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

Что-то мне подсказывает, что я на пенсию раньше выйду, чем IPv6 внедрят - если его вообще всерьез будут внедрять повсеместно, не в качестве proof of concept, а пользы для. Мне кажется, что родят что-то более адекватное, с нормальной обратной совместимостью с IPv4, либо вообще нечто принципиально новое, типа NewIP китайского. А IPv6 никому не был и не будет нужен.

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

потому, что никто не назовёт такое деление внедрением ipv6. никто не примиет анонсы префиксов меньше /64. это можно сделать, например, для того, чтобы пройтись по граблям с proxy neighbor discovery. какие могут аргументы за внедрение ipv6 в таком исполнении?

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

а при чём здесь соотношение кол-ва адресов и кол-ва звёзд/моекул/etc? Это же ни о чём не говорит

Как не говорит? Адреса назначаются неким физ. объектам, которые состоят из тех самых молекул. Очевидно, что число объектов не может превышать числа их составляющих. Отсюда следует простой вывод о неисчерпаемости адресов IPv6 в обозримом будущем (несколько десятков поколений людей).

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

Что-то мне подсказывает, что я на пенсию раньше выйду, чем IPv6 внедрят

Вероятно, вы давно не смотрели статистику по IPv6: 30+% соединений до Google проходят через IPv6, подавляющее большинство крупных сайтов доступны по IPv6.

3 из 5 провайдеров, к которым я обращался для подключения домашнего интернета (РФ), готовы были предоставить мне IPv6. Это было в начале 2019.

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

Адреса назначаются неким физ. объектам

Не только физическим, но и виртуальным. Число виртуальных объектов неограничено(кол-вом адресов разве что). Ну и об утечках забывать не стоит. Я не знаю, насколько сильно текут адреса, но то, что они текут - это точно. Как и любой другой ресурс без жёсткого контроля

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

Адреса назначаются неким физ. объектам, которые состоят из тех самых молекул. Очевидно, что число объектов не может превышать числа их составляющих

Ах, да - атомы, протоны, нейтроны, электроны, кварки и прочая нечисть не учтена )

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

Не только физическим, но и виртуальным.

Хорошо, согласен. Но насколько виртуальных объектов больше физических? Пусть даже разница будет в 2-3 порядка, принципиально это ничего не изменит.

Ну и об утечках забывать не стоит. Я не знаю, насколько сильно текут адреса, но то, что они текут - это точно. Как и любой другой ресурс без жёсткого контроля

Не понял, что Вы имеете ввиду под утечкой адресов.

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

Ну и об утечках забывать не стоит. Я не знаю, насколько сильно текут адреса, но то, что они текут - это точно.

Не, ну если верить той методички от ripe, то адреса надо раздавать префиксами минимум по /64 и того у нас уже не 2^128 адресов, а 2^64 префиксов (минус технические)...и предлагается раздавать сразу по /48 или /56 дабы на будущее расширение сети хватило, так что идея об исчерпании ipv6 не лишена смысла, только мы врядли это все застанем.

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

Предполагаю что DllMain подразумевает что может оказаться приблизительно так же как и с V4. Начнем с, например у вас дома всего одно устройство но вы получаете /64 вам нужен всего один адрес, но получаете большую подсеть. Смотрим на пример в топике, ТС предполагает получить /56, сомневаюсь что у него такое кол-во устройств. Кто-то из провов, хоть и запросу выделяет и /48. Далее крупные корпорации понаберут себе кучу сетей, на всякий случай, это как раз про v4 когда «он все ещё заканчивается» а у корпораций куча нафиг не используемых сетей.

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

насколько виртуальных объектов больше физических?

Как заблагорассудится тем, кто будет это решать. Кто ж знает

что Вы имеете ввиду под утечкой адресов

Конкретную ситуацию я здесь не обрисую, ибо не админ, не провайдер и т. д. Абстракт: кто-то взял дофига адресов, большая часть из которых никогда не используется. Вот эти адреса и утекли

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

только мы врядли это все застанем

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

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

может оказаться приблизительно так же как и с V4

Кстати, многие, вероятно, знают какие были изначально оценки по v4 - итого всего через 20 с небольшим лет уже наметилась проблема исчерпания

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

Кстати, многие, вероятно, знают какие были изначально оценки по v4 - итого всего через 20 с небольшим лет уже наметилась проблема исчерпания

Кстати по годам вы практически угадали, не то что бы жестко «наметилась проблема» но за сетку стали просить обоснование, писал от балды, к тексту не прикапывались, но звоночек возник уже где-то через 18-20 лет. А раньше просто попросил, дали, без всяких обоснований.

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

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

В случае IPv4 такие адреса принудительно возвращались RIPE и повторно раздавались нуждающимся, насколько я в курсе.

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

Здесь хотелось бы поподробнее, особенно касательно процедуры обнаружения «лишних» адресов

Я тоже не сотрудник компании-LIRa, поэтому мог ориентироваться только на сообщения в Сети. Вот, например, цитата из статьи:

Когда в MIT выявили 14 миллионов внешних неиспользуемых IP-адресов, то больше половины из них 
решили перепродать действительно нуждающимся компаниями.

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

Хм, я так понял, они про свои адреса вспомнили и отдали их.

Возможно. Адреса - это актив. Держать их просто так довольно глупо, если есть свободные, выгоднее продать.

Это я к тому, что говорить о потерянных адресах - все равно, что о потерянных деньгах рассуждать. Да, наверное, одиночные случаи потери бывают. Но не в тех масштабах, чтобы серьезно повлиять на общую ситуацию.

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

если есть свободные, выгоднее продать

Цена растёт со временем, скорее всего. Поэтому держать до нахождения лучших капиталовложений

Адреса - это актив. Держать их просто так довольно глупо

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

[написано не политоты ради, но примера для - заход уж больно знакомый был]

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

Поддержу и дополню. Вот соседняя тема в части вложений в «виртуальность». Про продажу имени bin.com «всего-то» $339,500.00 за имя. При том что вложений 10 бакинских в год.

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

3 из 5 провайдеров, к которым я обращался для подключения домашнего интернета (РФ), готовы были предоставить мне IPv6. Это было в начале 2019.

Имена в студию!

Потому что в Питере я знаю два с половиной провайдера которые зоть как-то дают ipv6 физикам и то на костылях(скайнет даёт /64 но работает настолько нестабильно что я от них отключился, даёт дом.ру но только через pppoe и только /64 динамический, tilera вроде давала, но их абонентом не был, только по слухам знаю). Причём получить хотя бы /56 невозможно, отмазываются неготовностью биллинга к такой херне.

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

Вот кстати да, мне интересно почему все ломятся решать вопрос изоляции через nat, вместо ULA для внутрикорпоративного и роутингом филиальных сетей поверх ipsec? А в внешку ходить с GLA адресов хоть и PA.

Но я не настоящий админ, так he.net sage всего лишь.

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

вместо ULA для внутрикорпоративного и роутингом филиальных сетей поверх ipsec? А в внешку ходить с GLA адресов хоть и PA.

Ну я примерно такую схему и описал, только вместо ULA тоже глобальные адреса. Вопрос, как объяснить приложениям что надо ходить с определенного ip? В linux это скорее всего через netns решается, но у пользователей windows и ничего с этим не поделаешь.

Хотя...тут вопрос как оно с ULA работает, там вроде можно роуты через RA передавать и тогда можно явно сказать что на ULA адреса ходить через внутреннюю сеть и система сама допрет какой адрес подставить...но тогда это получается тот-же VPN между офисами что и сейчас IPv4.

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

Вы прочитали мой ответ полностью?

как вы сейчас решаете задачу с ipv4? Так же и решайте с ipv6.

Про NAT

но ipv6 умеет в nat

Я написал лишь, то что он умеет в NAT. Многие как и я до недавнего времени думали что оно не умеет.

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

Далее крупные корпорации понаберут себе кучу сетей, на всякий случай, это как раз про v4 когда «он все ещё заканчивается» а у корпораций куча нафиг не используемых сетей.

Ну так и разрешаться данная ситуация будет точно так же, как и в случае IPv4 - по мере необходимости неиспользуемые сети будут передаваться нуждающимся. Я, кстати, до сих пор не вижу существенного роста цен на IPv4-адреса, несмотря на многолетние разговоры об их исчерпании. Возможно, потому, что мне, как конечному пользователю, без надобности сети выше /24.

Это я к тому, что утечка адресов, о которой говорит DllMain, не является необратимой, со временем такие адреса вернутся в общий оборот.

Serge10 ★★★★★ ()