ike-scan не получает ответа от работающего шлюза IPsec
Отсутствие ответа от хостов обычно означает несовпадение предложения, а не отсутствие VPN. Прочитайте набор преобразований по умолчанию, предложите современный и осторожно интерпретируйте молчание.
Шлюз каждый день обслуживает телефоны и ноутбуки, но ike-scan сообщает, что ни один хост не ответил. Этот вывод читается как доказательство того, что в устройстве нет IPsec. Обычно это означает, что устройство отбросило каждое предложение в пробе и решило ничего не отвечать. Молчание тоже ответ, и это наименее информативный ответ, который инструмент может вам дать.
Разберите три отдельных вопроса: дошёл ли пакет, совпало ли какое-либо предложение и не отказал ли в чём-то ещё партнёр?
Шаг 1: прочитайте предложение, которое отправляет инструмент
Основной режим начинается с полезной нагрузки SA, в которой перечислены преобразования, которые примет инициатор, и ike-scan заполняет этот список из скомпилированного значения по умолчанию. Набор по умолчанию намеренно старый: DES и 3DES для шифрования, MD5 и SHA1 для хеширования, группы 1 и 2 для обмена ключами, предварительно разделённые ключи для аутентификации. Ни AES, ни SHA-2, ни группы 14. Шлюз, настроенный на AES-256 с SHA-256 и modp2048, ничего с ним не разделяет.
Некоторые реализации отвечают на несовпадающую пробу уведомлением NO-PROPOSAL-CHOSEN. Другие просто отбрасывают её, что обычно для устройств, считающих неизвестных партнёров шумом. В любом случае сканирование ничего не печатает, и это ничто идентично тому, как выглядит снаружи отфильтрованный UDP 500, как документация проекта ike-scan разъясняет насчёт набора по умолчанию.
Шаг 2: предложите одно современное предложение
Замените набор по умолчанию на --trans. Форма атрибутов принимает номера атрибутов IKE напрямую: 1 для шифрования, 2 для хеша, 3 для аутентификации, 4 для группы и 14 для длины ключа, когда алгоритм её принимает. На выходе получается строка, которую можно прочитать вслух на обзоре изменений.
Позиционная форма несёт те же значения по порядку и избегает скобок, что важно, когда команда проходит через оболочку.
ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10
Одно предложение на пакет медленно при перечислении, поэтому перебирайте правдоподобные значения: шифрование 5, 7/128, 7/192, 7/256; хеш 1, 2, 5, 6, 7; группы 1, 2, 5, 14, 15, 19, 20, 21; аутентификация 1 для предварительно разделённого ключа и 3 для подписей RSA. Печатайте каждую команду перед запуском, чтобы расшифровка показывала, что было предложено и в каком порядке.
Шаг 3: истолкуйте ответ
Ответ доказывает ровно две вещи: IKE-ответчик доступен по этому адресу и одно предложенное предложение было приемлемым. Он ничего не говорит о предварительно разделённом ключе, уровне L2TP или о том, существует ли учётная запись пользователя. Успешное сканирование полностью совместимо с провалом каждого последующего этапа.
На шлюзе, которым вы управляете, это действительно полезная часть. Сканирование сообщает, какие предложения устройство ещё принимает, а результат, ограниченный устаревшими преобразованиями, — это находка о политике устройства, а не повод ослаблять клиента.
Шаг 4: истолкуйте молчание
Молчание — более слабое доказательство, чем кажется. Каждое предложение могло быть отклонено, UDP 500 и 4500 могли быть отфильтрованы, источник мог быть ограничен по скорости после всплеска, или служба может слушать другой адрес, не тот, который вы сканировали. Сравните журнал IKE шлюза с клиентом, который уже подключается с действительными учётными данными, прежде чем делать выводы об этом устройстве.
Поведение при всплеске входит в этот список, потому что перечисление порождает много пакетов за короткое окно. Шлюз, который отвечает на первые попытки, а затем замолкает, описывает свою политику anti-DoS, а не набор предложений.
Шаг 5: запишите, что вы доказали
Запишите принятую комбинацию рядом с версией прошивки, затем сравните её с преобразованиями, которые клиенты, важные для вас, предлагают по умолчанию. Разрыв между этими двумя списками и есть проблема конфигурации, а сканирование лишь сделало её видимой. Если единственные принимаемые предложения — те, которые вы бы не выбрали, исправление относится к политике шлюза или профилю клиента, но никогда к пробе.
Проба, которая так и не ответила, всё равно кое-что ответила: она показывает, какие предложения это устройство готово обсуждать, а какие предпочло бы уронить на пол.