Все что нужно знать про IPv4, IPv6, Dual Stack, DNS64 и NAT64

В одном из своих последних проектов, связанных с голосовой и видеосвязью, я наткнулся на хитрую проблему. Долгое время я о ней не подозревал и всё удивлялся почему некоторые юзеры отваливаются через 10–12 секунд, так и не начав общаться? Особенно это проявлялось на зарубежном мобильном трафике. Думаю, у нас в СНГ таких сложностей пока возникать не должно, но во всем мире уже идет тренд на IPv6 и постепенный отказ от IPv4.

Я постарался написать эту статью максимально простым языком, чтобы она легко читалась даже новичками. При этом мне пришлось довольно глубоко копнуть в устройство современных сетей тема важна для всех, кто строит платформы аудио и видеокоммуникаций для пользователей из разных точек мира.

Итак поехали!

Когда начинаешь разбираться с настройкой серверов и сетей, постоянно натыкаешься на термины IPv4, IPv6, NAT, CGNAT, Dual Stack, DNS64, NAT64 и 464XLAT. Если с ipv4, ipv6 мы еще знакомы то с остальными терминами ничего непонятно. Часто их объясняют так, что без диплома сетевого инженера ничего не понятно. Разберем по порядку и с самого нуля, как устроены адреса в интернете, почему старых адресов перестало хватать, как работают программы переводчики у провайдеров и где именно твой код на бэкенде может упасть с ошибкой.

Почему закончились старые адреса IPv4

Чтобы компьютеры, телефоны и серверы могли находить друг друга в интернете и обмениваться данными, у каждого устройства должен быть свой цифровой номер, то есть IP адрес.

В 1981 году для интернета приняли протокол четвертой версии, который назвали IPv4. В этом протоколе под адрес каждого устройства выделили 32 бита памяти. Такое ограничение позволяет создать ровно 4 294 967 296 уникальных адресов (чуть больше четырех миллиардов). В восьмидесятые годы компьютеры были только в университетах и военных лабораториях, поэтому казалось, что четырех миллиардов номеров хватит навсегда.

Но сегодня на планете живет восемь миллиардов человек. Почти у каждого есть смартфон, дома стоят роутер, ноутбук и телевизор, а в дата центрах работают сотни миллионов серверов. В результате свободные адреса IPv4 в мире физически закончились еще в 2011 году.

Что такое белые и серые адреса и как работает NAT

Когда свободные адреса начали заканчиваться, интернет провайдеры не смогли выдавать каждому домашнему компьютеру и телефону отдельный уникальный адрес, который виден во всем интернете. Чтобы решить эту проблему, адреса разделили на два типа, которые разработчики называют белыми (публичными) и серыми (внутренними).

Представь большой офисный бизнес центр. У самого здания есть официальный городской адрес, например улица Ленина, дом 5. Любой курьер в городе может найти это здание по карте и привезти туда посылку. В компьютерных сетях такой настоящий уникальный адрес в интернете называется белым (или публичным) IP адресом.

Внутри этого бизнес центра находится тысяча комнат с номерами от 101 до 1100. Если ты закажешь доставку еды и напишешь в адресе только «кабинет 105» без указания улицы и дома, курьер к тебе не приедет, потому что кабинет 105 есть в каждом втором здании города. В сетях такие внутренние номера комнат называются серыми (или локальными) IP адресами. Они бесплатные, их можно раздавать сколько угодно, но они работают только внутри одного здания (внутри одной локальной сети), а в большом интернете о них никто не знает.

Как тогда людям из этих кабинетов заказывать товары из интернета, если у них есть только внутренние серые номера?

Для этого на входе в здание сажают вахтера с блокнотом. В сетях программа, которая выполняет работу такого вахтера на роутере, называется NAT (переводчик сетевых адресов). Работает это так.

1. Сотрудник из кабинета 105 хочет открыть сайт Google и отправляет запрос.

2. Вахтер на входе (роутер с программой NAT) берет этот запрос, стирает с конверта обратный адрес «кабинет 105» и пишет вместо него городской адрес всего здания «улица Ленина, дом 5».

