IPv6 — это катастрофа (но поправимая)

В последнее время мы всё чаще слышим не самые приятные новости про IP-адреса. Компания AWS объявила, что будет брать по $0,005/час за каждый адрес IPv4, тем самым присоединившись к другим облачным провайдерам, сделавшим платным использование публичного адреса IPv4. GCP просит с клиентов по $0,004, а Azure и Hetzner — по €0,001/ч. Очевидно, что эпоха, когда облачные провайдеры расширялись, скупая дополнительное пространство IPv4, подходит к концу. Чем дальше, тем ценнее становятся эти адреса, и тем менее целесообразно предоставлять их бесплатно.

Так что перспективы ясны — нам нужно переходить на IPv6. Впервые о необходимости перехода на IPv6 я услышал, когда учился в колледже, а сейчас мне 36. Это я к тому, чтобы вы поняли, как давно стали очевидны эти перспективы. До этого с IPv6 я не работал, на рынке практически отсутствовал спрос на соответствующие навыки, и мне не доводилось трудиться в компаниях, где бы эта тема кого-то интересовала. Поэтому и осваивать я её не стал, хотя зря, потому что она прекрасно расширила бы мои навыки в сфере сетевых технологий.

Но теперь настал очередной удачный момент, чтобы этим заняться, и я решил перевести свой блог исключительно на IPv6. Он будет находиться за CDN для обработки трафика IPv4, но всё же пора уже вступить в ряды крутых ребят. Однако в процессе я выяснил одну весьма неприятную вещь: в IPv6 практически ничто не работает «из коробки». Основные зависимости тут же слетают, а обходные решения оказываются не готовыми к продакшену. Процесс перевода команд на IPv6 будет очень тернистым, преимущественно из-за того, что никто ещё с этим не сталкивался. Мы многие годы откладывали освоение этой технологии, и теперь придётся за это платить.

Почему IPv6 стоит приложенных усилий?

Я не собираюсь подробно сравнивать IPv4 и IPv6. В сети есть множество прекрасных статей на эту тему. Давайте просто вкратце посмотрим «Почему вообще есть резон переходить на IPv6».

Заголовок пакета IPv6

• Пространство адресов (это очевидно).
• Меньше полей заголовков (8 против 13 в v4).

• Ускоренная обработка: отсутствие контрольной суммы, в связи с чем маршрутизаторам не нужно выполнять перерасчёт для каждого пакета.
• Ускоренная маршрутизация: больше общих и иерархических маршрутов. (Не знаете, что такое «общий маршрут»? Поясню. Общий маршрут равнозначен совмещению нескольких IP, благодаря чему вам уже не требуются все эти адреса, только их общее направление, основанное на первой части адреса. То же самое касается маршрутов. Поскольку адреса IPv6 уникальны по всему миру, вы можете использовать компактную и эффективную магистральную маршрутизацию).
• QoS (качество обслуживания): поля Traffic Class (класс трафика) и Flow Label (идентификатор потока) упрощают предоставление качественного сервиса.
• Автоматическая адресация. Позволяет хостам IPv6 в сети LAN подключаться без маршрутизатора или DHCP-сервера.
• Можно добавить в IPv6 набор протоколов IPsec с Authentication Header (заголовком аутентификации) и Encapsulating Security Payload (безопасной инкапсуляцией полезной нагрузки).

Ну и самое значительное: потому что адреса IPv6 свободны, в отличие от адресов IPv4.

Настройка сервера исключительно на IPv6

По факту процесс настройки оказался прост. Я подготовил ПК с Debian и выбрал «IPv6». Затем возник первый сюрприз. Мой компьютер не получил адрес IPv6. Ему был присвоен адрес с префиксом /64, а именно 18,446,744,073,709,551,616. Будет нелишним пояснить, что мой скромный сервер на ARM смог масштабироваться для выполнения всей сетевой инфраструктуры в каждой компании, где я работал, на всех публичных адресах.

Такой подход кажется растратным, но если рассмотреть принцип работы IPv6, выяснится, что это не так. Поскольку IPv6 намного менее «говорлив» в сравнении с IPv4, то даже когда у меня в сети было 10 000 хостов, это ничего не меняло. Как уже говорилось, есть смысл сохранить всё пространство IPv6, даже если сначала это покажется безумно затратным. Так что просто не думайте, сколько адресов отправляется на каждое устройство.

Важно: противьтесь желанию оптимизировать использование адресов. Общаясь с более опытными системными администраторами, я понял, что это типичная ловушка, в которую попадают очень многие. Мы все зачастую волновались, сколько пространства осталось в блоке IPv4, и проводили немало времени за поиском решений этой проблемы. Теперь же она просто исчезла. Префикс /64 является минимальным, какой вам нужно настроить в интерфейсе.

