Одноранговый VPN по-прежнему имеет центральные зависимости

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

Диаграмма без центральной стрелки пересылки может скрывать регистрационный орган, службу обнаружения и ретранслятор, которые все являются операционными зависимостями.

Прямой путь, общая плоскость управления

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

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

Обнаружение, доверие и ретранслятор — три задачи

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

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

На чём падает каждая зависимость

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

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

Спросите, какой сбой вы можете пережить

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

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

Слово децентрализованный заслуживает своего места, когда называет эти сбои. Без этого списка оно описывает диаграмму, а не систему.