3. Одновременно вахтер записывает себе в блокнот пометку о том, что запрос номер один к сайту Google отправил человек из кабинета 105.

4. Сервер Google получает запрос, видит городской адрес здания и отправляет ответ обратно на «улицу Ленина, дом 5».

5. Вахтер на входе ловит ответ от Google, смотрит в свой блокнот, видит, что этот ответ ждет кабинет 105, и передает данные внутрь нужной комнаты.

Точно такой же маленький вахтер NAT работает прямо сейчас в твоем домашнем роутере, чтобы твой телефон, ноутбук и телевизор могли выходить в интернет через один кабель.

А когда адреса закончились у самих интернет провайдеров, они поставили одного гигантского вахтера на уровне всего района или города. Такой большой провайдерский переводчик называется CGNAT. Провайдер берет всего один настоящий белый адрес IPv4 и подключает к нему сразу от одной тысячи до пяти тысяч разных квартир. Все эти тысячи людей сидят с внутренними серыми адресами и выходят в интернет через один общий внешний адрес провайдера.

Три проблемы, которые создает провайдерский CGNAT

Жизнь тысяч разных пользователей за одним общим адресом провайдера решила проблему нехватки номеров, но создала три серьезные проблемы для пользователей и веб разработчиков.

1. Блокировки из за соседей по провайдеру. Поскольку тысяча разных квартир выходит в интернет под одним и тем же белым адресом IPv4, для внешних сайтов все эти люди выглядят как один человек. Если один из этой тысячи абонентов запустит скрипт для агрессивного парсинга сайта, начнет рассылать спам или подхватит вирус, система защиты Cloudflare или Google заблокирует этот внешний IP адрес. В результате остальные 999 обычных людей, которые сидят на том же провайдере, при попытке открыть сайт получают отказ в доступе или бесконечно разгадывают капчу.

2. Невозможность соединить два устройства напрямую (для видеозвонков и игр). Когда ты просто открываешь сайт, твой компьютер сам пишет серверу первым, поэтому вахтер NAT делает запись в блокноте и знает, куда вернуть ответ. Но есть задачи, где два клиентских компьютера должны соединиться друг с другом напрямую без центрального сервера посередине. Первый пример это видеозвонки в браузере, которые работают на технологии WebRTC. Когда два человека созваниваются по видеосвязи на сайте, пропускать тяжелый видеопоток через сервер владельца сайта слишком дорого. Поэтому браузеры используют встроенный инструмент WebRTC, чтобы передавать звук и видео напрямую с телефона одного собеседника на телефон другого. Второй пример это кооперативные сетевые игры. Во многих играх разработчики не арендуют свои серверы для матчей. Вместо этого компьютер одного из игроков становится главным для текущей игровой комнаты, а компьютеры остальных игроков пытаются подключиться напрямую к его компьютеру. А теперь посмотри, что происходит, когда оба человека сидят за провайдерским CGNAT. Компьютер первого человека пытается постучаться к компьютеру второго и отправляет пакет на общий внешний адрес его провайдера. Пакет прилетает к провайдерскому вахтеру CGNAT. Вахтер открывает свой блокнот и видит, что изнутри здания никто эту посылку не заказывал. За спиной у вахтера пять тысяч разных квартир, и он понятия не имеет, кому именно из пяти тысяч абонентов предназначен этот входящий звонок, поэтому просто удаляет пакет. Прямое соединение срывается. Чтобы видеозвонок или игра все таки заработали, разработчику приходится арендовать за свои деньги промежуточный сервер посредник (в WebRTC он называется TURN сервер), к которому оба клиента подключаются сами, и перегонять весь трафик через него.

1. Платные адреса на хостингах. Поскольку свободных адресов IPv4 больше нет, хостинг провайдеры перекупают их друг у друга по цене от 35 до 50 долларов за один адрес. Поэтому сегодня при аренде сервера в облаке хостеры берут с разработчиков отдельную ежемесячную плату просто за то, что к серверу привязан один белый адрес IPv4.

