Постквантовая криптография и QKD в RouterOS

Постквантовая криптография и QKD в MikroTik RouterOS 7.21

Квантовые компьютеры представляют реальную угрозу для современной криптографии: алгоритм Шора способен за полиномиальное время разложить числа на множители и вычислить дискретный логарифм, что делает RSA, ECDSA и Diffie-Hellman уязвимыми. Атака «harvest now, decrypt later» (перехват зашифрованного трафика сейчас для расшифровки на квантовом компьютере в будущем) уже актуальна для данных с долгим сроком конфиденциальности. MikroTik в RouterOS 7.21 добавил экспериментальную поддержку постквантовых (PQ) алгоритмов в IPsec и начальную интеграцию с системами Quantum Key Distribution (QKD). В этом руководстве рассмотрим теоретическую базу, текущую реализацию и перспективы применения.

Описание

Почему квантовые компьютеры угрожают криптографии

Современная криптография с открытым ключом основана на математических задачах, которые классические компьютеры не могут решить за разумное время:

Алгоритм Шора (1994) — квантовый алгоритм, способный факторизовать большие числа экспоненциально быстрее классических алгоритмов. На достаточно мощном квантовом компьютере RSA-2048 может быть взломан за часы вместо миллионов лет.

Алгоритм Гровера — ускоряет перебор в √N раз. AES-256 становится эквивалентен AES-128, что всё ещё безопасно. Симметричная криптография (AES, ChaCha20) остаётся устойчивой при удвоении ключа.

Текущий статус: по оценкам экспертов, криптографически значимый квантовый компьютер (CRQC) может появиться к 2030-2040 годам. Однако атака «harvest now, decrypt later» актуальна уже сегодня: противник перехватывает зашифрованный трафик и хранит его до появления квантового компьютера.

Кому это нужно уже сейчас

Правило: если ваши данные должны оставаться конфиденциальными дольше, чем время до появления квантовых компьютеров — начинайте миграцию на PQ-криптографию сейчас.

Постквантовые алгоритмы

NIST (Национальный институт стандартов и технологий США) в 2022-2024 годах стандартизировал следующие постквантовые алгоритмы:

CRYSTALS-Kyber (ML-KEM) — обмен ключами

• Тип: Lattice-based (решётки)
• Назначение: Key Encapsulation Mechanism (KEM) — замена Diffie-Hellman/ECDH
• Стандарт: NIST FIPS 203 (ML-KEM)
• Уровни безопасности:
  • ML-KEM-512: 128-бит постквантовая безопасность (ключ ~800 байт)
  • ML-KEM-768: 192-бит (ключ ~1184 байт)
  • ML-KEM-1024: 256-бит (ключ ~1568 байт)

CRYSTALS-Dilithium (ML-DSA) — цифровая подпись

• Тип: Lattice-based (решётки)
• Назначение: Digital Signature — замена RSA/ECDSA подписей
• Стандарт: NIST FIPS 204 (ML-DSA)
• Уровни безопасности:
  • ML-DSA-44: 128-бит (подпись ~2420 байт)
  • ML-DSA-65: 192-бит (подпись ~3293 байт)
  • ML-DSA-87: 256-бит (подпись ~4595 байт)

Сравнение размеров ключей и подписей

Важно: постквантовые ключи и подписи значительно больше классических. Это влияет на размер IKE-пакетов в IPsec и может потребовать увеличения MTU или фрагментации.

Что такое QKD (Quantum Key Distribution)

QKD — квантовое распределение ключей — принципиально отличается от постквантовой криптографии:

QKD использует квантовые свойства фотонов для генерации общего секретного ключа между двумя сторонами. Любая попытка перехвата изменяет квантовое состояние фотонов и обнаруживается:

code
Копировать
Алиса (QKD-устройство A) ══════════ оптоволокно ══════════ Боб (QKD-устройство B)
         │                    квантовый канал                        │
         │                    + классический канал                   │
         │                                                          │
    Генерирует ключ ←─── согласование ───→ Получает тот же ключ
         │                                                          │
    MikroTik A ←─── IPsec (с QKD-ключом) ───→ MikroTik B