Попытка использовать префикс ещё меньше, например, /68 или /96, как известно по опыту некоторых специалистов, может нарушить автоконфигурацию адресов без сохранения состояния. На каждый сайт вам нужно подразумевать префикс /48. Именно такое значение выдаётся региональным интернет-регистратором при выделении IPv6. Продумывая организацию сети, вам также нужно определиться с ограничением по полубайту (nibble boundary). По сути, этот способ упрощает чтение IPv6.

Предположим, у вас адрес 2402:9400:10::/48. Если вы захотите получить для каждой машины в однотипной сети только /64, то поделите его так:

Для /52 принцип тот же:

Вы по-прежнему можете сразу понять, какая перед вами подсеть.

Хорошо, свою машину я подготовил. Теперь попробуем настроить на ней рабочий сервер.

▍ Проблема 1 — не могу подключиться по SSH

Это была ожидаемая проблема. Протокол IPv6 не поддерживается ни моим домашним провайдером, ни рабочим. Так что хорошо, что я настроил свою машину, но сделать теперь с ней я ничего не могу. Ладно, пока что я подключил адрес IPv4, установил соединение по SSH и далее настрою cloudflared для запуска туннеля. Возможно, этот сервис выполнит преобразование на своей стороне.

Вот только Cloudflare работает иначе. Представьте себе моё удивление, когда в момент удаления адреса IPv4 туннель закрылся. По умолчанию утилита cloudflared предполагает использование IPv4, и вам необходимо добавить в служебный файл systemd следующее: --edge-ip-version 6. После этого туннель заработал, и подключиться по SSH мне удалось.

▍ Проблема 2 — не могу использовать GitHub

Хорошо, система налажена. Теперь пора заняться настройкой всего остального. Я запускаю скрипт конфигурации сервера, и он тут же даёт сбой. Он пытается обратиться к инструкциям установки hishtory, прекрасной программы отслеживания истории оболочки, которую я использую для всех своих задач. Скрипт безуспешно пробует получить с GitHub файл её установки. «Но это очень странно. Ведь GitHub должен поддерживать IPv6?»

А вот и нет. Конечно, очень плохо, что сервис, через который разработчики по всему миру выпускают ПО, не поддерживает IPv6. Но ведь и у Microsoft возникли проблемы, и теперь эта компания занимается только фальшивым ИИ, так что какая разница? В итоге я успешно использовал TransIP GitHub Proxy. Теперь у меня есть доступ к GitHub. Но далее Python выдал urllib.error.URLError: <urlopen error [Errno 101] Network is unreachable>. Ладно, сдаюсь. Предполагаю, что версия Python 3 в Debian не дружит с IPv6, но сейчас я не в настроении с этим разбираться.

▍ Проблема 3 — не могу настроить Datadog

Займёмся чем-то попроще. Я определённо могу настроить Datadog, чтобы следить за своей машиной. Мне не нужно множество метрик, лишь несколько исторических данных о загрузке. Перехожу в Datadog, авторизуюсь и запускаю процесс… Сразу же сбой. Простая настройка подразумевает выполнение curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh. Но ведь S3 поддерживает IPv6, тогда какого чёрта?

curl -v https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh
*   Trying [64:ff9b::34d9:8430]:443...
*   Trying 52.216.133.245:443...
* Immediate connect fail for 52.216.133.245: Network is unreachable
*   Trying 54.231.138.48:443...
* Immediate connect fail for 54.231.138.48: Network is unreachable
*   Trying 52.217.96.222:443...
* Immediate connect fail for 52.217.96.222: Network is unreachable
*   Trying 52.216.152.62:443...
* Immediate connect fail for 52.216.152.62: Network is unreachable
*   Trying 54.231.229.16:443...
* Immediate connect fail for 54.231.229.16: Network is unreachable
*   Trying 52.216.210.200:443...
* Immediate connect fail for 52.216.210.200: Network is unreachable
*   Trying 52.217.89.94:443...
* Immediate connect fail for 52.217.89.94: Network is unreachable
*   Trying 52.216.205.173:443...
* Immediate connect fail for 52.216.205.173: Network is unreachable
123456789101112131415161718

Проблема не в S3 или машине, потому что я вполне могу подключиться к тестовому бакету S3, который предоставляет AWS.

