Между IPv4 и IPv6: решаем нехватку адресов с помощью CGNAT

Интернет пришел, пришел во все без исключения аспекты нашей жизни. От осознания того, какие устройства имеют порты для подключения к сети,  можно с ума сойти. Простой пример: я достаточно консервативен в этом отношении, но уже подключил:

• телевизор (2 штуки);
• телефон (2 сим);
• видеорегистратор;
• машину;
• собаку (ошейник с GPS/GPRS). 

На очереди:

• свет в доме;
• чайник;
• гладильная доска.

А в перспективе еще много чего. Дома, на работе, в машине, в общественном транспорте, на даче - везде есть доступ в интернет. Легче уже сказать, где его нет…Хотя, скорее уже наоборот - труднее, поскольку интернет есть везде.

Количество "Connected"-устройств растет непомерными темпами. Статистика и прогнозы роста аппаратных средств, которым нужен IP-адрес, не поддается анализу, но все источники сходятся в том, что рост носит экспоненциальный характер, и тенденция эта сохранится в ближайшие 5-10 лет.

С очередным расширением сети ушел в продакшн очередной блок IP-адресов, а их по сусекам почти не осталось… LIR PI  не выдает (что предсказуемо уже лет 5), а PA дорожают с каждым годом, да и аренда столь критического ресурса пугает немалыми рисками. Остался практически последний шанс получить статус LIR и заветную /22, и, судя по последним новостям RIPE, скоро такого шанса не станет вовсе: европейский регистратор раздал больше половины из последнего /8 блока. Да и весь запас адресов на исходе: 

Глядя на график становится ясно, что прогнозы регистраторов сбываются. Несмотря на все старания RIPE продлить агонию, в 2017 году выдано около 4 млн. адресов, а всего их осталось 11 миллионов. И это говорит о том, что к 2020 году их не станет вовсе. А операторам придется делать выбор: усиленно экономить IPv4 или переходить на IPv6.

Размышляя над будущей архитектурой сети, я прихожу к выводу, что, судя по темпам внедрения IPv6, ближайшие (как минимум) 10-15 лет основной трафик все же останется на 4 версии интернет-протокола. В России сегодня в анонсах BGP только около 15% AS имеют IPv6, а в мире - чуть больше 25% (Источник), трафик IPv6 в MSK-IX составляет менее 1% от IPv4 (Источник), по данным Гугла - чуть более 20% пользователей в мире (и только 1.34% в России) заходят с IPv6 (Источник). Рост трафика IPv6 есть, но он не столь значителен, чтобы всерьез беспокоиться и спешить с его внедрением. Связано это с тем, что нативная поддержка IPv6 до сих пор реализуется не во всех клиентских устройствах! Даже новых, даже в суперновомодных штуках, претендующих на новое поколение IoT-устройств. Так что, как верно подмечено в статье  одного из сотрудников Google, Avery Pennarun, после тотального перехода сетей на IPv6, нам всё ещё будет нужен...NAT. Чтобы устаревшие IPv4-лампочки смогли добраться до интернета.

Статей про реализации IPv6 можно найти предостаточно. Усредняя мегабайты прочитанного текста и собственные эксперименты, заключение на конец 2017 года такое: внедрять IPv6 нужно, но осторожно. Граблей будет много, и у каждого они окажутся свои. С поддержкой v6 пока еще все плохо даже на операторском оборудовании (про грабли внедрения можно почитать хотя бы вот тут). Внедрять нужно DualStack, т.е. выдавать клиенту адреса IPv6 и IPv4 одновременно. А это значит, что остатки IPv4 все еще нужно раздавать клиентам, и скоро они будут стоить на вес золота, и их надо экономить. Следовательно, в ближайшие (как минимум) 10 лет NAT никуда не денется, а значит планировать развитие сетей нужно с учетом реализации Dual Stack, либо просто закупать новые железки только с поддержкой v6, чтобы впоследствии получить как можно меньше проблем.

Прогнозируя рост трафика и количества абонентов, убеждаюсь в том, что на существующем железе, которое реализует NAT, достаточно скоро ресурсы закончатся, и надо будет расширяться. Решить необходимо следующие задачи:

• обеспечить заданное количество трансляций на одного абонента;
• обеспечить Address Pooling — все соединения от одного клиента должны транслироваться в один и тот же белый IP;
• ограничить время жизни одной трансляции;
• вести лог трансляций (для СОРМ).

Какие же решения нам предлагает рынок? 

Выбор аппаратных решений - это выбор бренда, и надежда на стабильность и надежность. Это примерно, как выбор топового автомобиля - Феррари, Ламборджини, Макларен…Все они безусловно хороши, но и бюджет на их приобретение весьма велик, а эксплуатация требует высокой квалификации инженерного состава. И эта квалификация, помимо того, что весьма недешево обойдется, должна быть заточена под конкретного производителя. К примеру, Juniper готов научить Вашего админа настраивать NAT на своем оборудовании чуть более, чем за 700 USD (тут), и только при условии наличия сертификата AJSPR. Таким образом, если у Вас в ядре сети уже трудятся Cisco ASR, то, конечно же, нет смысла рассматривать, например, Ericcsson для вынесения на него одной единственной функции.