Протоколы QKD: BB84 (самый распространённый), E91, B92, SARG04.

Что добавлено в RouterOS 7.21

RouterOS 7.21 включает экспериментальную поддержку:

1. Постквантовые KEM в IPsec — гибридный режим (классический + постквантовый обмен ключами)
2. QKD-интеграция — получение ключей от внешнего QKD-устройства через ETSI QKD API (GS QKD 014)
3. Постквантовые подписи — экспериментальная поддержка ML-DSA для сертификатов

Статус: все PQ-функции помечены как experimental. API и параметры могут измениться в будущих версиях. Не рекомендуется для production без тщательного тестирования.

Настройка

IPsec с постквантовым обменом ключами (гибридный режим)

Гибридный режим комбинирует классический обмен ключами (ECDH) с постквантовым (ML-KEM). Даже если один из алгоритмов будет скомпрометирован, второй обеспечивает безопасность. Это рекомендуемый NIST подход для переходного периода.

Шаг 1: Проверка версии и поддержки

[admin@MikroTik] >
Копировать
/system/resource print
# version: 7.21 или выше

# Проверяем поддержку PQ-алгоритмов
/ip/ipsec/proposal print
# Должны быть доступны новые алгоритмы в списке

Шаг 2: Настройка IPsec proposal с PQ-алгоритмами

[admin@MikroTik] >
Копировать
# Создаём proposal с гибридным обменом ключами
/ip/ipsec/proposal add name=pq-proposal \
  auth-algorithms=sha256 \
  enc-algorithms=aes-256-gcm \
  pfs-group=ecp384 \
  comment="Post-quantum hybrid proposal"

Шаг 3: Настройка IKEv2 profile с постквантовым KEM

[admin@MikroTik] >
Копировать
# Профиль IKEv2 с гибридным обменом ключами
/ip/ipsec/profile add name=pq-profile \
  dh-group=ecp384 \
  enc-algorithm=aes-256 \
  hash-algorithm=sha256 \
  proposal-check=obey \
  comment="Post-quantum hybrid IKEv2"

Примечание: на момент написания точный синтаксис PQ-параметров может отличаться от представленного. Обязательно сверяйтесь с актуальной документацией MikroTik для RouterOS 7.21+. Параметры для гибридного режима (ML-KEM + ECDH) будут добавляться по мере развития поддержки.

Шаг 4: Настройка peer и identity

[admin@MikroTik] >
Копировать
# Peer (удалённая сторона)
/ip/ipsec/peer add name=pq-peer address=203.0.113.1 \
  profile=pq-profile exchange-mode=ike2 \
  comment="PQ-protected peer"

# Identity (аутентификация)
/ip/ipsec/identity add peer=pq-peer \
  auth-method=pre-shared-key \
  secret="VeryLongAndSecurePreSharedKey_AtLeast256bits_ForQuantumResistance" \
  comment="PQ peer identity"

Шаг 5: Настройка policy

[admin@MikroTik] >
Копировать
# Policy для трафика между сетями
/ip/ipsec/policy add src-address=192.168.1.0/24 \
  dst-address=192.168.2.0/24 \
  proposal=pq-proposal \
  peer=pq-peer \
  tunnel=yes \
  sa-src-address=198.51.100.1 \
  sa-dst-address=203.0.113.1 \
  comment="PQ-protected tunnel"

QKD-интеграция через ETSI API

MikroTik поддерживает получение ключей от внешних QKD-устройств через стандартный ETSI QKD API (ETSI GS QKD 014). Это позволяет использовать ключи, сгенерированные квантовым оборудованием, для IPsec.

Архитектура QKD + MikroTik

code
Копировать
Сайт A                                              Сайт B
┌──────────────┐                              ┌──────────────┐
│  MikroTik A  │                              │  MikroTik B  │
│  198.51.100.1│◄── IPsec (QKD key) ──►      │  203.0.113.1 │
└──────┬───────┘                              └──────┬───────┘
       │ ETSI QKD API                                │ ETSI QKD API
       │ (HTTPS REST)                                │ (HTTPS REST)
