Сейчас на слуху переход на 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 в своей работе и тоже нашли подводные камни или полезные решения, пишите в комментариях.
Комментарии (36)
vanxant
04.04.2023 16:48+1А подскажите ради интереса примерный % соединений по ipv6?
MedicusAmicus
04.04.2023 16:48+1И подскажите провайдера, который выдает IPv6 only адреса. Или хотя бы просто поддерживает IPv6.
Отдельное спасибо, если регион укажете.
vabka
04.04.2023 16:48С поддержкой ipv6 есть, например, Планета (для физлиц) aka Miralogic (для юрлиц). Чтобы появился ipv6 нужно в кабинете галку нажать.
Свердловская область.
MedicusAmicus
04.04.2023 16:48Немного проясню свой вопрос.
Интересно предоставление IPv6 мобильными операторами в контексте географической привязки к основному региону обслуживания банка.
OlegY1611
04.04.2023 16:48+1По-умолчанию, ipv6 предоставляет только МТС, в т.ч. и в роуминге на полуострове.
Sadok
04.04.2023 16:48СПб, бывший Interzet. Сразу выдает /64. Правда только на pppoe почему-то. А вот какой-нить TimeWeb (хостер) выдает только в РФ и Польше. В Голландии уже ой.
FSA
04.04.2023 16:48Ростелеком. Но, говорят не во всех областях. Я проверял только в Свердловской и Новосибирской. Могут быть проблемы с входящими соединениями (торренты не будут работать, Wireguard и всё, что использует UDP), но тоже, говорят у кого-то всё нормально работает. У Дом.ру было, но ходит слухи, что они там что-то переделывают и у кого-то пропал IPv6.
Из сотовых - МТС и Мегафон.
А вообще, есть такой список провайдеров: https://version6.ru/isp
slonopotamus
04.04.2023 16:48И Мегафон
Сижу на Мегафоне, Москва и область. Никакого IPv6 не ощущаю. Вы уверены что он есть?
OlegY1611
04.04.2023 16:48На Мегафоне ipv6 включается по запросу (см. Использование IPv6 в мобильных сетях России - 4PDA )
slonopotamus
04.04.2023 16:48По вашей ссылке в разделе "Как подключить" отправляют на сайт Мегафона на страницу услуги "Открытый IPv6". Так вот, там 404. И в кабинете такой услуги тоже нет.
MaxSoniX
04.04.2023 16:48Ощущение IPv6 от МегаФон
Дело не в запросах (если вы про услугу "открытый IPv6", может быть такое что услугу включите, а IPv6 всё равно не появится).
1) Запустили с ноября по регионам, но не во всех (к примеру есть в СФО).
2) Работает не на всех смартфонах (есть предположение связано модулем LTE и настроек со стороны Мегафона, т.к. с МТС работает)
3) Сам же оператор МегаФон не раскрывает технических подробностей, даже про "Открытый IPv6" люди узнали окольными путями, что это аналог услуги у МТС "IPv6+" - открыть порты 0-1023 по IPv6.
StanleyShilow
04.04.2023 16:48Упячная заваруха, конечно...
Вот только формулировка "учет клиентских адресов... " звучит странно. Здесь повествование хотелось бы уточнить. Первое что приходит на ум, так это связь одного пользователя с одним адресом/ми, что вероятно, задача одного из микросервисов и напрягать NGINX этим делом нужно только на проверку. Вместе с этим, инафа пугающая. NGINX, если мне не изменяет память, должен спокойно работать как с 32-битным адресным пространством, так и с "новой технологией" - 128-битными шестнадцатеричными адресами, которые юзают с 1999 года.
PS. Иногда возникает ощущение (только ощущение, это слово надо подчеркнуть с целью не обижать и самому не обижаться), что дорогие devops'ы и разработчики разъехались по разным лагерям и постепенно разучиваются контачить между собой. Спасибо, за историю) Надеюсь пригодится)
OlegY1611
04.04.2023 16:48+1"учёт клиентских адресов" - в основном, как один из рубежей DDoS защиты. Для уникального адреса настраивается лимит подключений за определённый период времени. В некоторых случаях также применяются black-листы по ip-адресам/префиксам
AleksandrBelov332
04.04.2023 16:48IPv6 является более современной версией протокола интернет-протокола, чем IPv4. В первую очередь, при его разработке стояла задача расширения адресного пространства, которые в текущее время уже исчерпано для протокола IPv4, а такая плотность адресации заметно раздувает таблицы маршрутизации из-за того, что необходимо включать в глобальную таблицу маршрутизации небольшие диапазоны адресов.
OlegY1611
04.04.2023 16:48+1Действительно, BGP Full View бурно растёт, см. BGP Reports (potaroo.net). И если макс. размер IPv4-таблиц теоретически ограничен числом возможных подсетей /24, то макс. размер таблиц IPv6 - больше на порядки. Современные маршрутизаторы могут держать миллионы записей в FIB, скоро потребуются миллиарды :)
FSA
04.04.2023 16:48При разработке IPv6 учитывалось, что таблицы могут расти. Поэтому блоки IPv6 выделяются с достаточно большим запасом, чтобы потом не получилось множество отдельных сегментов и чтобы потом заниматься агрегацией маршрутов, если это возможно. Так что если сейчас таблица маршрутизации для IPv6 и растёт, то в будущем этот рост значительно замедлится. Там, где провайдеру нужны десятки, а то и сотни записей в таблице IPv4 для каждого мелкого блока, в IPv6 достаточно одной записи, которая не только покрывает все эти же потребности, но и имеет значительный запас на будущее. В одной сети /32 IPv6 содержится столько стандартных сетей /64, сколько всего адресов в IPv4. А у нас провайдеры ещё и экономные. Они дают клиентам не /48, а /56. Т.е. из 32 бит они себе забирают 24. Много ли вы видели провайдеров с /8? А IPv6 легко сеть такого размера получить и даже больше. А пользователям даже NAT не нужно использовать, потому что у них достаточно адресов.
OlegY1611
04.04.2023 16:48Совершенно верно, IPv6-адреса выдаются провайдерам крупными блоками, чтоб исключить запросы дополнительной адресной ёмкости. Однако, кроме огромного числа даже таких крупных блоков, на рост таблиц будет влиять ещё фрагментация этих блоков самими провайдерами. Часто провайдеры анонсируют more specific -префиксы, чтоб гибко управлять нагрузкой на межоператорских стыках.
MaxSoniX
04.04.2023 16:48+2Заинтересовало:
1) FQDN банка сайта не имеет AAAA записи
2) Какой мобильный оператор выдаёт адреса v6only?
По статье интересный опыт внедрения v6 банком, при условии что действительно будет похоже первым на территории РФ.OlegY1611
04.04.2023 16:481) AAAA -записи появляются в DNS по мере запуска соответствующих ресурсов на IPv6-адресах. Для ресурсов на адресах IPv4 соответствующие A-записи естественно есть.
2) Таких нам неизвестно, все кто предоставляют IPv6-связность, также дают и IPv4.
Спасибо, мы старались :)MaxSoniX
04.04.2023 16:481) Жаль что основной сайт банка не является соответствующим ресурсом :)
2)Например, мы не раз замечали, что сотовые провайдеры иногда «выдавали»
мобильным устройствам адреса IPv6, не назначив адреса IPv4.Тогда хотелось бы раскрыть более подробный пример такого случая.
OlegY1611
04.04.2023 16:481) Со временем, возможно, и веб-сайт Банка станет доступен по IPv6. Пока такого решения не принято, целесообразность доработки неочевидна.
2) Это были эпизодические непродолжительные случаи, связанные с некорректной работой смартфона или сети. Выглядело так, что смартфон при wifi-sharing-е не выдавал DHCPv4, только IPv6
aim
04.04.2023 16:48"«выставлять» сервер «белым» IPv6-адресом в Интернет – довольно опасно." — после этой фразы читать дальше не хочется. :(
OlegY1611
04.04.2023 16:48К сожалению, ресурсы Банка привлекают повышенное внимание злонамеренных пользователей. Убрать сервер за NAT - вполне рабочее решение.
aim
04.04.2023 16:48то есть просто Firewall настроить недостаточно? в чём повышение "безопасности" конкретного сервера, в случае если
а) имеется Firewall (как бы вроде бы требование регулятора, ЕМНИП)
б) открыты публично только "клиентский порты" (443 и что там ещё нужно для работы клиентов)
в) остальные порты (например управление ssh и что там ещё надо) — также на firewall отруливается и доступ разрешён только с доверенных адресов (ну там офиса, или с конечной точки vpn или ещё каким-то образом как вам нужно, ну в общем не публично)так чем NAT лучше? что он добавляет в эту схему (которая ДОЛЖНА быть уже)?
OlegY1611
04.04.2023 16:48Да, корректная настройка Firewall обеспечивает вполне достаточный уровень защиты. Однако, NAT не хуже. Кроме того, у нас были ещё некоторые причины применения NAT, но подробности выходят далеко за тематику статьи.
rzerda
Чем опасно?
Upd. Даже так: кого вам не удалось уговорить, сетевиков или безопасников?
OlegY1611
Опасность, в основном, в уязвимостях, в т.ч. 0day. Уговаривать было некому, сетевики и безопасники оказались заодно. Сделали по образу и подобию существующих IPv4-решений.
v0rdych
Так вы NAT66 делаете только для 443 порта?
А чем это отличается от FW, фильтрующего все, кроме 443 порта на хосте?
OlegY1611
На самом хосте, в общем случае, открыты ещё какие-то порты и протоколы. Да и сам FW (напр., netfilter) может быть подвержен каким-то уязвимостям. Рекомендации вроде NIST SP 800-215, наряду с прочими мерами, предлагают фильтровать трафик на 1st hop router-е либо на оборудовании доступа.