curl -v  http://s3.dualstack.us-west-2.amazonaws.com/
*   Trying [2600:1fa0:40bf:a809:345c:d3f8::]:80...
* Connected to s3.dualstack.us-west-2.amazonaws.com (2600:1fa0:40bf:a809:345c:d3f8::) port 80 (#0)
> GET / HTTP/1.1
> Host: s3.dualstack.us-west-2.amazonaws.com
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 307 Temporary Redirect
< x-amz-id-2: r1WAG/NYpaggrPl3Oja4SG1CrcBZ+1RIpYKivAiIhiICtfwiItTgLfm6McPXXJpKWeM848YWvOQ=
< x-amz-request-id: BPCVA8T6SZMTB3EF
< Date: Tue, 01 Aug 2023 10:31:27 GMT
< Location: https://aws.amazon.com/s3/
< Server: AmazonS3
< Content-Length: 0
<
* Connection #0 to host s3.dualstack.us-west-2.amazonaws.com left intact
1234567891011121314151617

Хорошо. Я проделаю всё вручную через apt.

0% [Connecting to apt.datadoghq.com (18.66.192.22)]

Да ёпрст! Ладно, Datadog исключается. В этот момент я понял, что эксперимент с использованием только IPv6 не сработает. Почти ничто не работает напрямую без посредника или всяческих ухищрений. Попробую по максимуму придерживаться IPv6, но использовать только его пока точно не вариант.

NAT64

Для доступа к ресурсам IPv4 через IPv6 вам нужно пройти через сервис NAT64. Я использовал этот. Тут же все мои проблемы исчезли. Я немного переживаю, насколько можно доверять процессы взаимодействия с критическими интернет-ресурсами сервису, по сути являющемуся хобби-проектом. Но раз уж, по всей видимости, ни один из восходящих сервисов не утруждается налаживанием работы IPv6, то выбора у меня особо не остаётся.

Я удивлён, насколько мало доступно альтернатив. Вот весь список провайдеров, какой мне удалось собрать:

Большинства из них сейчас уже нет. Связь Dresel не работает, Trex в ходе тестирования вызывал проблемы, August Internet закрылся, большинство тестовых устройств Go6lab отключены, Tuxis сработал, но их сервис был запущен в 2019 и, похоже, с тех пор не дорабатывался. По сути, Kasper Dupont является единственным, реально заинтересованным в продвижении IPv6. Спасибо тебе, Kasper.

Да, по факту развитие этого сегмента всемирной сети держится на плечах всего одного человека.

▍ Kasper Dupont

Мне стало интересно познакомиться с этим энтузиастом, и я написал ему письмо с несколькими вопросами. Вот часть нашей переписки:

Я: Лично мне сервис Public NAT64 показался очень эффективным инструментом перехода, но я хотел бы побольше узнать, почему вы этим занимаетесь.

Каспер: я делаю это в первую очередь ради продвижения IPv6. В течение нескольких лет у меня была возможность пользоваться дома нативной сетью исключительно на IPv6, используя DNS64+NAT64, и мне этот опыт очень понравился. В результате я просто захотел дать и другим людям возможность его испытать.

Когда я поднял первый шлюз NAT64, это стало просто подтверждением работоспособности расширения NAT64, которое я хотел распространять. Сервис NAT64 стал популярен, а вот расширение не особо.

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

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

Каспер: Под мои личные продукты у меня запущено 7 виртуальных машин, подключённых к разным хостингам. Некоторые из них я арендую у Hetzner по 4,51 евро в месяц.

Другие VM обходятся чуть дороже, но ненамного.

Из всех машин 4 используются для сервиса NAT64, а остальные для других сервисов, связанных с переходом на IPv6. Например, на отдельной VM у меня работает этот сервис.

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

Я: Было бы здорово, если бы вы рассказали о каких-нибудь технических деталях своего проекта.

Каспер: Сразу видно — свой человек :-)

Я могу углубиться в детали очень сильно.

Думаю, что мой сервис отделяет от других то, что каждый из моих серверов DNS64 автоматически обновляется префиксами NAT64 на основе проверки состояния всех шлюзов. Это означает, что выход из строя любого отдельного шлюза NAT64 окажется для потребителей практически незаметен. Кроме того, это упрощает обслуживание. Думаю, благодаря этому, мой сервис предоставляет один из высочайших уровней доступности среди всех публичных сервисов NAT64.

Весь код NAT64 разработан мной, и на данный момент он выполняется как демон в пространстве пользователя Linux. Правда сейчас я подумываю о переносе наиболее важной для производительности части в модуль ядра.

Сайт оригинала статьи

Хорошо, всё основное я наладил. Для передачи контейнеров Docker через IPv6 вам потребуется добавить в начало имени образа следующее: registry.ipv6.docker.com/library/. Например, image: mysql:8.0 станет image: registry.ipv6.docker.com/library/mysql:8.0.

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

Разобравшись с этим, я настроил сайт как запись DNS AAAA и позволил Cloudflare выступить в качестве посредника, то есть этот ресурс сможет обрабатывать оповещения IPv6 и перенаправлять трафик ко мне. По сравнению с прежней конфигурацией я изменил одну вещь. Раньше я использовал веб-сервер Caddy, но поскольку теперь бо́льшая часть моего трафика поступает через Cloudflare, я переключился на Nginx. Зная, что весь трафик поступает от Cloudflare, вы можете ради удобства сменить режим работы SSL.