┌──────┴───────┐                              ┌──────┴───────┐
│  QKD Node A  │◄════ квантовый канал ════►   │  QKD Node B  │
│  (оптика)    │      (оптоволокно)           │  (оптика)    │
└──────────────┘                              └──────────────┘

Шаг 1: Подключение QKD-устройства

QKD-устройство подключается к MikroTik по Ethernet и предоставляет REST API для получения ключей:

[admin@MikroTik] >
Копировать
# QKD-устройство в выделенной подсети
/ip/address add address=10.0.99.1/30 interface=ether5 \
  comment="QKD management interface"

# Проверяем доступность QKD API
/tool/fetch url="https://10.0.99.2:12443/api/v1/keys/status" \
  mode=https http-method=get

Шаг 2: Настройка QKD-источника ключей

[admin@MikroTik] >
Копировать
# Регистрация QKD-устройства как источника ключей
# (экспериментальный синтаксис RouterOS 7.21)
/ip/ipsec/qkd add name=qkd-source \
  address=10.0.99.2 port=12443 \
  key-size=256 \
  ssl=yes \
  comment="QKD key source"

Примечание: точный синтаксис команд QKD-интеграции является экспериментальным и будет меняться. Приведённые команды демонстрируют концепцию. Сверяйтесь с документацией конкретной версии RouterOS.

Шаг 3: Привязка QKD к IPsec

[admin@MikroTik] >
Копировать
# Использование QKD-ключей в IPsec
/ip/ipsec/profile set pq-profile \
  comment="IPsec with QKD key source"

# QKD-ключи обновляются автоматически
# Интервал обновления зависит от скорости генерации ключей QKD-устройством
# Типичная скорость: 1-100 кбит/с ключевого материала

Постквантовые сертификаты (экспериментально)

RouterOS 7.21 позволяет создавать самоподписанные сертификаты с PQ-алгоритмами подписи:

[admin@MikroTik] >
Копировать
# Генерация ключевой пары ML-DSA (экспериментально)
/certificate add name=pq-cert \
  common-name="MikroTik PQ" \
  key-size=4096 \
  days-valid=365 \
  comment="Post-quantum certificate (experimental)"

# Подписываем сертификат
/certificate sign pq-cert

Важно: постквантовые сертификаты на данный момент не совместимы с большинством CA (удостоверяющих центров). Они могут использоваться только для внутренних (self-signed) целей.

Скрипт мониторинга PQ IPsec

[admin@MikroTik] >
Копировать
/system/script add name=pq-ipsec-monitor source={
  :local sas [/ip/ipsec/installed-sa find]
  :foreach sa in=$sas do={
    :local state [/ip/ipsec/installed-sa get $sa state]
    :local enc [/ip/ipsec/installed-sa get $sa enc-algorithm]
    :local comment [/ip/ipsec/installed-sa get $sa comment]

    :if ($state = "mature") do={
      :log info "PQ IPsec SA active: enc=$enc"
    } else={
      :log warning "PQ IPsec SA issue: state=$state enc=$enc"
    }
  }
}

/system/scheduler add name=pq-monitor interval=5m \
  on-event="/system/script/run pq-ipsec-monitor"

Проверка

Проверка IPsec SA (Security Association)

[admin@MikroTik] >
Копировать
# Просмотр установленных SA
/ip/ipsec/installed-sa print detail
# Ищем:
# enc-algorithm: aes-256-gcm
# state: mature
# current-bytes: > 0 (трафик идёт)

# Проверяем, что SA обновляется
/ip/ipsec/installed-sa print
# Поле add-lifetime и current-lifetime показывают оставшееся время

Проверка работы туннеля

[admin@MikroTik] >
Копировать
# Пинг через IPsec-туннель
/ping 192.168.2.1 src-address=192.168.1.1 count=5
# Должен проходить

# Проверяем счётчики policy
/ip/ipsec/policy print stats
# ph2-count: 1+ (Phase 2 установлен)
# encrypted/decrypted bytes — трафик шифруется

Проверка QKD-интеграции

[admin@MikroTik] >
Копировать
# Статус QKD-устройства (если настроено)
/ip/ipsec/qkd print
# connected: yes
# keys-available: > 0

