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

Спросите, какого размера должна быть подсеть VPN, и честный ответ будет таким: в вопросе могут скрываться четыре разные подсети. VPN площадки может включать транспортные оконечные точки, нумерованные туннельные каналы, префиксы защищённой локальной сети и, на управляемых шлюзах, инфраструктурную подсеть, которую резервирует провайдер. В конкретном проекте существуют лишь одна-две из них. Рассчитывать их по числу офисных устройств — это путь к плану с /24, который никого не устроит.

Назовите четыре роли, прежде чем что-либо выделять

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

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

ip -br addr show
ip route show | head -40

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

Считайте каналы и топологию, а не устройства

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

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

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

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

Держите подсеть шлюза вне пула локальной сети

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

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

aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table

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

Записывайте роль, владельца и рост для каждого префикса

План, который переживает соприкосновение с эксплуатацией, указывает для каждого префикса, какую роль он играет, кто выделяет дальний конец и сколько запаса у него есть. Без поля владельца две команды выделяют одну и ту же /24 в одном квартале, и столкновение проявляется только при поднятии туннеля.

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

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