Теперь у меня в Nginx загружен сертификат Origin из Cloudflare с настроенной функциональностью Authenticated Origin Pulls, поэтому я уверен, что весь трафик поступает именно через Cloudflare. Этот сертификат выдаётся на 15 лет, так что я могу уверенно внедрить его в систему управления учётными цифровыми идентификационными данными и забыть. Для интересующихся этой темой есть хорошее руководство.

Отлично. Сайт налажен и работает.

Нерешённые проблемы

• Мои контейнеры по-прежнему не могут взаимодействовать с ресурсами IPv4 несмотря на то, что находятся в сети IPv6 с мостом IPv6. Разрешение имён DNS64 работает, и я также добавил в Docker fixed-cidr-v6. Я могу прекрасно взаимодействовать с ресурсами IPv6, но преобразование NAT64 не функционирует. Буду с этим разбираться.
• Пришлось добавить NAT с ip6tables.
• Проблемы с SMTP-сервером. Я не смог найти коммерческий SMTP-сервис, имеющий запись AAAA. Я опробовал Mailgun, SES и несколько более мелких — ни один не подошёл. Даже Fastmail не сгодился. Если вам известен хороший вариант, будьте добры, напишите мне сюда.

Почему бы не продолжать использовать IPv4?

Давайте на минуту забудем, что у нас кончаются адреса. Если бы мы начали внедрять IPv6 раньше, то построение инфраструктуры происходило бы совсем иначе. Компании зачастую используют такие технологии, как балансировщики нагрузки и туннели, не потому что фактически нуждаются в них, а потому что им требуется некий способ разделить закрытые IP-диапазоны и открытый IP-адрес, который они могут внести в запись DNS А.

Если разбить балансировщик нагрузки на составляющие, то он выполняет две задачи: распределяет входящие пакеты по внутренним серверам и проверяет состояние этих серверов, исключая нездоровые из ротации. Сегодня эти инструменты зачастую обрабатывают такие процессы, как завершение SSL и сбор метрик, но эта функциональность не является для них необходимой.

Балансировать нагрузку можно множеством способов, но самыми распространёнными являются следующие:

1. Round-robin. Круговая обработка запросов на подключение.
2. Weighted Round-robin. Взвешенная круговая обработка, в результате которой сервера получают больше или меньше нагрузки.
3. Least-Connection. При получении новых запросов их распределение происходит по серверам с наименьшим числом подключений.
4. Weighted Least-Connection. То же самое, но можно отдавать приоритет определённым машинам.

Как видите, здесь нет ничего, что требовало бы или получало преимущество от использования закрытого IP-адреса вместо публичного. Настройка хостов для получения трафика только от одного источника (балансировщика нагрузки) производится просто и относительно дёшево в вычислительном смысле. Многие схемы инфраструктуры, с которыми мы оказались вынуждены работать, например, VPC, шлюзы NAT, публичные и закрытые подсети — без всех них можно было либо обойтись полностью, либо опираться на эти решения в меньшей степени.

Ещё одна ирония заключается в том, что практика формирования белых списков IP-адресов, которая сейчас является неактуальной, поскольку мы все используем адреса, принадлежащие облачным провайдерам, в этом случае оказалась бы кстати. С появлением спроса компаниям стало бы проще приобретать для себя адреса с префиксом /44, и люди бы начали чаще обращаться за покупкой блока IP-адресов в Американский реестр номеров интернета (ARIN), Координационный центр распределения ресурсов сети интернет в Европейском регионе (RIPE) или Азиатско-Тихоокеанский сетевой информационный центр (APNIC).

Вам бы никогда не пришлось думать о том «Купит ли Google дополнительные IP-адреса» или «Мне нужно мониторить страницу поддержки GitHub, чтобы убедиться, что они не добавят их позднее». У вас бы был один блок, который компания бы использовала для всего бизнеса до конца его существования. Системам контейнеров не потребовалось бы присваивать внутренние IP-адреса каждому хосту, достаточно было бы выделять для них сегменты публичных IP, а также при необходимости делать оповещения через стандартные публичные DNS.

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

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

Улучшится ли ситуация?

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

Надеюсь, что в конечном итоге ситуация всё же улучшится. Думаю, по меньшей мере, это должно открыть новые возможности для небольших компаний, стремящихся занять для себя IP-диапазон, которым они будут пользоваться неограниченное время. К тому же, наверняка с распространением IPv6 упростится и его использование. Но должен сказать, что сейчас эта технология находится в поразительно плачевном состоянии.

Если вы являетесь небольшой компанией, которая не желает платить лишние налоги на IP, уделите время на решение множества проблем, с которыми вам предстоит столкнуться.

Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх 🕹️

Автор: Дмитрий Брайт

Источник