Как спланировать пул адресов VPN-клиентов, который подойдёт

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

Начните с поля пула, прежде чем подключится хоть один клиент

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

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

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

Прочитайте адрес, который клиент действительно получил

Подключите одного клиента и читайте то, что сообщает туннель, а не то, что обещал пул. Клиент показывает свой внутренний адрес в состоянии подключения, а в Linux интерфейс несёт его напрямую.

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

ip -4 addr show tun0
ip route get 192.168.50.20

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

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

Проследите ответ обратно от службы

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

Трансляция меняет то, что видит остальная система. Когда источник перезаписывается, адрес в межсетевом экране узла и в журнале приложения — транслированный, поэтому правило, написанное против адреса пула, ни с чем не совпадает, а строку журнала нельзя проследить до клиента. Документация strongSwan по перенаправлению охватывает серверную половину этого пути для шлюза IKEv2. DNS несёт то же ограничение, потому что имя, которое разрешается в адрес, недоступный клиенту, терпит неудачу позже и в другом месте.

Два клиента, затем один отзыв

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

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

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

Запишите эти четыре значения там, где их найдёт следующее изменение

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

Держите при ней заметку о принадлежности: диапазон туннеля принадлежит серверу VPN, а резервирование, сделанное в области DHCP локальной сети ничего не резервирует для клиента внутри туннеля. Эта одна строка предотвращает самую частую переделку, когда кто-то добавляет резервирование и ждёт, что адрес туннеля последует за ним.