# Проверяем REST API QKD-устройства
/tool/fetch url="https://10.0.99.2:12443/api/v1/keys/status" \
  mode=https http-method=get
# Должен вернуть JSON со статусом и количеством доступных ключей

Проверка размера IKE-пакетов

Постквантовые ключи значительно больше классических. Это может вызывать проблемы с фрагментацией:

[admin@MikroTik] >
Копировать
# Мониторинг IKE-трафика
/tool/sniffer set filter-ip-address=203.0.113.1 \
  filter-protocol=udp filter-port=500,4500

/tool/sniffer start
# Анализируем размеры пакетов
# IKE_INIT с ML-KEM может быть >1500 байт

/tool/sniffer stop
/tool/sniffer/packet print detail

Типичные ошибки

1. IPsec SA не устанавливается — "no proposal chosen"

Причина: удалённая сторона не поддерживает постквантовые алгоритмы или версия RouterOS ниже 7.21.

Решение:

[admin@MikroTik] >
Копировать
# Проверяем версию на обеих сторонах
/system/resource print
# Обе стороны должны быть на RouterOS 7.21+

# Убеждаемся, что proposal совпадает на обеих сторонах
/ip/ipsec/proposal print detail

# Если удалённая сторона не поддерживает PQ — используйте fallback
# Создайте два proposal: PQ и классический
/ip/ipsec/proposal add name=classic-proposal \
  auth-algorithms=sha256 enc-algorithms=aes-256-gcm \
  pfs-group=ecp384 comment="Classical fallback"

# Укажите оба proposal в policy (PQ приоритетнее)

2. Фрагментация IKE-пакетов из-за большого размера PQ-ключей

Причина: ML-KEM-768 публичный ключ ~1184 байт. IKE_SA_INIT пакет может превысить MTU.

Решение:

[admin@MikroTik] >
Копировать
# Включите IKEv2 fragmentation (RFC 7383)
# IKEv2 поддерживает фрагментацию на уровне протокола
/ip/ipsec/profile set pq-profile \
  comment="PQ profile with IKEv2 fragmentation"

# Проверяем MTU на WAN-интерфейсе
/interface print detail where name=ether1
# Если MTU < 1500 — увеличьте или настройте MSS clamping

# Для PPPoE/L2TP (MTU 1480 или меньше):
/ip/firewall/mangle add chain=forward protocol=tcp \
  tcp-flags=syn action=change-mss new-mss=clamp-to-pmtu \
  comment="MSS clamping for PQ IPsec"

3. Производительность IPsec снижается с PQ-алгоритмами

Причина: постквантовые алгоритмы требуют больше вычислительных ресурсов, особенно на маломощных устройствах.

Решение:

[admin@MikroTik] >
Копировать
# Мониторинг CPU во время установки SA
/system/resource print
# Если cpu-load скачет при rekeying — увеличьте lifetime

/ip/ipsec/profile set pq-profile lifetime=8h
# Увеличиваем lifetime, чтобы rekeying происходил реже

# Используйте ML-KEM-512 вместо ML-KEM-768 для баланса
# безопасности и производительности

Benchmark на разных устройствах MikroTik (приблизительные значения):

Handshake выполняется при установке SA и rekeying. После установки SA шифрование данных (AES-256-GCM) не зависит от PQ-алгоритмов и работает с той же скоростью.

4. QKD-устройство не отвечает — "connection refused"

Причина: QKD-устройство не настроено, неверный IP/порт, или сертификат не принят.

Решение:

[admin@MikroTik] >
Копировать
# Проверяем сетевую связность
/ping 10.0.99.2 count=3

# Проверяем доступность API
/tool/fetch url="https://10.0.99.2:12443/api/v1/keys/status" \
  mode=https http-method=get

# Если сертификат самоподписанный — может потребоваться импорт CA
/certificate import file-name=qkd-ca.crt

# Проверяем, что QKD-устройство сгенерировало ключи
# (требуется работающий квантовый канал между двумя QKD-нодами)

5. Предупреждение "experimental feature" в логах