Зачем создали IPv6 и почему на него еще не все перешли

Протокол шестой версии (IPv6) разработали для того, чтобы полностью отказаться от провайдерских переводчиков CGNAT и снова выдать каждому смартфону, роутеру и серверу в мире собственный белый адрес.

Вместо 32 бит под адрес в IPv6 выделили 128 бит. Это дало ровно 340 282 366 920 938 463 463 374 607 431 768 211 456 уникальных адресов. При таком запасе экономить номера больше не нужно, поэтому на хостингах адреса IPv6 выдают бесплатно целыми огромными блоками.

Почему тогда весь мир до сих пор не отключил старый IPv4?

Главная причина состоит в том, что создатели IPv6 сделали его полностью несовместимым со старым протоколом IPv4. Это как два человека, один из которых говорит только на русском языке, а другой только на китайском. Без переводчика они не поймут ни слова. Точно так же компьютер, у которого настроен только старый протокол IPv4, физически не может отправить данные на сервер, у которого есть только новый адрес IPv6, и наоборот.

Из за этой несовместимости возникла задержка с переходом. Если ты прямо сейчас отключишь на своем сайте старый IPv4 и оставишь только IPv6, к тебе не сможет зайти ни один пользователь, чей домашний интернет провайдер работает по старому протоколу.

А многие домашние интернет провайдеры (особенно в СНГ и Центральной Азии) не спешат включать у себя IPv6 по простой финансовой причине. Сеть провайдера состоит из дорогих промышленных роутеров, которые перекачивают трафик между районами и городами. На старом оборудовании поддержка IPv6 часто работает плохо или требует платного обновления и перенастройки всей сети компании. Провайдеру невыгодно тратить на это деньги, потому что он уже бесплатно спрятал тысячи абонентов за одним адресом через CGNAT, а все популярные сайты и так открываются по старому IPv4.

Перешли на новый протокол в первую очередь те компании, у которых старая схема перестала выдерживать нагрузку. Это крупные облачные хостинги и большие мобильные операторы (например в Германии, Франции, США и Индии), у которых десятки миллионов смартфонов просто переполняли память переводчиков CGNAT. Поэтому сегодня более половины мирового мобильного трафика уже идет по IPv6, тогда как домашний проводной интернет во многих странах продолжает работать по IPv4.

Что такое Dual Stack

Поскольку половина интернета сидит на старом протоколе, а половина мобильных сетей уже перешла на новый, владельцам сайтов и серверов пришлось поддерживать оба протокола одновременно. Такой режим работы назвали Dual Stack (двойной стек).

Никакого перевода одного протокола в другой внутри Dual Stack нет. Если продолжать аналогию с языками, то сервер с Dual Stack это человек, который одинаково хорошо знает и русский, и китайский язык.

Когда ты настраиваешь Dual Stack на своем сервере, это выглядит так.

1. На сетевой карте твоего сервера прописаны сразу два белых адреса (один старый IPv4 и один новый IPv6).

2. В телефонной книге интернета (в системе DNS, которая переводит понятное имя домена вроде example.com в цифровой IP адрес) ты создаешь для своего домена две записи. Запись типа A хранит твой старый адрес IPv4, а запись типа AAAA хранит твой новый адрес IPv6.

3. Твой веб сервер (например Nginx или программа на Go) слушает входящие подключения по обоим адресам сразу. Если заходит пользователь с домашнего интернета в Ташкенте, где есть только IPv4, сервер общается с ним по IPv4. Если заходит пользователь с мобильного интернета в Германии, где работает IPv6, тот же самый сервер отвечает ему напрямую по IPv6.

При этом в современных браузерах и смартфонах работает защитный механизм Happy Eyeballs. Когда пользователь открывает твой сайт, браузер запрашивает у DNS оба адреса (A и AAAA) и сначала пытается подключиться по новому протоколу IPv6. Если по какой то причине маршрут IPv6 у провайдера сломан и сервер не отвечает в течение 150 или 250 миллисекунд, браузер незаметно для человека переключается на старый адрес IPv4.

