Сейчас на слуху переход на 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:

<MT-config>
 …

/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 в своей работе и тоже нашли подводные камни или полезные решения, пишите в комментариях.