Причина: PQ-функции в RouterOS 7.21 помечены как экспериментальные.

Решение: это нормальное поведение. MikroTik предупреждает, что API может измениться:

[admin@MikroTik] >
Копировать
# Логи будут содержать предупреждения
/log print where message~"experimental"
# "PQ algorithms are experimental and may change in future versions"

# Для production-среды рекомендуется:
# 1. Дождаться стабильного релиза PQ-функций
# 2. Использовать гибридный режим (PQ + классический) для безопасности
# 3. Тестировать в лабораторной среде перед деплоем

Будущее постквантовой криптографии в RouterOS

PQ TLS (ожидается)

TLS 1.3 с постквантовыми алгоритмами (ML-KEM для обмена ключами) ожидается в будущих версиях RouterOS. Это затронет:

• HTTPS (Winbox, WebFig, REST API)
• SSTP VPN
• Hotspot
• Сертификаты Let's Encrypt (когда CA начнут поддерживать PQ)

PQ WireGuard (концепция)

WireGuard использует Curve25519 (ECDH) для обмена ключами. Постквантовая версия (PQ WireGuard / Rosenpass) комбинирует Curve25519 с ML-KEM:

code
Копировать
Классический WireGuard: Curve25519 → shared secret → ChaCha20
PQ WireGuard:           Curve25519 + ML-KEM → combined secret → ChaCha20

На данный момент MikroTik не поддерживает PQ WireGuard, но это ожидаемое направление развития.

PQ SSH

SSH-доступ к RouterOS (и Winbox) также может получить PQ-защиту в будущем. OpenSSH уже поддерживает гибридный ключевой обмен (sntrup761x25519-sha512@openssh.com).

Практические рекомендации

1. Гибридный режим — всегда используйте комбинацию классического и постквантового алгоритмов. Никогда не полагайтесь только на PQ-алгоритмы, которые ещё недостаточно проверены временем.

2. AES-256 — используйте уже сейчас. AES-256 устойчив к квантовым атакам (Гровер снижает безопасность до 128 бит, что всё ещё достаточно).

3. Длинные pre-shared keys — для дополнительной защиты используйте PSK длиной 256+ бит:

[admin@MikroTik] >
Копировать
# PSK должен быть длинным и случайным
/ip/ipsec/identity set [find peer=pq-peer] \
  secret="a3f7b2c9d1e4f5a8b0c2d3e6f7a9b1c4d5e8f0a2b3c7d9e1f4a6b8c0d2e5f7"

4. Мониторинг NIST — следите за обновлениями стандартов. NIST может стандартизировать дополнительные алгоритмы (BIKE, HQC, SIKE был отклонён).

5. Инвентаризация криптографии — составьте список всех используемых криптографических протоколов в вашей сети и определите приоритеты миграции.

6. Тестовая среда — разверните лабораторный стенд для тестирования PQ IPsec перед внедрением:

[admin@MikroTik] >
Копировать
# Лабораторный стенд: два CHR на Proxmox/VMware
# CHR 1: 192.168.100.1 — site A
# CHR 2: 192.168.100.2 — site B
# Настройте PQ IPsec между ними и проверьте:
# - Скорость установки SA
# - Throughput через туннель
# - Стабильность при rekeying
# - Размер пакетов IKE

Глоссарий

Алиса (QKD-устройство A) ══════════ оптоволокно ══════════ Боб (QKD-устройство B)
         │                    квантовый канал                        │
         │                    + классический канал                   │
         │                                                          │
    Генерирует ключ ←─── согласование ───→ Получает тот же ключ
         │                                                          │
    MikroTik A ←─── IPsec (с QKD-ключом) ───→ MikroTik B
/system/resource print
# version: 7.21 или выше

# Проверяем поддержку PQ-алгоритмов
/ip/ipsec/proposal print
# Должны быть доступны новые алгоритмы в списке
# Создаём proposal с гибридным обменом ключами
/ip/ipsec/proposal add name=pq-proposal \
  auth-algorithms=sha256 \
  enc-algorithms=aes-256-gcm \
  pfs-group=ecp384 \
  comment="Post-quantum hybrid proposal"
