Спланируйте подсети до VPN между площадками: перенумеруйте или транслируйте

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

Инвентаризируйте каждый диапазон, включая забытые

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

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

Делайте IPv6 отдельно, потому что его план и его пересечения независимы.

Сравнивайте префиксы, а не знакомые адреса

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

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

Таблицы префиксов с масками достаточно; схемы без масок — нет.

Решите, что действительно должно проходить

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

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

Напишите список доступа до конфигурации туннеля, а не после её отказа.

Перенумеруйте или транслируйте и знайте цену

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

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

Обходной путь без обратного пути — не обходной путь.

Используйте матрицу маршрутов как приёмочный тест

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

Ping между адресами туннеля доказывает, что туннель существует, и ничего о плане адресов за ним.

Храните матрицу вместе с конфигурацией туннеля, и следующее добавление площадки начнётся с данных, а не с памяти. Когда план существует, руководство strongSwan по пересылке покрывает сторону шлюза.