Что такое DNS64 и NAT64 и зачем они нужны

Поддерживать режим Dual Stack на одном сервере легко. Но внутри огромного мобильного оператора (например T Mobile в Германии), где в сети одновременно находятся десятки миллионов смартфонов, поддерживать сразу две параллельные сети слишком сложно и дорого.

Поэтому мобильные операторы пошли другим путем. Они полностью отключили старый протокол IPv4 на телефонах своих абонентов и оставили смартфонам только адреса IPv6.

Тут у любого веб разработчика возникает практический вопрос. Допустим, я создал для своего сайта поддомен ws.example.com, на котором работают WebSocket соединения, и прописал для него в DNS только старый адрес IPv4 (запись A), а новый адрес IPv6 не настраивал. Сможет ли пользователь из Германии с телефона, на котором есть только IPv6, подключиться к моему веб сокету?

Да, сможет в ста процентах случаев.

Во первых, если перед твоим сервером включена защита Cloudflare (горит оранжевая иконка облака в панели DNS), то Cloudflare автоматически берет роль Dual Stack на себя. Пользователю из Германии он выдаст свой собственный адрес IPv6, примет от него соединение, а дальше сам перешлет данные на твой сервер по твоему старому адресу IPv4.

Во вторых, даже если ты отключил проксирование Cloudflare и пустил трафик напрямую на свой сервер со старым адресом IPv4, немецкий пользователь все равно подключится. Его автоматически проведет через себя пара переводчиков DNS64 и NAT64, которые установлены у его мобильного оператора.

Цифры 64 в этих названиях не связаны с 64 битными процессорами. В сетях это читается как «из шестой версии в четвертую», то есть перевод трафика из протокола IPv6 в протокол IPv4.

Почему тут нужны сразу две программы (и DNS64, и NAT64)? Потому что на смартфоне пользователя протокол IPv4 выключен. Если просто сказать такому телефону старый адрес твоего сервера (например 185.10.20.30), операционная система телефона не поймет этот формат и сразу выдаст ошибку сети, даже не пытаясь никуда отправить пакет.

Поэтому мобильный оператор обманывает смартфон в два шага.

1. Первый шаг делает сервер DNS64 (подмена адреса в телефонной книге). Когда браузер на смартфоне пытается подключиться к домену ws.example.com, он спрашивает у операторского сервера DNS64 адрес нового формата IPv6 (запись AAAA). Сервер DNS64 проверяет твой домен, видит, что у тебя нет адреса IPv6, а есть только старый адрес 185.10.20.30. Чтобы телефон не выдал ошибку, DNS64 берет специальное стандартное начало адреса IPv6 (префикс переводчика) и приклеивает к нему в самый конец твой старый адрес 185.10.20.30. Получается искусственный, но правильный по формату адрес IPv6, который DNS64 и отдает смартфону.

2. Второй шаг делает роутер NAT64 (перевод пакета на границе сети). Смартфон видит нормальный адрес IPv6 и спокойно отправляет туда пакеты. Внутри сети мобильного оператора настроено правило отправлять все пакеты с таким искусственным началом на специальный пограничный роутер NAT64. Этот роутер ловит пакет от телефона, отрезает приклеенную шапку IPv6, достает из конца твой настоящий адрес 185.10.20.30, перекладывает данные в обычный пакет старого формата IPv4 и отправляет твоему серверу. Когда твой сервер отвечает, роутер NAT64 заворачивает ответ обратно в оболочку IPv6 и возвращает на телефон.

Здесь важно понять главное правило. Переводчик DNS64 и NAT64 стоит у мобильного оператора клиента и работает только в одну сторону, когда устройство из сети IPv6 само звонит наружу на старый сервер IPv4.

