ike-scan не отримує відповіді від робочого шлюзу IPsec

Шлюз щодня обслуговує телефони й ноутбуки, але 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: запишіть, що ви довели

Запишіть прийняту комбінацію поруч із версією прошивки, потім порівняйте її з перетвореннями, які клієнти, важливі для вас, пропонують типово. Розрив між цими двома списками і є проблемою конфігурації, а сканування лише зробило його видимим. Якщо єдині прийнятні пропозиції — ті, які ви не обрали б, виправлення належить до політики шлюзу або профілю клієнта, ніколи до проби.

Проба, яка так і не відповіла, все ж на щось відповіла: вона показує, які пропозиції цей пристрій готовий обговорювати, а які волів би впустити на підлогу.