Пять ролей адреса в профиле IPsec, и какая из них неверна

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

Пять задач, в порядке их важности

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

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

Решение первое: ничего не устанавливается

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

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

Решение второе: туннель поднят, а трафик умирает

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

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

Решение третье: отказывает только собственный трафик шлюза

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

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

Следующий переход — локальная инструкция

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

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

Читайте профиль с обоих концов

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

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