На обычных хостингах (вроде Hetzner или DigitalOcean) входящего переводчика нет. Если ты при покупке сервера решишь сэкономить пару долларов, откажешься от белого адреса IPv4 и возьмешь сервер только с адресом IPv6, то клиенты со старым домашним интернетом зайти к тебе напрямую не смогут (придется обязательно ставить спереди прокси Cloudflare). Более того, с такого сервера ты даже не сможешь скачать код командой git clone с сайта GitHub, потому что серверы GitHub до сих пор работают только на старом IPv4. Чтобы сервер без IPv4 мог скачивать пакеты со старых сайтов, в его настройки DNS нужно вручную прописать бесплатный публичный адрес DNS64 (такой переводчик бесплатно предоставляет например Cloudflare).

Что такое 464XLAT и CLAT

Связка DNS64 и NAT64 отлично спасает ситуацию, когда браузер или приложение обращается к твоему серверу по имени домена (например ws.example.com). Ведь именно в момент запроса домена сервер DNS64 может незаметно подсунуть телефону искусственный адрес IPv6.

Но что будет, если программа на телефоне вообще не запрашивает домен у DNS, а пытается подключиться к серверу напрямую по цифровому адресу IPv4 (например 185.10.20.30)?

В разработке такое происходит в двух случаях. Первое это старые приложения и игры, где программисты прописали адрес сервера цифрами прямо в коде. Второе это уже знакомая нам технология видеозвонков WebRTC, где во время установки связи браузеры и серверы пересылают друг другу свои прямые цифровые IP адреса без всяких доменных имен.

Когда программа на смартфоне (где есть только IPv6) пытается отправить пакет напрямую на цифры 185.10.20.30, сервер DNS64 об этом даже не узнает, потому что к телефонной книге DNS никто не обращался. Система телефона видит попытку отправить пакет старого формата и обрывает связь.

Чтобы видеозвонки и игры не ломались в мобильных сетях, инженеры придумали механизм 464XLAT. Цифры 4, 6 и 4 здесь означают двойной перевод каждого пакета по маршруту «из IPv4 в IPv6 и снова в IPv4», а слово XLAT это сокращение от английского слова перевод.

Работает это так.

1. Прямо внутри операционной системы каждого современного смартфона (Android и iOS) встроена маленькая системная программа переводчик, которая называется CLAT.

2. Когда CLAT видит, что мобильный оператор выдал телефону только новый протокол IPv6, она создает прямо внутри памяти телефона виртуальную (ненастоящую) сетевую карту старого образца и выдает ей внутренний адрес IPv4.

3. Приложение или движок видеозвонка WebRTC видит, что в телефоне якобы есть рабочий интернет IPv4, и отправляет пакет на голый адрес твоего сервера 185.10.20.30.

4. Программа CLAT прямо внутри процессора телефона перехватывает этот пакет, переделывает его в пакет формата IPv6 и отправляет по мобильной сети оператора (это первый перевод из четвертой версии в шестую).

5. На выходе из сети мобильного оператора этот пакет ловит уже знакомый нам пограничный роутер провайдера NAT64 (в документации к этой схеме его также называют PLAT), переделывает пакет обратно в старый формат IPv4 и доставляет на твой сервер (это второй перевод из шестой версии в четвертую).

Какой практический вывод из этого следует для разработчика?

Благодаря защитным механизмам DNS64, NAT64 и 464XLAT мобильный пользователь зайдет на твой сервер и подключится к сокету даже в том случае, если у тебя настроен только старый IPv4.

Но за работу через переводчики всегда приходится платить накладными расходами.

1. При работе через 464XLAT каждый пакет с голосом или видео пересобирается дважды (сначала процессором телефона, затем роутером оператора), что увеличивает задержку.

2. При работе длинных WebSocket соединений через операторский роутер NAT64 сокеты могут внезапно обрываться. Дело в том, что роутер NAT64 у мобильного оператора хранит список всех активных соединений абонентов в своей оперативной памяти. Чтобы память не переполнялась, роутер оператора принудительно удаляет любое соединение, по которому не передавались данные в течение 30 или 60 секунд. Если в твоем чате полминуты никто ничего не писал, переводчик оператора молча закроет соединение. Чтобы этого не происходило, нужно либо каждые 15 или 20 секунд отправлять по сокету пустые проверочные сообщения Ping и Pong, либо включить на своем сервере полноценный IPv6, чтобы мобильные клиенты соединялись с сервером напрямую в обход всех переводчиков.

