Что на самом деле должен фиксировать реестр адресов выхода VPN?
Реестр выходов полезен только тогда, когда каждая запись указывает своё значение, публикатора и срок действия. Классификация — это не идентификация абонента.
Реестры выходов звучат как списки, и список — не самая сложная часть. Самая сложная часть — решить, что утверждает каждая запись, кто может её опубликовать и что происходит, когда утверждение перестаёт быть верным. В этих предложениях смешиваются три разные роли адреса, и реестр, который их смешивает, не может надёжно ответить ни на один вопрос. Проследите одну запись от публикации до отзыва, и требования к проектированию появятся сами собой.
Начните с записи, а не со списка
Первый вопрос — не сколько адресов включить, а что означает одна строка. Описывает ли она, куда подключаются клиенты, какой источник может видеть получатель или кто держит выделение в реестре? Это три утверждения с тремя владельцами и тремя режимами отказа. Реестр, который не указывает, какое из них он фиксирует, нельзя проверить, исправить или закрыть. Правильное понимание смысла — это работа над дизайном, а список — лишь результат.
Напишите определение строки, прежде чем писать любую схему. Если определению нужно слово и, то это, вероятно, две записи, которые выдают себя за одну.
Три роли адреса, которые выглядят одинаково
Роли легко перепутать, потому что одно развёртывание может использовать все три сразу и часто так и делает. Сервис может завершать соединения на одном адресе и пересылать трафик с другого, а реестр фиксирует совершенно третий факт.
| Address role | Who may publish | What it does not prove | Withdrawal trigger |
|---|---|---|---|
| Forwarded exit | The operator that forwards the traffic, or a feed it authorizes | That a subscriber is behind the address, or that all its traffic is tunnelled | The address stops forwarding for that operator, or the prefix is reassigned |
| Registered allocation | The registry, or the holder of the allocation | That the resource is used as a VPN exit, or which application uses it | The allocation is returned, transferred, or the holder changes |
| Tunnel entry | The operator that terminates the tunnel | That traffic exits from the same address, or that the client is a subscriber | The endpoint is decommissioned or its address changes |
Хостинговый блок может содержать выходы VPN и несвязанные рабочие нагрузки бок о бок, поэтому совпадение в реестре ничего не говорит о том, что делает данный адрес в данный момент. Запись, которая не называет свою роль, не является доказательством чего-то конкретного. Именно название роли делает запись опровержимой. Укажите и семейство адресов, потому что реестр, который молча охватывает только IPv4, введёт в заблуждение каждого, кто предполагает обратное.
Проследите одну запись от публикации до отзыва
Возьмите один гипотетический выход и проследите его. Оператор публикует префикс и свою роль в объявленное время вступления в силу, потребители получают его, а затем адрес перестаёт служить выходом. Каждый шаг требует правила: кто может публиковать, что префикс на самом деле охватывает, когда запись вступает в силу и как она отзывается. Поток без пути отзыва накапливает устаревшие утверждения, которые никто не может отличить от текущих.
Отделите полномочия публиковать от точности метки. Запись реестра, связывающая организацию с ресурсом, доказывает выделение, а не текущее использование, и это разные утверждения с разными доказательствами. Потребителям нужно знать, какому из двух они доверяют.
Определите и исправление. Адрес, перераспределённый клиенту, или несвязанный сервис, пойманный неверной меткой, нуждается в документированном пути к исправлению, а не в споре в очереди заявок. Триггер отзыва относится к тому же документу, что и правило публикации.
Что опубликованный поток может и не может поддерживать
Опубликованные атрибуты префикса — устоявшийся шаблон, и существующие примеры описывают географию или собственность, а не поведение. Потоку VPN понадобятся собственная семантика, собственные правила доказательств и собственный процесс проверки, а переименование списка стран не даёт ничего из этого. Руководство по реестру ARIN показывает, что утверждают записи о выделении, а что нет, и новый поток должен добиться той же ясности в отношении собственных утверждений. Это задача спецификации, а не задача переименования.
Что такой поток может поддерживать — это решение о классификации сетевого источника. Чего он не может — идентифицировать человека за общим адресом, доказать, что весь трафик с этого адреса идёт через туннель, или решить, является ли конкретный запрос злоупотреблением. Это три отдельных вопроса с тремя отдельными требованиями к доказательствам.
Держите юридический вопрос вне спецификации
Техническая спецификация не может решить, является ли предлагаемое требование регистрации законным, соразмерным или разумным. Эта оценка требует фактического текста закона, затронутых прав, юрисдикции и юридического анализа, которого формат данных предоставить не может. Формат может быть хорошо спроектирован и всё же поддерживать плохую политику.
Что спецификация может сделать — это сделать дискуссию конкретной. Сначала определите предлагаемые данные, их границы и режимы отказа, чтобы политический аргумент касался реального механизма, а не неопределённого списка, который каждый участник представляет по-своему. Это максимум, что технический документ может внести в юридический вопрос.