Адреса IPv6 не заменяют ваш VPN: пройдите исходную работу

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

Назовите работу, прежде чем убирать инструмент

Люди говорят «VPN», когда имеют в виду одно из трёх устройств, и все три отказывают по разным причинам. Добраться до одного приложения, опубликованного одной командой, — это задача доступа к приложению. Войти в заданный набор частных сетей, чтобы несколько площадок могли достигать друг друга, — это отношение маршрутизации. Поддерживать стабильный административный слой поверх инфраструктуры, которой вы не управляете полностью, — это операционное устройство со своим планом адресов.

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

Публичный адрес — не шифрование

Адрес глобальной области говорит, откуда узел доступен; он ничего не говорит о том, зашифрован ли или аутентифицирован приходящий туда трафик. Обсуждение безопасности в RFC 8504 отделяет поддержку реализации IPsec от более широкого выбора между IPsec, TLS, SSH и другими подходами, и именно это различие исчезает, когда доступность читают как защиту. Стек, поддерживающий механизм, доказал лишь то, что механизм доступен, и никогда — что этот поток прошёл через него. Для IPsec в частности согласованная ассоциация и выбираемый ею трафик определяют, что защищено, а семейство адресов — свойство пакета, а не политика для него.

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

Что ещё даёт наложение

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

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

Пройдите службу, которая становится публичной

Начните с узла и перечислите, что действительно слушает, потому что одобренное вами приложение редко бывает единственным на машине. ss -lntup печатает каждого слушателя TCP и UDP с его адресом привязки и добавляет процесс-владелец там, где позволяют ваши права, что с первого взгляда показывает, сидит ли административный интерфейс на подстановочном адресе или только на loopback. Повторите как ss -6 -lntup, если ваш стек держит сокеты IPv6 отдельно.

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

Два теста, затем решите, что отключить

Прежде чем убирать слой, ответьте на два вопроса на бумаге. Первый: нужна ли требованию частная маршрутизация, то есть доступность, которую публичный адрес не подразумевает и поставщик доступа не предлагает? Второй: нужна ли ему граница защиты, то есть шифрование и аутентификация на потоке, который иначе открыто пересёк бы недоверенный путь? Если оба ответа для этой службы «нет», туннель — кандидат на удаление; если хотя бы один «да», он остаётся.

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