Решаем нехватку адресов с помощью CGNAT
Интернет пришел во все без исключения аспекты нашей жизни. От осознания того, какие устройства имеют порты для подключения к сети, можно с ума сойти. Тем временем количество IP-адресов уменьшается прямо пропорционально.
Простой пример: я достаточно консервативен в этом отношении, но уже подключил:
Количество «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, достаточно скоро ресурсы закончатся, и надо будет расширяться. Решить необходимо следующие задачи:
Выбор аппаратных решений — это выбор бренда, и надежда на стабильность и надежность. Это примерно, как выбор топового автомобиля — Феррари, Ламборджини, Макларен…Все они безусловно хороши, но и бюджет на их приобретение весьма велик, а эксплуатация требует высокой квалификации инженерного состава. И эта квалификация, помимо того, что весьма недешево обойдется, должна быть заточена под конкретного производителя. К примеру, 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 в одной коробке — оптимальное решение по совокупности требований к стоимости, функционалу, масштабируемости и ремонтопригодности.
Шлюз трансляции сетевых адресов операторского уровня Carrier-Grade NAT компании F5 Networks
Реализуемый функционал
NAT44
Функционал NAT44 обеспечивает трансляцию частных адресов IPv4 в публичные («белые») адреса IPv4 из определенного пула публичных адресов IPv4 в CGNAT.
Шлюз CGNAT поддерживает технологию mapping (RFC 4787): для каждого частного и частного порта клиентской сессии гарантируется постоянство публичных и порта, независимо от и порта назначения в публичном адресном пространстве. Это значительно сокращает таблицу трансляций, упрощает мониторинг и анализ пользовательских сессий.
NAT64
Операторам, внедряющим IPv6 на своих сетях, CGNAT предлагает функционал NAT64. Этот функционал дает возможность операторам связи прозрачно и управляемо обеспечивать пользователям услуг на базе IPv6 доступ к контенту и ресурсам с адресами IPv4, транслируя адреса IPv6 в публичные адреса IPv4.
Port Control Protocol (PCP)
Многие одноранговые (P2P) и многопользовательские игровые приложения используют стандарт UPnP для установки соединений между клиентами. Однако протокол SSDP, который обеспечивает обнаружение устройств и приложений UPnP, не работает через устройства NAT операторского уровня.
Application Layer Gateway — шлюз уровня приложений
При передаче голоса поверх пакетной сети (VoIP), использовании видеоконференций и других служб SIP/RTSP сигнальные сообщения содержат для установления соединения между абонентами для передачи звука или видео. Однако при прохождении трафика SIP или RTSP через в сигнальных сообщениях не транслируются, что не дает возможности абонентам установить соединение.
CGNAT реализует функционал шлюза уровня приложений (ALG) и преобразует как в заголовках пакетов, так и внутри сигнальных сообщений протоколов SIP/RTSP, а также обеспечивает прохождение сессии медиатрафика через NAT. Таким образом медиатрафик, использующий сигнализацию SIP/RTSP, прозрачно транслируется через устройство CGNAT, обеспечивая бесперебойную передачу видео и голосовых звонков.
Функционал ALG в решении CGNAT поддерживается и для протокола PPTP.
Туннельные режимы работы
Производительность системы
Решение CGNAT масштабируется для обслуживания до 480 миллионов одновременных соединений, поддерживает установление до 10,4 миллионов новых соединений в секунду и обеспечивает общую пропускную способность до 320 Гбит/с.
Методы CGNAT были впервые использованы в 2000 году для удовлетворения срочной потребности в большом количестве адресов IPv4 при развертывании общих служб пакетной радиосвязи (GPRS) в мобильных сетях. Предполагаемое количество развертываний CGNAT увеличилось с 1200 в 2014 году до 3400 в 2016 году, при этом 28,85% исследованных развертываний приходятся на сети операторов мобильной связи.
СОДЕРЖАНИЕ
Общее адресное пространство
Это побудило некоторых интернет-провайдеров разработать политику в Американском реестре Интернет-номеров (ARIN) для выделения нового частного адресного пространства для CGN, но ARIN передал IETF перед реализацией политики, указав, что это не типичная проблема распределения, а резервирование. адресов для технических целей (согласно RFC 2860).
Устройства, оценивающие, является ли IPv4-адрес общедоступным, должны быть обновлены для распознавания нового адресного пространства. Выделение большего объема частного адресного пространства IPv4 для устройств NAT может продлить переход на IPv6.
Недостатки
Критики NAT операторского уровня аргументируют следующие аспекты:
В случаях запрета трафика на основе IP-адресов система может заблокировать трафик пользователя, рассылающего спам, путем запрета IP-адреса пользователя. Если этот пользователь окажется за NAT операторского уровня, другие пользователи, использующие тот же публичный адрес со спамером, будут ошибочно заблокированы. Это может создать серьезные проблемы для администраторов форумов и вики, пытающихся устранить деструктивные действия одного пользователя, использующего IP-адрес с законными пользователями.
«Эхо прошлых лет»: Как решается вопрос недостатка адресов IPv4
IPv4 позволяет использовать около 4,3 млрд адресов. Однако «мощности» инфраструктуры интернета, которую заложили в 70-х годах XX века, сегодня становится недостаточно, поскольку в то время никто не предполагал такого быстрого роста потребителей. За последние 20 лет число интернет-пользователей выросло практически в 60 раз, во многом благодаря густонаселенным странам — Индии и Китаю. Также этому поспособствовало распространение мобильных устройств.
Управлением адресным пространством и раздачей IP-адресов занимается Администрация адресного пространства интернета IANA и региональные интернет-регистраторы (ARIN, APNIC, AfriNIC, LACNIC, RIPE NCC). В начале 2011 года IANA выделила последние пять из оставшихся блоков адресного пространства региональным операторам.
Тогда специалисты организации предсказали, что адреса будут исчерпаны в течение последующих пяти лет. И вот эти пять лет подошли к концу и о приостановке выдачи адресов заявила LACNIC. Поэтому мы решили обратиться к этой теме вновь и посмотреть, куда человечество продвинулось в решении сложившейся ситуации.
Что делать
В качестве одного из возможных решений сейчас предлагается усилить контроль за адресами. Изначально диапазоны выдавались огромными блоками, но многие организации, получившие их в свое распоряжение, сегодня перестали существовать, а реестр в то время не велся. Поэтому необходимо вернуть все адреса, разбить их на более мелкие кластеры и раздать повторно.
Другое решение — внедрение системы IPv6, которая представляет собой последнюю версию IP с практически неограниченным количеством адресов (2 в степени 128). Однако здесь возникает определенная сложность, поскольку протокол IPv6 несовместим с IPv4, что замедляет и усложняет переход.
Есть еще третий вариант. Обратиться к трансляции сетевых адресов (Network Address Translation, NAT), преобразующей множество локальных адресов организации в единый внешний. Механизм работы NAT описывается в RFC 1631, RFC 3022.
Выделяют несколько видов NAT. Первый — статический, который преобразует внутренние адреса во внешние «в масштабе» один к одному. Второй — динамический, транслирующий один внутренний адрес на внешний из предоставленного диапазона. Трансляция осуществляется так же, как и в статическом NAT, только внешний адрес выбирается случайным образом из тех, которые были свободны в момент преобразования.
И, наконец, третий вариант — это так называемый перегруженный NAT (NAPT, NAT Overload, PAT) — является формой динамического NAT, в которой несколько внутренних адресов отображаются на один внешний. Именно этот вариант способен помочь при нехватке публичных IP-адресов.
Максимальное число возможных портов составляет 65 тыс., поэтому, в теории, такое же количество локальных адресов может быть отображено на один внешний адрес. Однако NAT обладает рядом недостатков.
Поскольку все пользовательские сессии выходят в интернет с одного белого адреса, это будет вызывать проблемы с сайтами, разрешающими доступ к сервису по IP — возможность поработать с ним получит только один пользователь. Более того, если множество человек обратится к сайту с одного адреса, ресурс может решить, что на него осуществляется DDoS-атака, и закрыть доступ всем клиентам.
Что ждет NAT в будущем
А в будущем нас ждет следующий уровень развития NAT — Carrier Grade NAT (CGN/CGNAT). Решение рассчитано на интернет-провайдеров и операторов связи, но также подходит для замены NAT-устройств в корпоративных сетях. CGN позволяет назначать локальные адреса абонентам, централизовано преобразуя их во внешние.
У решения CG-NAT есть несколько достоинств. Оно обеспечивает прозрачный способ использования NAT, благодаря функциям Endpoint Independent Mapping (EIM), позволяющей для каждого сочетания частного IP-адреса и порта клиента гарантировать то же сочетание публичных IP-адресов, Endpoint Independent Filtering (EIF), отбрасывающей пакеты, не предназначенные для внутренних адресов, и Hairpinning, обеспечивающей доступ одной машины к другой внутри сети по внешнему адресу.
Еще одним важным преимуществом CGN является ограничение количества портов TCP и UDP, доступных абоненту. Это дает возможность эффективного распределения портов между пользователями, а также защищает от DDoS-атак с ботнетов.
Переход на IPv6
Многие операторы начинают постепенно переходить на IPv6, поскольку рано или поздно всем придётся его использовать. Смягчить переход от IPv4 к IPv6 способна технология Carrier-Grade NAT. Для этого применяются следующие решения: NAT64, DS-Lite, 6RD и NAT444.
Технология NAT64 позволяет пользователям услуг на IPv6 предоставлять доступ к ресурсам с адресами IPv4, транслируя адреса нового протокола в адреса старого.
Технология DS-Lite DS Lite использует IPv6-соединение между провайдером и клиентом. Пакет IPv4 от клиента, направляющийся во внешнюю сеть, инкапсулируется в IPv6 для передачи с помощью сети провайдера, а затем преобразуется обратно в IPv4 при переходе в публичный интернет. В этом случае оператор может развернуть у себя сеть IPv6, но продолжать предоставлять услуги подключения для клиентов по IPv4.
Технология 6RD реализует предоставление услуги IPv6 клиентам через существующую сеть IPv4. IPv6-адреса выделяются из подсети, которая закреплена за провайдером интернет-услуг. 6RD-узел, желающий отправить IPv6-пакет по сети, инкапсулирует его в пакет IPv4 и проводит проверку того, находится ли получатель в том же сегменте.
Если это так, то IP-адрес получателя формируется путем дополнения префикса IPv4 битами из IPv6 адресата, не входящими в 6RD-префикс. Если же получатель находится в другом сегменте, то пакет оправляется на шлюз провайдера, который извлекает пакет и затем уже передает его дальше по IPv6-сетям. Механизм описан в RFC 5969.
Технология NAT444 позволяет транслировать локальный адрес клиента в локальный адрес провайдера, который затем переводится в публичный адрес интернета. При этом не придётся изменять клиентское оборудование или сетевую структуру.
Для реализации любой из этих технологий необходимо либо использовать специальное оборудование для преобразования адресов или туннелирования (A10 Thunder, F5 BIG-IP Carrier-Grade NAT), либо модернизировать имеющиеся сетевые устройства дополнительными сервис-модулями.
Реализовать все это позволяет многофункциональное устройство, например DPI (Deep Packet Inspection) и Carrier-Grade NAT. Такие решения априори рассчитаны на работу с огромными нагрузками при анализе трафика, поэтому легко справятся с трансляцией адресов (функция NAT).
SavePearlHarbor
Ещё одна копия хабора
Carrier Grade NAT
Как известно, адресное пространство IPv4 практически исчерпано, а переход на IPv6 затянулся на долгие годы и особого прогресса в нём до сих пор нет. В то же время, Интернет развивается, провайдеры строят сети и всё более острой становится проблема дефицита IP. Частично «уплотнить» IP пулы позволяет использование BRAS и динамическая адресация, но, в конечном счёте, дело идёт к массовому NAT.
Вступление
NAT (Network Address Translation) — в общем случае технология изменения source или destination IP адреса в пакете на какой-то другой. Чаще всего (в том числе в этой статье) речь идёт о частном случае — napt44, он же inside source NAT with overload, он же PAT (Port Address Translation). Суть этой технологии в том, что меняется не только source IP, но и source port в L4 заголовке, и в специальную таблицу заносится соответствие inside IP/inside port — outside IP/outside port, и эта же таблица используется для трансляции обратного трафика. Всё это позволяет нескольким хостам выходить в Интернет, используя один и тот же реальный IP адрес. Хостам же назначаются т.н. «серые» адреса, которые маршрутизируются только в пределах локальной сети и не являются уникальными в Интернете. У технологии множество минусов, и, по мнению многих, она является костылём, но пока что это практически единственный способ давать пользователям доступ в Интернет в условиях нехватки IP адресов (nat64 с dns-alg ещё намного ужаснее и костыльнее).
RFC 6598 определяет специальный диапазон серых IP для CGN — 100.64.0.0/10. Несмотря на это, многие используют привычные всем серые IP из RFC1918. Когда речь идёт о небольшой сети и трафике до нескольких гигабит, со всем вышенаписанным справится обычный сервер с Linux/FreeBSD или софтовый роутер. Но при более высоких нагрузках появляется необходимость использовать специальное железо. Последние несколько лет вендоры активно работают над этим, мне известно о решениях у Cisco, Juniper, Huawei с заявленной производительностью от 20 до 80 Gbps на слот. Общие принципы у всех одинаковы, но в примерах я буду приводить Juniper, так как имею опыт внедрения CGN решения на оборудовании этого вендора. Кроме того, мне известно о решении на оборудовании Huawei у одного из операторов. О внедрённых решениях CGN от Cisco (на базе ASR 9000) я не слышал (что неудивительно при их ценах), но наверняка где-то в мире есть.
Расчёт пулов и аллокация портов
Первая и очевидно возникающая задача — расчёт количества L4 портов и белых IP для нат пула. Примем 64к портов на IP адрес (well-known ports для NAT не используются). У NAT карты, в свою очередь, есть своё ограничение по количеству сессий. К примеру, у MS-DPC это 4 миллиона сессий (в каждую сторону) на каждый из двух PIC’ов (Physical Interface Card). Поделив 4000000 на 64000, получим 62.5, что соответствует /26 сети (64 адреса). Однако, аллокация портов по одному приведёт к деградации производительности сервисной карты, поэтому мы будем использовать PBA (Port Block Allocation). Эта фича позволяет выделять для абонента блок портов при установке первого соединения, и дальше использовать порты из этого блока. Обратной стороной такой конфигурации будет неполный расход L4 портов, так что придётся использовать больший пул белых IP для достижения полной утилизации карты.
Подсеть /24 позволит использовать почти 16к портов на каждый белый IP, пользователю выделяются блоки по 1к портов (максимум 4 блока) с таймаутом в 5 минут. Juniper рекомендует создавать блоки из расчёта в 2 или 4 раза больше, чем реально использует абонент.
Кроме того, стоит упомянуть две важные опции:
Так выглядит правило трансляций:
Кроме метода аллокации портов, в целях безопасности стоит ещё установить ограничение по количеству одновременных соединений для пользователя. Обычный пользователь очень редко будет использовать больше, чем 200-300 одновременных сессий, но некоторые приложения (в основном торрент) могут быстро забить этот лимит. К счастью, MS-DPC умеет быть IDS’ом (вообще, lookup block в любой линейной карте построенной на Trio архитектуре, умеет аппаратно разбирать до 256 байт в пакете, но сейчас нам это не надо). Так что можно поставить отдельный лимит на количество UDP сессий по портам выше, чем well known, и отдельный лимит для всего остального трафика.
Как показывает практика, такого лимита хватает с запасом. UDP с номерами портов выше 1024, как правило, использует или торрент или онлайн игры, вряд-ли пользователь будет включать и то и другое одновременно; важно же то, что включенный торрент не помешает другим приложениям большим количеством одновременно открытых соединений. Конечно, решение может показаться слегка «костыльным», но это соответствует парадигме NAT. У меня был единственный инцидент, когда по ошибке или незнанию выдали серый IP какой-то фирме, судя по всему, с немалым количеством пользователей (которые сидят за их внутренним натом), им не хватило и 4к сессий. Разумеется, таким надо давать белый IP.
К вопросу безопасности стоит упомянуть ещё важную вещь: кровавый режим некоторых стран требует от провайдера раскрытия личности абонента по IP. NAT тут добавляет проблем, т.к. за белым IP сидит несколько абонентов. Решается это логированием каждого установленного соединения (нагружает сервисную карту) или использованием deterministic PBA. Конфигурируется почти так же, как и secured PBA, но отличается алгоритм аллокации портов, таким образом по сочетанию [белый IP]:[source port] можно однозначно определить серый IP, который был транслирован. Подробнее по ссылке.
Изменение способа аллокации портов на MS-DPC требует перезагрузки платы или PIC, но у нас же Carrier Grade, так что должен сразу срабатывать резерв, о чём ниже.
Настройка трансляции
Указанные выше правила теперь нужно прицепить к service-set. Их в Junos есть 2 типа: interface style и next-hop style. Первый проще:
И указанной конфигурации достаточно, чтоб NAT наконец заработал. Но возникнут проблемы с резервированием и балансировкой трафика, так что лучше использовать next-hop style service-set.
Схема прохождения трафика через роутер при использовании next-hop style service-set. Здесь используется пример inline NAT на обычной линейной карте с Trio чипсетом, но в PAT на MS-DPC принцип тот же.
Теперь нам осталось направить трафик, подлежащий NAT, на сервисный интерфейс sp-10/1/0 unit 10, а обратный трафик будет приходить на unit 20. Делается это при помощи FBF (Firewall Based Forwarding), аналог PBR в Cisco.
Соответственно, создаётся routing instance. В Junos их есть несколько типов, включая VRF, для данной задачи проще всего использовать тип инстанса forwarding. Это просто дополнительная таблица маршрутизации, в которую можно импортить маршруты при помощи rib-groups. Rib-groups — очень мощный инструмент в Junos с довольно широким применением, на хабре была про него статья.
В данном примере используются 2 MS-DPC в 8-м и 10-м слотах маршрутизатора, каждая из карт имеет 2 PIC, каждому из которых соответствует сервисный интерфейс. При этом создаётся таблица маршрутизации Nat.inet.0, в которую надо импортировать directly connected маршруты:
Подробнее про rib-groups можно почитать в приведённой выше статье.
Трафик балансируется между сервисными интерфейсами и в случае падения одной из карт переходит на исправную. Для балансировки применяются общие в Junos настройки L2 и L3 лоад балансинга.
Опция hash-key работает только для DPC карт. Для новой NAT карты MS-MPC, а также обычных линейных карт (которые на Trio чипсете) используется опция enhanced-hash-key. Есть ещё нюанс, который не описан в мануалах, но я обнаружил при тестировании: при использовании в хэш-кее L3 и L4 заголовков, производительность MS-DPC для NAT вырастает примерно на 20-25%, по сравнению с использованием только L3, что довольно существенно. Инженер Juniper подтвердил это и порекомендовал использовать L3+L4, но я не знаю, проводил ли он какие-то дополнительные тесты. Впрочем, всё это уже не очень актуально, т.к. для новых инсталляций используется более производительная MS-MPC.
На этом конфигурацию CGN можно считать законченной. Можно жёстко привязывать серые подсети к определённому белому IP, чтоб не ругались системы безопасности некоторых интернет ресурсов, но, как показала практика, большой необходимости в этом нет. Делать обратный (destination) NAT, как и статический NAT 1 в 1 для некоторых абонентов — тоже плохая идея, т.к. это создаёт лишнюю нагрузку на NAT карту, а белые IP не экономит. Проще выдавать таким клиентам белые IP. Задачу по разделению трафика по входящему интерфейсу (актуально для многих украинских провайдеров по историческим причинам) я решил методом домосетей с линуксовыми роутерами: маркировка dscp на входе и фильтр на сервисном интерфейсе. Если кто-то заинтересуется, расскажу подробнее, но всё довольно очевидно. Интересно, что архитектура MX позволяет на одном и том же роутере промаркировать пакет и на основе этой же маркировки принимать решение.
Всем коллегам желаю успешного внедрения CGN, но не стоит забывать, что это только временное решение перед переходом на IPv6. Не превращайте его в решение постоянное. Не надо так.