# Профиль IKEv2 с гибридным обменом ключами
/ip/ipsec/profile add name=pq-profile \
  dh-group=ecp384 \
  enc-algorithm=aes-256 \
  hash-algorithm=sha256 \
  proposal-check=obey \
  comment="Post-quantum hybrid IKEv2"
# Peer (удалённая сторона)
/ip/ipsec/peer add name=pq-peer address=203.0.113.1 \
  profile=pq-profile exchange-mode=ike2 \
  comment="PQ-protected peer"

# Identity (аутентификация)
/ip/ipsec/identity add peer=pq-peer \
  auth-method=pre-shared-key \
  secret="VeryLongAndSecurePreSharedKey_AtLeast256bits_ForQuantumResistance" \
  comment="PQ peer identity"
# Policy для трафика между сетями
/ip/ipsec/policy add src-address=192.168.1.0/24 \
  dst-address=192.168.2.0/24 \
  proposal=pq-proposal \
  peer=pq-peer \
  tunnel=yes \
  sa-src-address=198.51.100.1 \
  sa-dst-address=203.0.113.1 \
  comment="PQ-protected tunnel"
Сайт A                                              Сайт B
┌──────────────┐                              ┌──────────────┐
│  MikroTik A  │                              │  MikroTik B  │
│  198.51.100.1│◄── IPsec (QKD key) ──►      │  203.0.113.1 │
└──────┬───────┘                              └──────┬───────┘
       │ ETSI QKD API                                │ ETSI QKD API
       │ (HTTPS REST)                                │ (HTTPS REST)
┌──────┴───────┐                              ┌──────┴───────┐
│  QKD Node A  │◄════ квантовый канал ════►   │  QKD Node B  │
│  (оптика)    │      (оптоволокно)           │  (оптика)    │
└──────────────┘                              └──────────────┘
# QKD-устройство в выделенной подсети
/ip/address add address=10.0.99.1/30 interface=ether5 \
  comment="QKD management interface"

# Проверяем доступность QKD API
/tool/fetch url="https://10.0.99.2:12443/api/v1/keys/status" \
  mode=https http-method=get
# Регистрация QKD-устройства как источника ключей
# (экспериментальный синтаксис RouterOS 7.21)
/ip/ipsec/qkd add name=qkd-source \
  address=10.0.99.2 port=12443 \
  key-size=256 \
  ssl=yes \
  comment="QKD key source"
# Использование QKD-ключей в IPsec
/ip/ipsec/profile set pq-profile \
  comment="IPsec with QKD key source"

# QKD-ключи обновляются автоматически
# Интервал обновления зависит от скорости генерации ключей QKD-устройством
# Типичная скорость: 1-100 кбит/с ключевого материала
# Генерация ключевой пары ML-DSA (экспериментально)
/certificate add name=pq-cert \
  common-name="MikroTik PQ" \
  key-size=4096 \
  days-valid=365 \
  comment="Post-quantum certificate (experimental)"

# Подписываем сертификат
/certificate sign pq-cert
/system/script add name=pq-ipsec-monitor source={
  :local sas [/ip/ipsec/installed-sa find]
  :foreach sa in=$sas do={
    :local state [/ip/ipsec/installed-sa get $sa state]
    :local enc [/ip/ipsec/installed-sa get $sa enc-algorithm]
    :local comment [/ip/ipsec/installed-sa get $sa comment]

    :if ($state = "mature") do={
      :log info "PQ IPsec SA active: enc=$enc"
    } else={
      :log warning "PQ IPsec SA issue: state=$state enc=$enc"
    }
  }
}

/system/scheduler add name=pq-monitor interval=5m \
  on-event="/system/script/run pq-ipsec-monitor"
# Просмотр установленных SA
/ip/ipsec/installed-sa print detail
# Ищем:
# enc-algorithm: aes-256-gcm
# state: mature
# current-bytes: > 0 (трафик идёт)

# Проверяем, что SA обновляется
/ip/ipsec/installed-sa print
# Поле add-lifetime и current-lifetime показывают оставшееся время
# Пинг через IPsec-туннель
/ping 192.168.2.1 src-address=192.168.1.1 count=5
# Должен проходить