Почему адрес из Hetzner не вставляется в Cloudflare

Разберем частую ошибку при первой настройке IPv6 на реальном примере хостинга Hetzner и панели DNS в Cloudflare.

Когда ты арендуешь сервер в Hetzner, хостер выдает тебе один старый адрес IPv4 и целый блок новых адресов IPv6. В панели управления Hetzner этот блок записан в виде четырех групп символов, разделенных двоеточиями, а в самом конце строки стоят два двоеточия подряд и запись /64.

Если скопировать эту строку целиком и попытаться вставить ее в запись AAAA в панели Cloudflare, появится ошибка о том, что введен неправильный адрес IPv6.

Происходит это потому, что запись с /64 на конце это не адрес одного конкретного сервера, а обозначение всей выделенной тебе подсети (по сути целой улицы из восемнадцати квинтиллионов адресов).

Любой адрес IPv6 длиной 128 бит всегда делится ровно пополам.

1. Первые 64 бита (первые четыре группы символов) это номер твоей сети в оборудовании Hetzner.

2. Вторые 64 бита (которые идут после двух двоеточий) это номер конкретного устройства внутри твоей сети. Два двоеточия подряд просто заменяют длинный ряд нулей, чтобы адрес было короче писать.

Настройки DNS в Cloudflare не принимают адрес всей улицы со значком /64, они требуют указать точный номер одного дома (одного сервера). Когда Hetzner автоматически создает твой сервер, он всегда назначает сетевой карте сервера самый первый адрес из выданного тебе блока. Поэтому чтобы добавить запись AAAA в Cloudflare, тебе нужно просто стереть /64 в конце строки и сразу после двух двоеточий поставить цифру 1.

Четыре места в коде и настройках сервера, где разработчики совершают ошибки

Самостоятельно настраивать переводчики сетей веб разработчику не нужно, это делают интернет провайдеры и сервисы вроде Cloudflare. Но как только ты включаешь для своего сайта Cloudflare или добавляешь запись AAAA в DNS, к тебе на бэкенд начинают приходить запросы от пользователей с адресами IPv6. Вот четыре конкретных места, которые нужно проверить в своем проекте.

1. Размер поля для IP адреса в базе данных. Если ты сохраняешь IP адреса пользователей в базу данных (например при регистрации, оплате или в историю входов), проверь длину колонки. Раньше разработчики часто ставили тип поля VARCHAR(15), потому что старый адрес IPv4 никогда не бывает длиннее пятнадцати символов. Но полный адрес IPv6 может занимать до 45 символов. Если в базе стоит ограничение в 15 символов, то при заходе первого же пользователя с мобильного интернета база данных выдаст ошибку и не даст человеку войти на сайт. Всегда ставь длину поля VARCHAR(45) или используй специальный тип данных INET в базе PostgreSQL.

2. Обработка адреса и порта в коде. В старом протоколе IPv4 адрес отделялся от номера порта символом двоеточия, поэтому многие программисты в коде просто разбивали строку по двоеточию через функцию split. В протоколе IPv6 сам адрес состоит из множества двоеточий. Если применить к нему обычный split, код развалится и получит кусок адреса вместо номера порта. Чтобы никогда не сталкиваться с этой ошибкой, не разбирай сетевые адреса вручную через строковые функции, а используй встроенные функции сетевой библиотеки твоего языка программирования (например функции SplitHostPort и JoinHostPort из стандартного пакета net в языке Go).

3. Ограничение частоты запросов (Rate Limiting) и блокировка ботов. На многих сайтах стоит защита, которая разрешает делать не больше десяти запросов в секунду с одного IP адреса. Для старого протокола IPv4 мы просто берем весь адрес целиком и записываем его в счетчик. Но в мире IPv6 блокировать один конкретный адрес бесполезно. Как ты уже видел на примере Hetzner, в сетях IPv6 каждому серверу или домашнему роутеру выдается не один адрес, а сразу целая подсеть /64, внутри которой лежат квинтиллионы бесплатных адресов. Спамер может отправлять каждый новый запрос со следующего адреса внутри своей бесплатной подсети, меняя последние цифры. Чтобы твой лимитер работал правильно, при получении любого входящего адреса IPv6 нужно программно отрезать от него вторую половину (последние 64 бита) и считать все запросы с первых 64 бит адреса как запросы от одного и того же пользователя.