С другой стороны, реализация NAT на чисто аппаратных средствах (ASIC), это скорее экзотика, и как доказательство тому - модуль CGSE для Cisco представляет собой ни что иное, как х.86 сервер с проприетарным софтом на базе FreeBSD, адаптированный под работу в составе аппаратного роутера. И в этом смысле, его цена кажется совсем заоблачной. Но наиболее желанным функционалом брендовых аппаратных решений, является "настроил и забыл", жаль, только, что он так до сих пор никем и не реализован на 100%. Стоило бы вынести в отдельный раздел виртуализованные платформы, такие как NFWare Virtual Carrier Grade NAT, Juniper vSRX / vMX и прочие NFV-решения, для которых NAT является интересным кейсом для концепции распределённого NFV (dNFV), когда сетевые функции логически централизованы (имеем единый пул адресов и ресурсов, и единую точку управления), но при этом территориально распределены (источник). Но это тема достойна отдельного и достаточно емкого обзора.

Есть мнение, что за NFV будущее, не зря же этой тематикой интересуются и именитые бренды, традиционно занимающие топовые позиции на рынке операторского железа, и крупные инвесторы, активно финансирующие все, что связано с виртуализацией, в том числе и сетевых функций (на примере АФК Системы и NFWare). Но NFV, в рамках данной статьи, более касаться не буду.

Также, несколько особняком стоит Mikrotik, который может быть реализован на платформе х.86 и не х.86 (CCR), и в виртуализованной среде (CHR), но, тем не менее, это чистой воды софт-роутер, обрабатывающий практически все функции одинаковыми процессорами. Но, в виду того, что CCR, это законченное устройство с проприетарным софтом - я отнес его также в раздел аппаратных (кстати, это одно из немногих решений для малых сетей - предел производительности в режиме NAT+шейпер около 4-5 Гбит/с для модели CCR-1036), а RouterOs для х.86 - софт - он попал в раздел х.86.

Самосбор на Linux/FreeBSD - это, если вернуться к автомобильной тематике, раллийный автомобиль. Надо взять платформу, изначально предназначенную для гражданских целей, грамотных механиков, и пилить, крутить, настраивать, перестраивать и надеяться, что в конечном итоге на всем этом можно очень быстро поехать на встречу победе…Все зависит на 90% от тех, кто будет это реализовывать и поддерживать. Как правило,  такой человек в компании один. И строит систему он исходя из своего понимания процесса. И поддерживает систему он же. А что будет, если он уйдет? Насколько качественно задокументирован функционал? Поддерживать чужую систему подобного рода также затратно, как и написать ее с нуля.

Альтернативой самосбору и именитым брендам являются чисто софтовые решения, такие, как  RDP.ru, Carbon Soft,  VAS Experts и т.д. В автотерминах - это тюнинг-ателье, которые за определенную сумму денег, из гражданской машины могут сделать весьма впечатляющий спорткар, во многом не уступающий именитым брендам. На сегодняшний момент, для средних и даже крупных сетей, этот вариант подкупает массой достоинств. А именно: х.86 - распространенная платформа, компоненты которой можно купить практически в любом крупном городе, и они зачастую есть на складе у поставщика. Аппаратная часть заметно дешевле тех же модулей для Cisco или Juniper, что позволяет держать их в ЗИПе. Можно модернизировать платформу, заменив аппаратную часть на более производительную и докупив лицензии, а высвободившееся оборудование задействовать для других целей. Т.е. вопросы резервирования легко решаемы и концепция pay-as-you-grow видна во всей своей красе. Кроме того, софтовые решения, такие как СКАТ DPI от VAS Experts, выполняют еще ряд задач, которые в случае аппаратных решений придется реализовывать отдельно. Это кэширование трафика, защита от DDOS, и другие прелести полноценного DPI, такие как блокировки в соответствии с ФЗ-139, блокировка и замена рекламы, журналирование трансляций и экспорт данных в СОРМ-3, сбор статистики по типам трафика, возможность реализации некоторых доп. услуг, как, например, "Детский интернет" и т.д.  Что немаловажно, на рынке софтовых решений очень хорошо представлены отечественные производители, а это помимо гордости за отчизну, еще и русскоязычная поддержка, у которой нет языкового барьера с разработчиками.

Недостатки у х.86 решений тоже очевидны - в первую очередь это касается грамотного подбора аппаратных компонентов. Ошибки чреваты проблемами с производительностью и отказоустойчивостью. Инсталляция системы (если производитель не предоставляет такой услуги) может оказаться крайне нетривиальным занятием. Однако адекватный поставщик софта всегда должен помочь как с выбором аппаратной части, так и с инсталляцией и вводом в эксплуатацию. Отдельно стоит отметить, что решение должно быть сертифицированным, тут думаю, вопросов "зачем" и "почему", возникнуть не должно.

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