Как спланировать адресное пространство для VPN с несколькими площадками

Каким должен быть размер подсети VPN, ответа нет, пока не названо, какие адреса вы считаете. В одном проекте это два конца нумерованного туннельного канала, в другом — локальная сеть офиса за туннелем на основе политик, в третьем — резервируемая инфраструктура управляемого шлюза. Три объекта, три бюджета, и большинство ошибок в размерах возникает из-за заполнения одного столбца числом из другого.

Четыре роли, четыре разных вопроса

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

Только третий из них связан с тем, сколько ноутбуков находится в офисе. Именно это единственное смешение объясняет большинство споров.

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

Подсчёт блоков: сколько на самом деле стоит /30

Канал точка-точка требует двух адресов и расходует блок, размер которого зависит от платформы. /30 содержит четыре адреса, из которых два обычно пригодны для использования, поэтому двенадцать каналов расходуют в плане сорок восемь адресов, предлагая двадцать четыре оконечные точки. /31 содержит два адреса, и оба пригодны, что вдвое сокращает арифметику, но только там, где оба конца это принимают.

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

ipcalc -n 10.44.12.0/30
ipcalc -n 10.44.12.4/31

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

Подсеть управляемого шлюза — не пул клиентов

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

Читайте требование провайдера как фиксированные затраты, так же как вы отнеслись бы к единице стойки. Оно не входит в бюджет защищённого префикса.

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

Задокументируйте план, чтобы он пережил вторую площадку

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

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

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