Вступление: IPv6 без лишней теории
IPv6 часто воспринимается как технология на будущее, которую можно включить когда-нибудь потом. Для VPN-сервисов это уже не совсем так, ибо современные сети все чаще используют IPv6 одновременно с IPv4, а значит VPN-инфраструктуре приходится учитывать оба протокола.
Причина же появления IPv6 достаточно простая, IPv4-адресов просто стало мало. IPv4 использует 32-битные адреса, поэтому его адресное пространство ограничено примерно 4.3 миллиардами адресов. Для современного интернета этого оказалось недостаточно, и сеть уже много лет компенсирует нехватку адресов с помощью NAT и CGNAT.
IPv6 использует 128-битные адреса, поэтому его адресное пространство практически несопоставимо с IPv4 по размеру. Если обычный IPv4 выглядит как 123.10.20.30, то IPv6 может выглядеть так:
2001:db8:1234:5678::10
На первый взгляд адрес выглядит сложнее, да и запомнить его проблемно. На практике же принцип тот же, это просто сетевой адрес, по которому система может найти нужное устройство или сервис.
Для VPN важен не сам факт существования нового формата адресов, а то, что IPv6 позволяет строить сетевую инфраструктуру значительно свободнее и в некоторых сценариях уменьшать зависимость сервиса от конкретных IPv4-адресов и маршрутов.
Почему IPv6 полезен именно VPN-сервису
VPN-сервис постоянно работает с адресами. Есть адреса серверов, адреса клиентов, внутренние подсети, VPN-интерфейсы, маршруты и прочие крайне важные вещи. В IPv4 все это вполне можно организовать, но по мере роста инфраструктуры все сильнее приходится учитывать дефицит публичных адресов, NAT и особенности маршрутизации.
Для VPN-сервиса это становится особенно заметно в сетях, где доступ к отдельным IP-адресам или другим сетевым ресурсам может ограничиваться. Если инфраструктура полностью завязана на один IPv4-адрес, проблема с доступностью именно этого адреса автоматически становится проблемой подключения к VPN.
IPv6 позволяет использовать дополнительный протокол и отдельное адресное пространство. Например, VPN-сервер может одновременно иметь IPv4 и IPv6, а клиент сможет использовать тот вариант подключения, который доступен из его сети.
Это не означает, что IPv6 автоматически защищает от блокировок. Ограничения могут применяться и к IPv6-адресам, однако наличие второго протокола дает VPN-сервису больше вариантов для построения инфраструктуры и уменьшает зависимость от одной конкретной точки подключения.
Тем не менее, по нашим наблюдением, органы власти все-таки реже обращают свой взор в сторону IPv6-адресов, предпочитая в первую очередь заниматься ограничениями и блокировками относительно IPv4-адресов, которые где-либо "засветились". Насколько долго это продлится никому неизвестно.
IPv6 внутри VPN
Одно из самых полезных применений IPv6 это использование его непосредственно внутри VPN-туннеля.
Например, WireGuard-сервер может иметь внутренний IPv6-адрес:
fd42:42:42::1/64
а клиент:
fd42:42:42::2/128
В таком случае у VPN появляется собственная IPv6-сеть. Для этого необязательно выдавать клиентам публичные IPv6-адреса.
Это удобно для связи между VPN-серверами, клиентами и внутренними сервисами. VPN в таком случае становится не обычным способом вывести трафик пользователя в интернет, а полноценной виртуальной сетью, внутри которой можно использовать обычную IPv6-маршрутизацию и все более гибко настраивать.
Внешний транспорт и адресация внутри VPN могут быть разными. Клиент может подключаться к серверу по IPv4, а после установления туннеля использовать IPv6 внутри VPN. И наоборот, если между клиентом и сервером есть хороший IPv6-маршрут, сам VPN-туннель можно устанавливать непосредственно по IPv6.
Для VPN-сервиса это также удобно с точки зрения изоляции внутренних сетей. Отдельный IPv6-префикс можно использовать для серверов, клиентов и внутренних сервисов, не смешивая их с основной IPv4-адресацией.
Подключение к VPN по IPv6
Если VPN-сервер имеет рабочий IPv6, он может использоваться в качестве конечной точки точно так же, как IPv4.
Для WireGuard, например:
Endpoint = [2001:db8:1234::10]:51820
Кстати, квадратные скобки здесь нужны из-за синтаксиса IPv6, сам адрес содержит двоеточия, поэтому их необходимо отделить от номера порта.
Особенно интересным такой вариант становится в сетях с CGNAT. При использовании IPv4 клиент может находиться за NAT оператора, тогда как IPv6 при наличии корректной маршрутизации позволяет установить соединение без этой дополнительной трансляции.
Для VPN-сервиса это также означает наличие еще одного варианта подключения к серверу. Если конкретный IPv4-маршрут недоступен из определенной сети, наличие IPv6 может позволить использовать другой путь до той же инфраструктуры.
Но это не означает, что IPv6 автоматически обходит блокировки. Если ограничение применяется непосредственно к IPv6-адресу, доменному имени или маршруту, соединение по IPv6 также может оказаться недоступным.
Поэтому для VPN-сервиса разумнее не выбирать между IPv4 и IPv6, а поддерживать оба варианта и проверять их доступность из сетей пользователей.
IPv6 и блокировки
Для VPN-сервисов IPv6 становится особенно интересным именно при рассмотрении сетевых ограничений.
На территории РФ доступ к интернет-ресурсам может ограничиваться по различным сетевым параметрам, ибо ухищрения местных властей не знают предела. В том числе в системе ограничений используются доменные имена и сетевые адреса, поэтому конкретный IP-адрес или целая подсеть этих адресов может стать причиной недоступности сервиса для части пользователей.
Если VPN-сервис использует только один IPv4-адрес, то ограничение доступа к этому адресу фактически лишает пользователя возможности подключиться к серверу по данному адресу.
При наличии IPv6 у сервиса появляется еще один вариант адресации. Например, тот же сервер может быть доступен одновременно по IPv4 и IPv6, а клиент при наличии рабочего IPv6-соединения сможет установить VPN-туннель через него. При этом не стоит воспринимать IPv6 как какой-то специальный способ обхода РКН. IPv6 может быть ограничен точно так же, как IPv4. Его практическая польза заключается в том, что сервис получает дополнительный адрес и потенциально другой маршрут до своей инфраструктуры.
Именно поэтому при проектировании VPN лучше не делать один IP-адрес единственной точкой входа в сервис. Несколько серверов и разные IPv4 с IPv6 дают значительно больше возможностей для поддержания доступности инфраструктуры.
IPv6 и устойчивость VPN-инфраструктуры
Представим, что VPN-сервис имеет один сервер и один публичный IPv4-адрес. Клиент подключается непосредственно к нему, и вся доступность сервиса зависит от этого адреса. Если адрес становится недоступен из сети конкретного оператора, пользователь уже не сможет установить VPN-соединение, даже если сам сервер продолжает работать нормально.
При использовании IPv6 сервис может предоставить дополнительную точку подключения. Сервер получает IPv4 и IPv6, а доменное имя может содержать одновременно записи A и AAAA. В таком случае клиентская система получает информацию сразу о двух вариантах подключения.
Для крупного VPN-сервиса это особенно полезно. IPv6 позволяет выделять отдельные подсети для серверов и различных сетевых сегментов, а сама инфраструктура становится менее зависимой от ограниченного количества IPv4-адресов.
При этом наиболее надежным вариантом остается не один IPv6-адрес вместо одного IPv4-адреса, а нормальная распределенная инфраструктура с несколькими серверами и сетями.
IPv6 не является гарантированным способом обхода блокировок
Нельзя просто выдать VPN-серверу IPv6 и считать, что после этого он перестанет попадать под ограничения. IPv6 является всего лишь другой версией IP-протокола, если конкретный адрес или связанный с ним ресурс становится недоступен из сети пользователя, наличие IPv6 само по себе этого не изменит.
Кроме того, ограничения могут затрагивать не только отдельный IP-адрес. Проблема может находиться на уровне доменного имени, DNS, маршрутизации или самого сетевого трафика. Поэтому вновь и вновь повторимся, IPv6 правильнее рассматривать как дополнительный вариант подключения и элемент отказоустойчивости VPN-инфраструктуры, а не как гарантию доступности сервиса при любых блокировках.
Если VPN-сервис хочет повысить устойчивость к сетевым ограничениям, гораздо полезнее сочетать IPv4 и IPv6 с разными серверами, сменой IP-адресов и корректной настройкой VPN-сервиса.
Почему это становится все важнее
Современные клиенты могут получать IPv6 от домашнего провайдера, мобильного оператора или другой сети совершенно автоматически. Пользователь может даже не знать, что его устройство использует IPv6, ОС сама выберет доступный протокол.
Если VPN-сервис предоставляет клиенту только IPv4, он заранее отказывается от одного из доступных вариантов подключения. В некоторых сетях это практически никак не ощущается, а в других IPv6 может иметь другой маршрут или вообще быть единственным нормально работающим вариантом доступа к конкретной инфраструктуре.
Особенно важно это для мобильных сетей и других современных подключений, где IPv6 используется достаточно активно.
С точки зрения VPN-сервиса принцип довольно простой, если у клиента есть рабочий IPv6, нет особого смысла искусственно заставлять его использовать только IPv4. Гораздо логичнее поддерживать оба протокола и позволять клиентскому устройству использовать доступный вариант.
IPv6 не ускоряет VPN автоматически
Отдельно стоит упомянуть о распространенном представлении, что IPv6 сам по себе должен сделать VPN быстрее.
Никакой гарантированной прибавки к скорости у IPv6 нет. На реальную производительность влияют маршрут между сетями, пропускная способность каналов, загрузка сервера, оборудование, VPN-протокол и множество других факторов.
IPv6 может оказаться быстрее в конкретной сети, если оператор предоставляет более удачный маршрут. Но вполне возможна и обратная ситуация.
Для VPN-сервиса это особенно важно при анализе проблем с доступностью. Если IPv4 работает плохо, а IPv6 работает нормально, причина может находиться именно в различии маршрутов между двумя протоколами.
Поэтому IPv6 лучше рассматривать не как рекламную кнопку "ускорение интернета за счет волшебного адреса в лучшем VPN-сервисе", а как дополнительный сетевой протокол, который позволяет использовать другой маршрут и строить инфраструктуру без лишней зависимости от IPv4.
IPv6 и приватность
IPv6 сам по себе не делает пользователя анонимным и не заменяет VPN. Это просто другой способ адресации устройств в IP-сети.
В IPv6 существуют механизмы временных адресов, которые могут использоваться для уменьшения длительности применения одного и того же адреса при исходящих соединениях. Но это отдельный механизм IPv6 и не имеет отношения к шифрованию VPN-трафика.
Для VPN-сервиса здесь важнее другое. Если пользователь подключен к VPN и ожидает, что весь его трафик проходит через туннель, IPv6 также должен быть учтен в маршрутизации.
Иначе может получиться ситуация, когда IPv4-трафик идет через VPN, а IPv6 продолжает использовать обычное подключение провайдера. В таком случае пользователь получает неполную защиту соединения, даже если сам VPN-туннель работает нормально.
Поэтому если вы не хотите резко понять, что оказывается IPv6 не защищал ваш интернет-трафик от дяди майора, то стоит заранее позаботиться об обработке IPv6-соединений и все-таки использовать VPN.
Главная практическая проблема - IPv6 leak
Поддержка IPv6 особенно важна для full-tunnel VPN. Представим, что VPN правильно перенаправляет весь IPv4-трафик клиента через сервер, но IPv6 вообще не учитывается. Тогда IPv4 будет проходить через VPN, а IPv6 продолжит использовать обычное подключение провайдера.
Получается ситуация, когда пользователь подключён к VPN и считает, что весь трафик идет через него, хотя часть соединений фактически проходит мимо туннеля, что и называют IPv6 leak.
Для VPN-сервиса здесь есть два нормальных варианта, либо корректно маршрутизировать IPv6 через VPN, либо явно отключать IPv6 в тех сценариях, где сервис не собирается его поддерживать. Оставлять IPv6 включённым и просто надеяться, что клиент им не воспользуется крайне сомнительная идея.
При этом проблема IPv6 leak имеет отношение не только к приватности. Если пользователь подключается к VPN именно для доступа к определенным ресурсам через инфраструктуру сервиса, часть IPv6-трафика, ушедшая напрямую через провайдера, вообще не будет использовать VPN-соединение.
Поэтому полноценная поддержка IPv6 это задача всей VPN-инфраструктуры, а не только конфигурации клиента.
Что необходимо проверить VPN-сервису
Для нормальной поддержки IPv6 недостаточно просто назначить серверу IPv6-адрес. В ExpressHost сервер получает адрес автоматически, об этом можно не беспокоиться, а вот проверить его работу еще как стоит.
Нужно проверить весь путь трафика, а именно наличие IPv6-маршрута, forwarding, firewall, DNS, настройки VPN-интерфейса и само собой выход в интернет.
Если IPv6 используется как дополнительная точка подключения к VPN, необходимо отдельно проверить, что клиент действительно может установить соединение с сервером по IPv6.
На Linux базовую диагностику можно выполнить стандартными командами:
ip -6 addr
ip -6 route
ping -6 google.com
curl -6 https://www.youtube.com/
Особенно важно убедиться, что IPv6-трафик действительно использует VPN-маршрут, если сервис работает в режиме full tunnel.
Также стоит проверить работу DNS, поскольку наличие корректного IPv6-адреса у сервера еще не означает, что доменное имя VPN-сервиса будет корректно разрешаться и использовать IPv6.
Итог
IPv6 для VPN это уже не просто экспериментальная технология и не функция на будущее. Он решает вполне конкретные задачи, а именно предоставляет огромное адресное пространство, уменьшает зависимость от NAT и CGNAT, позволяет строить собственные IPv6-сети и даёт VPN-сервису ещё один полноценный вариант сетевого подключения.
Для VPN-сервисов, работающих с пользователями из Российской Федерации, IPv6 может быть полезен и с точки зрения устойчивости инфраструктуры. Если конкретный IPv4-адрес или маршрут до него становится недоступен из определенной сети, наличие IPv6 дает сервису еще один вариант подключения.
При этом IPv6 не является гарантированным способом обхода блокировок. Ограничения могут применяться и к IPv6, а проблема может находиться не только на уровне IP-адреса. Поэтому рассчитывать исключительно на смену IPv4 на IPv6 не стоит.
На практике наиболее разумный подход это поддерживать оба протокола и корректно маршрутизировать их через VPN.
Особенно важно не забывать про IPv6 при настройке full tunnel. Если IPv4 проходит через VPN, а IPv6 остаётся за пределами туннеля, пользователь получает неполную маршрутизацию и потенциальную утечку трафика, что всегда может неприятно аукнуться как пользователю, так и вам, как владельцу сервиса.
В итоге IPv6 для VPN-сервиса это не попытка сделать инфраструктуру сложнее, а наоборот, при правильной настройке он позволяет избавиться от части ограничений IPv4, получить дополнительные варианты подключения и спокойнее масштабировать сеть.
А пользователю все это должно быть практически незаметно, он подключается к VPN, а сервис уже сам разбирается с тем, какой протокол использовать и куда отправить каждый пакет.
Использовать IPv6 или нет сугубо ваше решение, однако если вы хотите развернуть полноценный и надежный VPN-сервис, особенно ориентированный на работу в условиях сетевых ограничений, то обслуживание IPv6 этому явно не помешает.