Решаем нехватку адресов с помощью CGNAT
Интернет пришел во все без исключения аспекты нашей жизни. От осознания того, какие устройства имеют порты для подключения к сети, можно с ума сойти. Тем временем количество IP-адресов уменьшается прямо пропорционально.
Простой пример: я достаточно консервативен в этом отношении, но уже подключил:
- телевизор (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 в одной коробке — оптимальное решение по совокупности требований к стоимости, функционалу, масштабируемости и ремонтопригодности.
