Как в РНКБ IPv6 внедряли
Сейчас на слуху переход на IPv6 и связанные с ним проблемы. Мы в РНКБ недавно испытали это на себе — внедряли IPv6 для мобильных приложений. Задача оказалась нетривиальная, поэтому мы решили рассказать и другим хабравчанам, почему у нас не всё пошло гладко и с чем мы столкнулись. В других банках РФ, в т. ч. из топ-10, по нашим сведениям, IPv6 пока не поддерживается.
А зачем нам IPv6?
Клиенты финтеха всё больше пользуются услугами онлайн, поэтому банки внимательно следят за доступностью и удобством своих мобильных приложений, финансируют собственные разработки и стараются всячески клиентский опыт улучшать. Мы в РНКБ тоже к своему интернет-хозяйству относились всегда крайне серьёзно, в том числе к интернет-связности: у нас есть собственные AS (автономная система) и блоки IP-адресов, которые позволяют гибко управлять распространением в Интернете маршрутов к ресурсам Банка. Поэтому, когда мы стали получать обратную связь от клиентов наподобие «ваше приложение не работает, хотя интернет есть — Гугл же открывается», то стали разбираться в причинах.
По опыту мы знаем, что виновниками проблем нередко оказываются сами сети операторов в сети Интернет. Но в нашем случае не все сбои можно было списать на них, и мы заподозрили, что дело может быть в некорректной работе мобильного интернета. Например, мы не раз замечали, что сотовые провайдеры иногда «выдавали» мобильным устройствам адреса IPv6, не назначив адреса IPv4.
Задача напрашивалась сама собой: пора было внедрять IPv6-связность для наших мобильных приложений, чтобы услуги банка оставались доступными для клиентов.
Не все провайдеры умеют готовить IPv6
Вообще-то нашей автономной системе уже давно был присвоен блок адресов IPv6, просто руки не доходили его использовать. Так что, когда мы решили, что внедрить IPv6 всё-таки нужно, то в первую очередь пришлось заняться IPv6-связностью на аплинках нашей AS. Это оказалось не так просто: мы не сразу смогли добиться от вышестоящих провайдеров работоспособности IPv6, а некоторые из них и вовсе не сумели это сделать. Нам даже стало казаться, что в крупных провайдерах все толковые инженеры и грамотные менеджеры заняты в межоператорских подразделениях, тогда как на долю клиентов — юридических лиц остаются специалисты, которые хоть как-то разбираются только в DHCP и статическом присвоении IPv4. По крайней мере, когда мы попытались выяснить, могут ли нам предоставить IPv6-связности по BGP, нас попросту не понимали. До того дошло, что с одним провайдером мы переписывались по этому вопросу больше года!
Но хоть процесс и занял немало времени, и не все провайдеры смогли поучаствовать, мы в конце концов сумели получить IPv6-связность на многих наших аплинках. Дальше уже дело было за нами.
Выбираем оптимальное решение
Итак, у нас было мобильное приложение, которое работало по IPv4, а FQDN ресурсов описывались A-записями на DNS-серверах. «Белые» IPv4-адреса транслировались (NAT/PAT) на сетевом оборудовании периметра нашей сети в «серые» (RFC1918) адреса прокси-серверов Nginx. У этих прокси-серверов несколько сетевых интерфейсов, и они выполняли первичную обработку https-запросов и балансировку по серверам приложений. Предстояло как-то внедрить в эту схему IPv6.
Схема «как было»
Первое, что пришло нам на ум, — это добавить в DNS AAAA-запись и трансляцию адресов 6-to-4 NAT на сетевом оборудовании. Но, обдумав этот вариант, мы всё же признали его неудачным. Тому было немало причин, самой важной из которых была невозможность вести учёт IPv6-адресов клиентов на Nginx. Такой учёт реализован в РНКБ в уже существующих решениях и нужен в некоторых случаях. В частности, при противодействии DDoS-атакам.
Затем мы задумались над вариантом сделать специальный Nginx c IPv6-интерфейсом в сторону Интернета и традиционным IPv4-интерфейсами в сторону серверов приложений. Но и у этой версии был существенный недостаток: «выставлять» сервер «белым» IPv6-адресом в Интернет — довольно опасно. Так что мы «спрятали» его за NAT, в нашем случае — destination nat 6-to-6. Да, мы знаем, что это решение многим покажется спорным: всё-таки лучшие практики по безопасности, да и не только они не рекомендуют использовать NAT подобным образом. Но такая практика у нас распространена и хорошо себя зарекомендовала.
Окончательное решение выглядело так: AAAA-записи, 6-to-6 NAT и прокси-сервера с двойной связностью, IPv6 и IPv4.
Схема «как стало»
Тестирование и «подводные камни» смартфонов
Чтобы протестировать получившееся решение, нам пришлось развернуть Wi-Fi-сеть для мобильных устройств, сеть доступа с IPv6-связностью, но без IPv4. Для достижения цели мы применили маршрутизатор MikroTik, изначально с аплинком на сотовом модеме. На кэширующем DNS в маршрутизаторе настроили нужные AAAA-записи и приступили к тестам.
Первые результаты удручали: приложение не стало работать стабильнее, зато в наличии были всевозможные глюки: при подключении смартфонов, пингах, при DNS-запросах и т. д. Тогда мы попытались улучшить ситуацию и организовали наземный аплинк стенда с IPv6-связностью. Но и это не помогло: на наземном канале тоже случались разные глюки. В чём же дело? Стали выяснять — и нашли причину. Виновны оказались… сами смартфоны.
Изначально настройки и первые проверки мы выполняли с ноутбука, и только позже в дело вступали разные смартфоны. В деталях процесс был такой: мы настраивали роутер, затем подключались к его SSID тем же ноутбуком и проверяли доступность фронтенда curl-ом либо браузером. Затем к этому SSID подключали смартфоны с установленным банковским приложением и уже полностью проверяли работоспособность. Если приложение не работало, то проверяли пинги и корректность разрешения имён DNS. При необходимости снимали дампы средствами MikroTik или на аплинке стенда.
IPv6 предполагает 2 различных механизма автоконфигурации клиента: DHCPv6 и ND (Neighbor Discovery). Кроме этого, есть ещё ряд неочевидных настроек (подробнее можно ознакомиться здесь: https://wiki.mikrotik.com/wiki/Manual: IPv6). Так вот: разные модели смартфонов по-разному определяют работоспособность Интернета через Wi-Fi: кому-то из них достаточно только IPv6 Neighbor Discovery, кто-то предпочитает DHCPv6, а некоторые вообще не хотят считать Wi-Fi-сеть рабочей без стандартного DHCP (v4).
Нам пришлось ещё раз доработать своё решение, чтобы устранить и эту проблему. Итоговая конфигурация включала в себя ND и раздачу IPv4-адресов в Wi-Fi по DHCP, но без IPv4-адреса на uplink-интерфейсе маршрутизатора. Работоспособной оказалась примерно такая конфигурация MikroTik в части IPv6:
…
/ipv6 pool
add name=poolipv6 prefix=xxxx: xxxx: xxxx: xxxx::/xx prefix-length=xx
…
/ip dns static
add address=xxxx: xxxx:0: xxxx: xx name=service.rncb.ru type=AAAA
…
/ipv6 route
add disabled=no distance=1 dst-address=::/0 gateway=xxxx: xxxx: xxxx: xxxx: x \
routing-table=main scope=30 target-scope=10
…
/ipv6 address
add address=xxxx: xxxx: xxxx: xxxx: x/xx advertise=no interface=XXXX
add address=::1 from-pool=poolipv6 interface=XXXX
…
/ipv6 nd
set [ find default=yes ] disabled=yes
add dns=xxxx: xxxx: xxxx: xxxx::1, xxxx: xxxx: xxxx: xxxx::1 interface=XXXX\
ra-interval=20s-1m ra-lifetime=13m20s
…
Тестирование с этой версией конфигурации на стенде показало, что мобильное приложение подключается и работает стабильно уже со всех смартфонов и планшетов — по крайней мере тех, которые оказались в нашем распоряжении.
Дальнейшее тестирование обошлось уже без каких-либо стоящих упоминания деталей. Выявили ещё несколько ошибок в настройках и логике приложений применительно к IPv6-клиентам и исправили их.
Ну и результат наших экспериментов уже на практике: после проделанной работы клиенты перестали жаловаться на проблемы с приложением при работающем мобильном Интернете и связи только по IPv6. Успех.
Итоги
Стоила ли задача потраченных усилий? Смотря с какой стороны посмотреть. Например, клиенты довольны, и это важно! Но, когда после запуска в продакшн мы изучили долю трафика IPv6 в общем объёме запросов к сервису, оказалось, что она невелика, — около 10%. Вероятно, потому, что протокол IPv6 пока ещё мало распространён на сетях мобильных операторов и Wi-Fi.
Тем не менее работа над внедрением IPv6 стала для нас положительным опытом. Она позволила нам лучше понять новую технологию и освоиться с соответствующими настройками оборудования. Возможно, что этот опыт поможет и вам лучше подготовиться к встрече с IPv6 в будущем.
А если вы, как и мы, уже столкнулись с IPv6 в своей работе и тоже нашли подводные камни или полезные решения, пишите в комментариях.
