Чому IKEv2 на Android не працює на нестандартному порту UDP

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

Шлюз відповідає на IKEv2 на UDP 4443 не випадково, у профілі є поле з назвою Server, ви вводите ім’я хоста й порт, а телефон повідомляє, що не може досягти сервера або не може розв’язати адресу. Нічого не блокується. Штатна форма Android очікує хост, і те саме слушно в Windows. Нестандартний порт — це можливість клієнта, а не налаштування сервера, і виразити її дозволяють лише деякі клієнти. Пройдіть три частини по порядку: що може сказати клієнт, що слухає сервер і чи однаково інкапсулюються пакети на обох кінцях.

Що телефон насправді надіслав

Рядок host:port у полі, призначеному для імені, розв’язується як ім’я. Розв’язувач нічого не повертає для vpn.example.net:4443, і помилка, яку ви бачите, — це збій розв’язання імені або недоступність, а не тайм-аут на порту. Ця різниця важлива, бо повтор із коротшим ім’ям або іншою мережею ніколи не виправить рядок, який форма не може розібрати.

Штатний профіль IKEv2 на Android, як і вбудований клієнт Windows VPN, прив’язаний до стандартних портів IKE. Жоден із них не показує поле порту, і жодне редагування профілю його не додає. Якщо слухач оператора справді на 4443, вбудований клієнт — неправильний інструмент, а не неправильно налаштований.

Використовуйте клієнт, який показує порт

Клієнт strongSwan для Android документує налаштовуваний порт сервера в розширених параметрах профілю, тому він трапляється майже в кожному робочому рецепті для цієї схеми. Ця підтримка належить саме тому клієнту: інший застосунок IKEv2 або форк постачальника того самого застосунку може не показувати те саме поле, хоча базовий демон strongSwan його підтримує.

Попросіть в оператора весь набір одразу: ім’я шлюзу, порт UDP, метод автентифікації та ідентичність сервера, якої має очікувати клієнт. Нестандартний порт — не привід вимикати перевірку сертифікатів або змінювати протоколи. Введіть порт там, де його очікує встановлений клієнт, і якщо в цього клієнта немає такого поля, відповідь — інший дозволений клієнт, а не вигаданий обхід.

У сервера два порти, і обидва мають збігатися

IKE починається на UDP 500, а проходження NAT зазвичай переносить IKE та інкапсульований ESP на UDP 4500. У strongSwan це окремі налаштування, тому сервер, перенесений на один нестандартний порт, має змінити обидва на однакове значення:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

Коли один порт обслуговує обидві ролі, демон має відрізняти IKE від ESP-in-UDP на тому самому сокеті, що він робить за допомогою чотирибайтового маркера «не ESP», який передує повідомленню IKE. Тому клієнт не може домовитися на нестандартному порту й потім мовчки продовжити на 4500, і тому фраза «просто змініть порт» приховує вимогу до інкапсуляції.

Переадресація — це не слухач

Переадресація 4443 на звичайний слухач IKE — це режим відмови, який виглядає майже успішним. Перший обмін надходить, сервер відповідає, і далі з’єднання застрягає або перестворює ключі в нікуди, бо відповідь виходить з іншого порту, а подальший інкапсульований трафік ніколи не збігається зі станом, який створили обидва кінці. Правило, яке переписує порт призначення, не переміщаючи слухач, дає саме цей напіввідкритий результат.

Шлях також має дозволяти UDP від краю до краю. Те, що TCP 443 проходить через готельну або операторську мережу, нічого не каже про IKEv2 на порту UDP, навіть із тим самим номером. Там, де дозволено лише TCP 443, нестандартний порт UDP не перетворює IKEv2 на HTTPS, і правильною відповіддю може бути інший шлях доступу, а не черговий експеримент із портом.

Розділяйте три етапи під час тестування

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

tcpdump -ni eth0 -vv udp port 4443

Далі читайте повідомлення клієнта, а не його обертовий індикатор. Помилка пропозиції означає, що алгоритми не збігаються, збій автентифікації означає, що не збігаються ідентичності або сертифікати, а повторні передачі без відповіді означають, що на цьому порту ніхто не відповідає. Перевіряйте по одному етапу й змінюйте одне поле між спробами; документація strongSwan про проходження NAT описує маркер і поведінку порту, які показує вам запис.

Схожі статті