1. Открытые порты во втором файрволе. Когда на твоем сервере работают оба протокола (Dual Stack), у сервера фактически появляются две отдельные входные двери. В операционной системе Linux старая программа для настройки файрвола iptables закрывает порты только для старого протокола IPv4, а для защиты протокола IPv6 там существует отдельная программа ip6tables. Из за этого часто случается опасная ситуация. Разработчик запускает на сервере базу данных или Redis, закрывает порт от внешнего мира через привычный iptables, проверяет сервер сканером по старому адресу IPv4, видит что порт закрыт, и считает сервер защищенным. А в это время база данных остается полностью открытой для всего интернета через вторую дверь по публичному адресу IPv6, потому что правила в ip6tables никто не настроил. Если ты используешь на сервере более современную утилиту ufw, она автоматически создает правила сразу для обоих протоколов, но проверять закрытие портов снаружи всегда нужно и по старому адресу IPv4, и по новому адресу IPv6.

Заключение

Подведем практический итог всей этой истории. Когда я разобрался в механике работы провайдерских переводчиков, стало понятно, почему пользователи с мобильного интернета в Германии спокойно заходили в мой голосовой чат даже тогда, когда на сервере был настроен только старый протокол IPv4. За меня всю черновую работу по переводу пакетов незаметно делали прокси серверы Cloudflare и операторские шлюзы NAT64 в связке с системной программой CLAT внутри самих смартфонов.

Но понимание того, как именно работает эта скрытая механика, позволило мне убрать узкие места в архитектуре чата. Одно дело, когда у тебя обычный сайт со статьями, где лишняя пересборка пакета на роутере мобильного оператора ни на что не влияет. И совсем другое дело, когда у тебя живой голосовой чат на базе WebSocket и WebRTC.

Если трафик мобильного пользователя идет через переводчики NAT64 и 464XLAT, его смартфон и оборудование оператора вынуждены дважды пересобирать каждый голосовой пакет на лету, а сам роутер оператора пытается принудительно закрыть веб сокет при любой паузе в передаче данных. Как только я правильно прописал адрес сервера с единицей на конце в запись AAAA для своих доменов, настроил прослушивание обоих протоколов и проверил регулярную отправку проверочных сообщений Ping и Pong в веб сокетах, мобильные клиенты получили возможность соединяться с сервером напрямую по чистому протоколу IPv6 без лишних посредников.

Что я советую сделать тебе на своем проекте прямо сейчас.

1. Не нужно бросать текущие задачи и переживать, если твой сервер пока работает только на старом адресе IPv4. Твой сайт уже доступен для всех пользователей мира, потому что мобильные операторы и Cloudflare позаботились об обратной совместимости.

2. Если твой хостинг (например Hetzner или DigitalOcean) уже бесплатно выдал твоему серверу подсеть IPv6, потрать десять минут и включи полноценный режим Dual Stack. Замени маску /64 в конце выданного адреса на единицу, добавь запись AAAA в панель DNS и убедись, что твой Nginx или бэкенд слушает оба сетевых интерфейса. Так ты избавишь мобильных пользователей от двойного перевода пакетов и случайных обрывов связи на операторских роутерах.

3. Обязательно проверь код своего бэкенда и настройки сервера по четырем пунктам, которые мы разобрали выше. Расширь колонку под IP адрес в базе данных минимум до 45 символов, убери ручное разбиение адресов по символу двоеточия в коде, переделай блокировку спамеров и лимиты запросов на проверку первых 64 бит адреса, и прямо сегодня проверь правила второго файрвола ip6tables на своем сервере, чтобы твоя база данных случайно не оказалась открытой для всего интернета.