Android VPN до Cisco IOS: договір, який треба отримати першим

Телефон має дістатися шлюзу Cisco. Хтось уже назвав клієнт, який треба встановити. Це неправильний кінець процесу, і саме тому тунель падає після години повторного введення облікових даних.

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

Отримайте це письмово, і вибір клієнта стане просто довідкою. Пропустіть — і кожна невдача виглядатиме як неправильний пароль.

Зберіть відомості до того, як щось установлювати

Надішліть власникові шлюзу список і просіть відповіді, а не назву продукту. Девять пунктів повністю покривають профіль віддаленого доступу:

1. Імя хоста або адреса шлюзу, до якого клієнт має підключатися, і чи доступний він ззовні.
2. Протокол і версія: IKEv2, інше покоління IPsec або служба на основі TLS.
3. Ідентичність партнера, якої очікує шлюз, і те, що він сам подає у відповідь.
4. Матеріал довіри: який CA підписує сертифікат шлюзу або чи використовується заздалегідь розділений ключ.
5. Автентифікація користувача: сертифікат, імя користувача й пароль EAP або заздалегідь розділений ключ.
6. Пул адрес, у який потрапляє клієнт, з маскою та шлюзом.
7. DNS-сервери для використання всередині тунелю і чи має клієнт їх приймати.
8. Дозволені префікси призначення і чи треба блокувати трафік за їх межами.
9. Підтримувані версії клієнта й версії операційної системи телефону, а також будь-які вимоги реєстрації.

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

Назва постачальника — не протокол

Cisco IOS і IOS XE пропонують кілька схем віддаленого доступу, і вони не поділяють один формат передавання. IKEv2 з профілем у стилі FlexVPN — не та сама служба, що стара конфігурація IKEv1, а клієнтська служба на основі TLS — знову інший продукт, часто на іншій платформі в тому самому середовищі.

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

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

Що покриває вбудований стек Android

Android надає платформний профіль IKEv2/IPsec через Ikev2VpnProfile, з окремими типами автентифікації для заздалегідь розділеного ключа, сертифіката RSA та імени користувача й пароля EAP. Довідник Ikev2VpnProfile — авторитетне джерело про те, що приймає конструктор, зокрема імя хоста шлюзу й кореневий CA сервера, який використовується для його перевірки.

Цей API — заява про можливості, а не обіцянка сумісности. Він каже, що платформа вміє IKEv2 з цими типами автентифікації. Він не каже, що певний екран налаштувань OEM показує кожне поле, і не каже, що профільний файл, експортований з іншого продукту, буде імпортовано.

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

Перевіряйте в тому порядку, у якому написано договір

Перевіряйте один рівень за раз і зупиняйтеся на першій невдачі, бо подальші тести безглузді, доки не пройдено попередні.

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

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

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

Досяжність. Перевірте одну дозволену ціль за адресою, потім за імям. Якщо адреса працює, а імя ні, ви повернулися до DNS. Якщо не працює жодне, порівняйте перевірюваний префікс із дозволеним списком, перш ніж торкатися клієнта.

Режими відмови й відкат

Тримайте попередній робочий профіль експортованим і задокументованим, перш ніж щось змінювати, зокрема псевдонім CA й пул адрес. Тоді відкат означає відновлення відомого профілю, а не збирання його з памяти під час збою.

Коли запрацює, запишіть девять відповідей збору поруч із профілем. Наступний телефон, наступне оновлення системи й наступна зміна шлюзу стануть порівнянням із документом замість ще одного дня здогадів.