Android VPN do Cisco IOS: umowa, którą trzeba zdobyć najpierw

Telefon musi dotrzeć do bramy Cisco. Ktoś już wskazał klienta, który ma zostać zainstalowany. To zły koniec procesu i właśnie dlatego tunel zawodzi po godzinie ponownego wpisywania danych logowania.

Najpierw potrzebna jest umowa o połączeniu: protokół, uwierzytelnianie, tożsamość, materiał zaufania, przydział adresów i routing, spisane przez osobę zarządzającą bramą.

Zdobądź to na piśmie, a wybór klienta stanie się zwykłym sprawdzeniem. Pomiń, a każda awaria będzie wyglądać jak błędne hasło.

Zbierz informacje, zanim cokolwiek zainstalujesz

Wyślij właścicielowi bramy listę i proś o odpowiedzi, nie o nazwę produktu. Dziewięć punktów w pełni pokrywa profil dostępu zdalnego:

1. Nazwa hosta lub adres bramy, do której klient ma się łączyć, i czy jest osiągalna z zewnątrz.
2. Protokół i wersja: IKEv2, inna generacja IPsec albo usługa oparta na TLS.
3. Tożsamość drugiej strony oczekiwana przez bramę i to, co ona sama przedstawia.
4. Materiał zaufania: który CA podpisuje certyfikat bramy albo czy używany jest klucz współdzielony z góry.
5. Uwierzytelnianie użytkownika: certyfikat, nazwa użytkownika i hasło EAP albo klucz współdzielony z góry.
6. Pula adresów, w której ląduje klient, wraz z maską i bramą.
7. Serwery DNS do użycia wewnątrz tunelu i czy klient musi je zaakceptować.
8. Dozwolone prefiksy docelowe i czy ruch poza nimi ma być blokowany.
9. Obsługiwane wersje klienta i wersje systemu operacyjnego telefonu oraz wszelkie wymagania rejestracyjne.

Dwa z tych punktów powodują większość awarii, których można uniknąć. Bez materiału zaufania nie zweryfikujesz bramy, więc poprawny klient wygląda na zepsuty. Bez dozwolonych prefiksów nie odróżnisz ograniczenia routingu od problemu z usługą.

Nazwa dostawcy to nie protokół

Cisco IOS i IOS XE oferują kilka rozwiązań dostępu zdalnego i nie dzielą jednego formatu transmisji. IKEv2 z profilem w stylu FlexVPN to nie ta sama usługa co starsza konfiguracja IKEv1, a usługa klienta oparta na TLS to kolejny produkt, często na innej platformie w tym samym środowisku.

Klient, w którego nazwie pojawia się dostawca routera, niczego więc nie dowodzi. Może dobrze realizować jedną z tych usług i żadnej innej. Zapytaj, która usługa jest skonfigurowana, a potem sprawdź, czy dokumentacja klienta wymienia ją jako obsługiwaną.

Dokumentacja IKEv2 samego Cisco rozdziela propozycję, politykę, profil i pęk kluczy jako osobne obiekty. Ta struktura jest przydatna, gdy czytasz konfigurację, którą ktoś ci wkleja: mówi, który obiekt trzyma ustawienia istotne dla zdalnego telefonu, zamiast traktować cały plik jako jedną bryłę.

Co obejmuje wbudowany stos Androida

Android udostępnia platformowy profil IKEv2/IPsec przez Ikev2VpnProfile, z osobnymi typami uwierzytelniania dla klucza współdzielonego z góry, certyfikatu RSA oraz nazwy użytkownika i hasła EAP. Dokumentacja Ikev2VpnProfile jest źródłem wiedzy o tym, co przyjmuje konstruktor, w tym nazwa hosta bramy i główny CA serwera używany do jej weryfikacji.

To API jest deklaracją możliwości, nie obietnicą zgodności. Mówi, że platforma potrafi IKEv2 z tymi typami uwierzytelniania. Nie mówi, że dany ekran ustawień OEM pokazuje każde pole, ani że plik profilu wyeksportowany z innego produktu da się zaimportować.

Oznacza to też, że wbudowany stos cię nie uratuje, jeśli brama udostępnia usługę, której platforma nie implementuje. Wtedy potrzebny jest klient dostawcy obsługiwany przez operatora, zainstalowany i skonfigurowany tak, jak dokumentuje operator, a nie obejście zbudowane na protokole, którym telefon nie mówi.

Testuj w kolejności, w jakiej spisano umowę

Weryfikuj jedną warstwę naraz i zatrzymaj się na pierwszej awarii, bo dalsze testy nie mają sensu, dopóki wcześniejsze nie przejdą.

Zaufanie. Jeśli klient odrzuci certyfikat bramy, nic innego się nie liczy. Potwierdź, że otrzymany CA podpisuje certyfikat przedstawiany przez bramę i że nazwa hosta, do której dzwoniłeś, w nim występuje. Zostaw weryfikację włączoną; wyłączenie jej zamienia problem tożsamości w ryzyko przechwycenia.

Uwierzytelnianie. Odrzucone dane logowania i niedopasowana propozycja dają różne błędy, ale podobnie wyglądające awarie. Dziennik bramy rozstrzyga: powie, czy propozycja była akceptowalna, zanim powie cokolwiek o użytkowniku.

Adres i DNS. Potwierdź, że telefon otrzymał adres z udokumentowanej puli, a następnie rozwiąż jedną nazwę wewnętrzną. Tunel, który wstaje z adresem i bez resolvera, wygląda na połączony i zachowuje się, jakby nic nie działało.

Osiągalność. Przetestuj jeden dozwolony cel po adresie, potem po nazwie. Jeśli adres działa, a nazwa nie, wróciłeś do DNS. Jeśli żadne nie działa, porównaj testowany prefiks z listą dozwolonych, zanim dotkniesz klienta.

Tryby awarii i wycofanie

Trzymaj poprzedni działający profil wyeksportowany i udokumentowany, zanim cokolwiek zmienisz, wraz z aliasem CA i pulą adresów. Wycofanie oznacza wtedy przywrócenie znanego profilu, a nie odtwarzanie go z pamięci podczas awarii.

Gdy zadziała, zapisz dziewięć odpowiedzi zbieranych obok profilu. Następny telefon, następna aktualizacja systemu i następna zmiana bramy staną się porównaniem z dokumentem zamiast kolejnym popołudniem zgadywania.