Я знаю, я знаю… я говорил, что закончил с серией по IPsec, НО что бы эта серия сказала обо мне, если бы я не автоматизировал всё??
В последних нескольких постах мы рассмотрели работу через CLI: классическая база, PPK, гибрид ML-KEM, сертификаты ML-DSA, атомарное переключение. Именно так вы ИЗУЧАЕТЕ платформу. Но это не то, как вы УПРАВЛЯЕТЕ сетью.
И если вы уже некоторое время следите за моим блогом, вы уже знаете, какой будет следующий шаг. В этом и заключалась цель с самого начала: дать сообществу инструменты программируемости, чтобы вы могли перестать печатать команды на устройствах и начать управлять ими через API. YANG, NETCONF, RESTCONF, Ansible: годы этой работы. Автоматизация на основе API была одной из главных целей. Давайте теперь используем эти навыки для настройки постквантового IPsec!
Введите один и тот же профиль IKEv2 на трех устройствах, измените два адреса, и вы получите два маршрутизатора, которые «договорились», и один, который — нет. Вы узнаете об этом только через неделю. Постквантовая конфигурация — это решение: ML-KEM-768, опционально или обязательно, ML-DSA-65. Вы хотите задать это один раз, применить и доказать, что активная SA действительно это использовала. ГОТОВО.
Этот пост посвящен именно этому уровню. Тот же стенд, те же RFC, те же два столпа. Интерфейс — Ansible поверх NETCONF вместо трех консолей.
Все документы и плейбуки Ansible доступны в моем GitHub для вашего собственного тестирования, но если у вас нет трех маршрутизаторов в лаборатории, вы все равно можете следить за материалом. Вы не сможете повторять действия, если у вас нет оборудования. Вы увидите плейбуки, которые мы запускали, XML, который был реально применен, и вывод команд show, который мы получили в ответ.
Почему это стоит автоматизировать
Вернитесь к топологии «звезда» (hub-and-spoke) из части 9. Хабу нужен один профиль IKEv2 на каждый спик. Каждому спику нужен один профиль в сторону хаба. Предложение (proposal), набор преобразований (transform set), туннель, MTU фрагментации: одни и те же строки, изменены только два адреса.
Затем добавьте PQC, и цена опечатки возрастет. Забудьте «pqc mlkem768 optional» на одном спике, и этот туннель останется классическим, в то время как остальные станут гибридными. Забудьте про фрагментацию, и рукопожатие никогда не завершится. Измените аутентификацию на одном конце пары, и, как показала часть 11, туннель умрет, пока другой конец не последует за ним.
Автоматизация — это не про экономию нажатий клавиш. Это про то, чтобы задать конфигурацию в одном месте и не двигаться дальше, пока устройство не подтвердит её.
Автоматизация — это не про экономию нажатий клавиш. Это про то, чтобы задать конфигурацию в одном месте и не двигаться дальше, пока устройство не подтвердит её.
Конфигурация моделируется. Действия — нет.
Вот ключевой факт об IOS XE 26.2, который определяет всё нижесказанное.
Постквантовая конфигурация — это настоящий YANG. Не CLI-строки, отправленные по более «модному» каналу. Именованные узлы (leaves), типизированные, проверяемые при редактировании. Если вы уже работали с моделью Cisco IOS XE, это те же навыки. Имена узлов новые (например, mlkem768 или mldsa-sig). Паттерн тот же: прочитать модель, отправить структурированные данные, проверить, что вернулось.
Чего YANG не будет делать, так это просить устройство что-то выполнить. В Cisco-IOS-XE-crypto.yang ноль операторов rpc. Поэтому такие команды все еще идут через CLI:
- crypto key generate mldsa
- crypto pki enroll
- clear crypto ikev2 sa
«Это предложение должно предлагать ML-KEM-768» — это выразимо. «Пересогласовать сейчас» — нет. И вам нужно и то, и другое, потому что изменение предложения не затрагивает уже поднятую SA. Отправьте ML-KEM, прочитайте операционные данные, увидите отсутствие PQC, и вы решите, что функция сломана, хотя она просто не пересогласовалась.
Это весь дизайн в одном абзаце. Желаемое состояние через NETCONF. Несколько действий через CLI, отмеченные как «аварийные выходы», а не скрытые.
Четыре плейбука, одна и та же последовательность
Три маршрутизатора в топологии «звезда». Один плейбук на устройство. Каждое устройство удаляет свою конфигурацию с помощью -e state=absent. Каждое применение завершается отчетом о полученном состоянии.
PPK и ML-KEM — это альтернативы, а не шаги. То же правило, что и в части 9: мы никогда не используем их вместе. ML-DSA ортогонален. Он меняет способ подтверждения личности и не заботится о том, выбрали ли вы PPK, ML-KEM или ничего из этого для обмена ключами.
Сама конфигурация живет в одном файле, «pqc.yml». Две строки определяют IPsec-часть лаборатории:
Измените значение, перезапустите, и каждое предложение в сети обновится. Вам никогда не придется открывать XML-шаблон.
Перед всем этим «bootstrap.yml» включает NETCONF. Он все еще работает через SSH CLI, потому что вы не можете настроить транспорт поверх самого транспорта. 🙂 Первый запуск ждет подсистему (на этих устройствах чуть больше двух минут). Второй запуск сравнивает с текущей конфигурацией, ничего не отправляет и сообщает changed=false.
ML-KEM — это два узла
«ipsec-pq-mlkem.yml» добавляет два узла YANG к существующему предложению и больше ничего. Полезная нагрузка, которая попадает на устройство, выглядит так:
Набор параметров — это имя элемента, а не значение. mlkem512, mlkem768 и mlkem1024 — это дочерние узлы типа empty. Вот почему pq_key_exchange должен быть написан так, как того требует схема.
В CLI хаба вся единица — это всего одна строка:
Затем роль очищает IKEv2 SA (это тот самый аварийный выход CLI), чтобы следующее согласование действительно использовало новое предложение.
PLAY RECAP из реального применения, три маршрутизатора параллельно:
И доказательство, с R2 (хаб), оба туннеля:
Это не «редактирование вернуло <ok/>». Это активная SA, говорящая вам, что она согласовала ML-KEM-768. В операционном YANG даже есть узел для этого: «pqc-group = pqc-gt-mlkem768».
Нельзя использовать PPK вместе с ML-KEM
В части 9 мы настроили PPK, затем удалили PPK, затем включили ML-KEM. Автоматизация кодирует это как жесткую остановку.
Запустите «ipsec-pq-mlkem.yml», пока PPK все еще настроен, и ничего не изменится:
То же самое в обратную сторону: ipsec-pq-ppk.yml проверяет наличие ML-KEM и прерывается, если находит его. Ни одна роль не удаляет другую автоматически.
ML-DSA по одному маршрутизатору за раз
Смена аутентификации заменяет метод, а не добавляет к нему. Между моментом переключения одного конца и последующим переключением другого узлы не согласны друг с другом, и туннель законно лежит. Параллельный запуск оставил бы сеть наполовину мигрировавшей. Переключение r2, затем r1, затем r3 сохраняет это окно только для одной пары узлов.
Вот почему первое применение занимает около десяти минут, а не потому, что Ansible медленный. Каждый маршрутизатор генерирует свой собственный ключ ML-DSA на устройстве, создает CSR, узел управления подписывает его, сертификат возвращается, затем профиль переключается. Пока хаб переключился, а спик еще нет, пинги оверлея не проходят и повторяются. Эти красные строки FAILED - RETRYING являются преднамеренными и не критичными. failed=0 в PLAY RECAP — это то, что важно.
Чистая сборка с нуля, три маршрутизатора:
Второй запуск намного быстрее: CA и выданные сертификаты уже существуют, поэтому большинство задач сообщают changed=0.
Одно отличие от части 10 стоит прояснить. В ручном прохождении через CLI импортировался пакет PKCS#12, созданный полностью на рабочей станции (включая закрытый ключ). Плейбук делает наоборот: маршрутизатор генерирует ключ, только CSR покидает устройство, только сертификат возвращается. Тот же внешний CA OpenSSL 3.5+, та же цепочка ML-DSA-65. Закрытый ключ идентификации никогда не оказывается на ноутбуке.
После того как цикл прошел полностью:
Хаб, два туннеля, оба ML-DSA. Операционный YANG не может сообщить об этом: typedef crypto-auth-method не содержит значения ML-DSA. Так что это единственный законный случай парсинга вывода (screen-scrape) на пути чтения IPsec. Все остальное, связанное с постквантовыми технологиями, возвращается в виде листового узла (leaf).
И мы проверяем Auth sign в каждой строке SA, на каждом маршрутизаторе, а не Auth verify. В части 11 уже было показано почему: в процессе миграции поле Auth verify инициатора не является надежным. Споук может выводить Auth verify: MLDSA, в то время как хаб все еще подписывает PSK. Каждое устройство подтверждает только то направление, за которое оно отвечает.
Ответ <ok/> — это не доказательство
Это главная мысль, которую стоит вынести из всего этого уровня.
Успешное выполнение NETCONF edit означает, что полезная нагрузка была проанализирована. Это не означает, что функция работает. Это не означает, что SA была пересогласована. Это не означает, что сертификат, который маршрутизатор только что импортировал, — это тот самый сертификат, который использует профиль.
Поэтому каждое устройство выполняет проверку после своей настройки:
Вы можете выполнить повторную проверку позже, не применяя настройки заново:
Передайте оба флага, как только весь стек будет запущен, и у вас появится CI-проверка: завершайте задание с ошибкой, если активные SA не являются гибридными и не используют ML-DSA.
Что мы сделали
Те же три устройства, больше никакого ввода через CLI. Состояние системы хранится в одном файле. PPK и ML-KEM не могут быть объединены. ML-DSA разворачивается по одному пиру за раз, потому что этого требует протокол. И проверка, которая действительно важна, — это не «ответил ли NETCONF <ok/>», а PQC Key Exchange: ML-KEM-768 и Auth sign: MLDSA на активной SA.
Вы начали Часть 1 с вопроса: готова ли ваша VPN к квантовой эре? Теперь вы можете ответить на него, на ноутбуке и на маршрутизаторе Cisco, вручную и с помощью кода. Задача DevNet заключалась в том, чтобы расширить возможности этого сообщества в области программируемости, где автоматизация на основе API является одной из главных целей. Вот эта работа, запущенная на работающем квантово-устойчивом туннеле.
От «docker compose up» до «show crypto ikev2 sa» и «ansible-playbook ipsec-pq-mlkem.yml». Заголовки о том, что квантовые компьютеры взломают интернет, перестают пугать, как только вы увидите, как поднимается туннель, и этот эффект сохраняется, когда вы можете поднять следующую сотню таким же образом.
Вперед, автоматизируйте свои PQC-развертывания!
