Як MOBIKE зберігає VPN IKEv2 під час зміни мережі
MOBIKE оновлює підтримуване з'єднання IKEv2, коли пристрій змінює мережу. Маршрутизація, фільтрування та відновлення сеансу застосунку все одно мають працювати.
Телефон залишає Wi-Fi і приєднується до стільникової мережі, ноутбук переходить з Ethernet на точку доступу, і тунель IKEv2 або виживає, або ні. MOBIKE — це розширення, яке дозволяє йому вижити, повідомляючи далекій стороні, що адреса джерела змінилася, замість того щоб починати спочатку. Чого воно не робить — не зберігає роботу кожного застосунку під час зміни. Це два твердження, і друге зазвичай і мають на увазі.
Пройдіть перехід поетапно, бо кожен етап відмовляє по-своєму.
Що насправді змінює оновлення
Поки асоціація безпеки ще дійсна, ініціатор дізнається свою нову адресу й надсилає оновлення відповідачу, який потім використовує цю адресу для тієї самої асоціації. Параметри безпеки не узгоджуються заново з нуля. У цьому вся вигода: жодного нового кола автентифікації, жодного нового обміну ключами, жодного запиту до користувача. Це також означає, що збережений стан досі належить старому сеансу.
MOBIKE може також перевести трафік в інкапсуляцію UDP, тому робочий тунель іноді починає використовувати порт 4500 після зміни мережі. Цей перехід сам по собі не доводить, що NAT виявлено, хоча обидва часто з'являються разом.
Чи справді ваш профіль це вмикає
Обидві сторони мають підтримувати розширення, і розгортання має його ввімкнути. У strongSwan поведінка налаштовується для кожного з'єднання, а зміни інтерфейсу або маршруту можуть запускати пошук шляху й оновлення за потреби. Перегляньте фактичні налаштування з'єднання, а не припускайте, що кожен профіль IKEv2 його вмикає. Профіль, скопійований із посібника, старішого за цю функцію, — часта причина цього.
Узгоджений стан на обох кінцях є авторитетом, а не документація родини продуктів.
Пройдіть перехід поетапно
Запишіть стан застосунку перед зміною мереж. Потім змініть і запишіть стан клієнта та сервера після цього. Відсутня адреса, недосяжний партнер і застосунок, який має сам перепідключити свій сеанс, — три різні результати. Лише перші два належать до рівня VPN; третій належить до протоколу, яким говорить застосунок.
Порівняйте перемикання мережі зі стаціонарним тестом, щоб знати, яка подія спричиняє проблему. Вимірювання пропускної здатності в кінцевій мережі не може відтворити перехід. Воно вимірює пункт призначення, а не шлях.
Розділіть рівні відмови
Довготривалий сеанс TCP може відмовити з причин поза обміном IKEv2. Нова мережа може фільтрувати, розв'язувати імена або маршрутизувати інакше. Адреса тунелю може взагалі не змінитися, поки шлях під нею змінюється. Тому перепідключення застосунку може виправити те, що VPN ніколи не ламав.
Тримайте політику блокування на місці й під час відновлення.
Автоматична мобільність і правило, що забороняє прямий трафік, — різні засоби контролю, і вимикати друге, щоб працювало перше, — поганий обмін. Якщо оновлення мобільності не вдається, блокування має втриматися, а не пропускати трафік в обхід тунелю.
Що записувати, коли це повторюється
Зберігайте позначки часу та обидва значення адрес з обох боків. Цей запис показує, чи завершилося оновлення до того, як застосунок втратив контакт, і в цьому різниця між помилкою мобільності та тайм-аутом застосунку. Потім порівняйте напрямок перемикання: вихід з Wi-Fi у стільникову мережу не симетричний до зворотного. Один напрямок може працювати, поки інший відмовляє.
Ця асиметрія достатньо поширена, щоб бути першим, що варто перевірити.
Із записом у руках інцидент перестає бути черговою відключеною іконкою і стає однією подією в послідовності з відомим власником. І це все, що може чесно обіцяти прохід.