Android VPN k Cisco IOS: smlouva, kterou je třeba získat první

Telefon se musí dostat k bráně Cisco. Někdo už jmenoval klienta, který se má nainstalovat. To je špatný konec postupu, a proto tunel po hodině přepisování přihlašovacích údajů selže.

Nejprve potřebujete smlouvu o připojení: protokol, ověřování, identitu, důvěryhodný materiál, přidělování adres a směrování, sepsané tím, kdo bránu spravuje.

Získejte to písemně a volba klienta se změní v pouhé dohledání. Vynechejte to a každé selhání vypadá jako špatné heslo.

Proveďte sběr informací dřív, než cokoli nainstalujete

Pošlete správci brány seznam a žádejte odpovědi, ne název produktu. Devět bodů pokrývá profil vzdáleného přístupu úplně:

1. Název hostitele nebo adresa brány, kterou má klient volat, a zda je dostupná zvenčí.
2. Protokol a verze: IKEv2, jiná generace IPsec, nebo služba založená na TLS.
3. Identita protější strany, kterou brána očekává, a co sama předkládá.
4. Důvěryhodný materiál: která CA podepisuje certifikát brány, nebo zda se používá předsdílený klíč.
5. Ověření uživatele: certifikát, uživatelské jméno a heslo EAP, nebo předsdílený klíč.
6. Fond adres, do kterého klient přistane, s maskou a bránou.
7. DNS servery pro použití uvnitř tunelu a zda je klient musí přijmout.
8. Povolené prefixy cílových sítí a zda se má provoz mimo ně blokovat.
9. Podporované verze klienta a verze operačního systému telefonu, plus případný požadavek na registraci.

Dva z těchto bodů způsobují většinu odvratitelných selhání. Bez důvěryhodného materiálu nemůžete bránu ověřit, takže správný klient vypadá rozbitý. Bez povolených prefixů nerozlišíte omezení směrování od problému služby.

Název výrobce není protokol

Cisco IOS a IOS XE nabízejí několik uspořádání vzdáleného přístupu a nesdílejí jeden přenosový formát. IKEv2 s profilem ve stylu FlexVPN není stejná služba jako starší konfigurace IKEv1 a klientská služba založená na TLS je zase jiný produkt, často na jiné platformě v témže prostředí.

Klient, v jehož názvu je výrobce routeru, tedy nic nedokazuje. Může dobře implementovat jednu z těch služeb a žádnou jinou. Zeptejte se, která služba je nakonfigurovaná, a pak ověřte, zda dokumentace klienta tuto službu uvádí jako podporovanou.

Vlastní dokumentace Cisco k IKEv2 odděluje návrh, zásadu, profil a klíčenku jako samostatné objekty. Tato struktura je užitečná, když čtete konfiguraci, kterou vám někdo vloží: řekne vám, který objekt drží nastavení důležitá pro vzdálený telefon, místo aby celý soubor bral jako jeden blok.

Co pokrývá vestavěný stack Androidu

Android zpřístupňuje platformní profil IKEv2/IPsec přes Ikev2VpnProfile, se samostatnými typy ověřování pro předsdílený klíč, certifikát RSA a uživatelské jméno a heslo EAP. Reference Ikev2VpnProfile je autoritou pro to, co tvůrce přijímá, včetně názvu hostitele brány a kořenové CA serveru použité k jeho ověření.

Toto API je prohlášení o schopnosti, ne slib kompatibility. Říká, že platforma umí IKEv2 s těmito typy ověřování. Neříká, že konkrétní obrazovka nastavení OEM zpřístupňuje každé pole, ani že se soubor profilu vyexportovaný z jiného produktu naimportuje.

Znamená to také, že vestavěný stack vás nezachrání, pokud brána provozuje službu, kterou platforma neimplementuje. V takovém případě potřebujete klientský software výrobce, který operátor podporuje, nainstalovaný a nakonfigurovaný podle dokumentace operátora, ne obchvat postavený na protokolu, kterým telefon nemluví.

Testujte v pořadí, v jakém je smlouva napsaná

Ověřujte jednu vrstvu po druhé a zastavte se u prvního selhání, protože další testy nemají smysl, dokud předchozí neprojdou.

Důvěra. Pokud klient odmítne certifikát brány, nic dalšího nehraje roli. Potvrďte, že CA, kterou jste dostali, podepisuje certifikát, který brána předkládá, a že se v něm objevuje název hostitele, který jste volali. Ověřování nechte zapnuté; jeho vypnutí mění problém identity v riziko odposlechu.

Ověřování. Odmítnuté přihlašovací údaje a neshodný návrh dávají různé chyby, ale podobně vypadající selhání. Rozhodující je log brány: řekne, zda byl návrh přijatelný, dřív než řekne cokoli o uživateli.

Adresa a DNS. Potvrďte, že telefon dostal adresu z dokumentovaného fondu, a pak přeložte jeden interní název. Tunel, který se zvedne s adresou a bez resolveru, vypadá připojený a chová se, jako by nic nefungovalo.

Dostupnost. Otestujte jedno povolené cílové místo podle adresy, pak podle názvu. Pokud adresa funguje a název ne, jste zpět u DNS. Pokud nefunguje ani jedno, porovnejte prefix, který testujete, s povoleným seznamem, než sáhnete na klienta.

Režimy selhání a návrat

Před jakoukoli změnou mějte předchozí funkční profil vyexportovaný a zdokumentovaný, včetně aliasu CA a fondu adres. Návrat pak znamená obnovit známý profil, ne ho rekonstruovat z paměti během výpadku.

Když to funguje, zapište devět odpovědí ze sběru vedle profilu. Další telefon, další aktualizace systému i další změna brány se stanou srovnáním s dokumentem místo dalšího odpoledne hádání.