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 и пула от адреси. Тогава връщането назад означава възстановяване на известен профил, а не сглобяването му по памет по време на прекъсване.

Когато работи, запишете деветте отговора от събирането до профила. Следващият телефон, следващата актуализация на системата и следващата промяна на шлюза стават сравнение с документ вместо още един следобед на гадаене.