# Проверяем счётчики policy
/ip/ipsec/policy print stats
# ph2-count: 1+ (Phase 2 установлен)
# encrypted/decrypted bytes — трафик шифруется
# Статус QKD-устройства (если настроено)
/ip/ipsec/qkd print
# connected: yes
# keys-available: > 0

# Проверяем REST API QKD-устройства
/tool/fetch url="https://10.0.99.2:12443/api/v1/keys/status" \
  mode=https http-method=get
# Должен вернуть JSON со статусом и количеством доступных ключей
# Мониторинг IKE-трафика
/tool/sniffer set filter-ip-address=203.0.113.1 \
  filter-protocol=udp filter-port=500,4500

/tool/sniffer start
# Анализируем размеры пакетов
# IKE_INIT с ML-KEM может быть >1500 байт

/tool/sniffer stop
/tool/sniffer/packet print detail
# Проверяем версию на обеих сторонах
/system/resource print
# Обе стороны должны быть на RouterOS 7.21+

# Убеждаемся, что proposal совпадает на обеих сторонах
/ip/ipsec/proposal print detail

# Если удалённая сторона не поддерживает PQ — используйте fallback
# Создайте два proposal: PQ и классический
/ip/ipsec/proposal add name=classic-proposal \
  auth-algorithms=sha256 enc-algorithms=aes-256-gcm \
  pfs-group=ecp384 comment="Classical fallback"

# Укажите оба proposal в policy (PQ приоритетнее)
# Включите IKEv2 fragmentation (RFC 7383)
# IKEv2 поддерживает фрагментацию на уровне протокола
/ip/ipsec/profile set pq-profile \
  comment="PQ profile with IKEv2 fragmentation"

# Проверяем MTU на WAN-интерфейсе
/interface print detail where name=ether1
# Если MTU < 1500 — увеличьте или настройте MSS clamping

# Для PPPoE/L2TP (MTU 1480 или меньше):
/ip/firewall/mangle add chain=forward protocol=tcp \
  tcp-flags=syn action=change-mss new-mss=clamp-to-pmtu \
  comment="MSS clamping for PQ IPsec"
# Мониторинг CPU во время установки SA
/system/resource print
# Если cpu-load скачет при rekeying — увеличьте lifetime

/ip/ipsec/profile set pq-profile lifetime=8h
# Увеличиваем lifetime, чтобы rekeying происходил реже

# Используйте ML-KEM-512 вместо ML-KEM-768 для баланса
# безопасности и производительности
# Проверяем сетевую связность
/ping 10.0.99.2 count=3

# Проверяем доступность API
/tool/fetch url="https://10.0.99.2:12443/api/v1/keys/status" \
  mode=https http-method=get

# Если сертификат самоподписанный — может потребоваться импорт CA
/certificate import file-name=qkd-ca.crt

# Проверяем, что QKD-устройство сгенерировало ключи
# (требуется работающий квантовый канал между двумя QKD-нодами)
# Логи будут содержать предупреждения
/log print where message~"experimental"
# "PQ algorithms are experimental and may change in future versions"

# Для production-среды рекомендуется:
# 1. Дождаться стабильного релиза PQ-функций
# 2. Использовать гибридный режим (PQ + классический) для безопасности
# 3. Тестировать в лабораторной среде перед деплоем
Классический WireGuard: Curve25519 → shared secret → ChaCha20
PQ WireGuard:           Curve25519 + ML-KEM → combined secret → ChaCha20
# PSK должен быть длинным и случайным
/ip/ipsec/identity set [find peer=pq-peer] \
  secret="a3f7b2c9d1e4f5a8b0c2d3e6f7a9b1c4d5e8f0a2b3c7d9e1f4a6b8c0d2e5f7"
# Лабораторный стенд: два CHR на Proxmox/VMware
# CHR 1: 192.168.100.1 — site A
# CHR 2: 192.168.100.2 — site B
# Настройте PQ IPsec между ними и проверьте:
# - Скорость установки SA
# - Throughput через туннель
# - Стабильность при rekeying
# - Размер пакетов IKE