Android-VPN till Cisco IOS: avtalet du måste skaffa först
Innan du installerar en Android-klient för en Cisco IOS-gateway måste du hämta in protokoll, autentisering, identitet och routing. En runbook för den fasen.
Telefonen ska nå en Cisco-gateway. Någon har redan pekat ut klienten som ska installeras. Det är fel ände av processen, och det är därför tunneln fallerar efter en timme av att skriva in inloggningsuppgifter igen.
Det du behöver först är ett anslutningsavtal: protokoll, autentisering, identitet, förtroendematerial, adresstilldelning och routing, nedskrivet av den som driftar gatewayen.
Få det skriftligt och klientvalet blir ett uppslag. Hoppa över det och varje fel ser ut som ett felaktigt lösenord.
Gör inventeringen innan du installerar något
Skicka en lista till gatewayens ägare och be om svar, inte om ett produktnamn. Nio punkter täcker en fjärråtkomstprofil helt:
- Gatewayens värdnamn eller adress som klienten ska ringa, och om den är nåbar utifrån.
- Protokollet och versionen: IKEv2, en annan IPsec-generation eller en TLS-baserad tjänst.
- Den peer-identitet gatewayen förväntar sig, och vad den själv presenterar tillbaka.
- Förtroendematerial: vilken CA som signerar gatewayens certifikat, eller om en fördelad nyckel används.
- Användarautentisering: certifikat, EAP-användarnamn och lösenord eller en fördelad nyckel.
- Adresspoolen som klienten hamnar i, med nätmask och gateway.
- DNS-servrar att använda inne i tunneln, och om klienten måste acceptera dem.
- Tillåtna destinationsprefix, och om trafik utanför dem ska blockeras.
- De klientversioner och telefonens OS-versioner som stöds, samt eventuella registreringskrav.
Två av dessa punkter orsakar de flesta undvikbara felen. Utan förtroendematerialet kan du inte validera gatewayen, så en korrekt klient ser trasig ut. Utan de tillåtna prefixen kan du inte skilja en routingbegränsning från ett tjänsteproblem.
Leverantörens namn är inte ett protokoll
Cisco IOS och IOS XE erbjuder flera fjärråtkomstupplägg, och de delar inte ett enda överföringsformat. IKEv2 med en FlexVPN-liknande profil är inte samma tjänst som en äldre IKEv1-konfiguration, och en TLS-baserad klienttjänst är återigen en annan produkt, ofta på en annan plattform i samma miljö.
En klient vars namn nämner routerleverantören bevisar alltså ingenting. Den kan implementera en av dessa tjänster väl och ingen av de andra. Fråga vilken tjänst som är konfigurerad och kontrollera sedan om klientens dokumentation anger den tjänsten som stödd.
Ciscos egen IKEv2-dokumentation skiljer förslaget, policyn, profilen och nyckelringen som egna objekt. Den strukturen är användbar när du läser en konfiguration som någon klistrar in till dig: den berättar vilket objekt som håller inställningarna som spelar roll för en extern telefon, i stället för att behandla hela filen som en enda klump.
Vad Androids inbyggda stack täcker
Android exponerar en plattforms-IKEv2/IPsec-profil via Ikev2VpnProfile, med separata autentiseringstyper för en fördelad nyckel, ett RSA-certifikat samt EAP-användarnamn och lösenord. Ikev2VpnProfile-referensen är auktoriteten för vad byggaren accepterar, inklusive gatewayens värdnamn och serverns rot-CA som används för att validera den.
Det API:et är en kapacitetsdeklaration, inte ett kompatibilitetslöfte. Det säger att plattformen kan IKEv2 med de autentiseringstyperna. Det säger inte att en viss OEM-inställningsskärm visar varje fält, och inte heller att en profilfil exporterad från en annan produkt kommer att importeras.
Det betyder också att den inbyggda stacken inte räddar dig om gatewayen kör en tjänst som plattformen inte implementerar. I så fall behöver du leverantörens klient som operatören stöder, installerad och konfigurerad som operatören dokumenterar, i stället för en kringgång byggd på ett protokoll som telefonen inte talar.
Testa i den ordning avtalet är skrivet
Validera ett lager i taget och stoppa vid första felet, för senare tester är meningslösa tills de tidigare går igenom.
Förtroende. Om klienten avvisar gatewayens certifikat spelar inget annat någon roll. Bekräfta att CA:n du fick signerar det certifikat gatewayen presenterar, och att värdnamnet du ringde står i det. Låt valideringen vara på; att stänga av den gör ett identitetsproblem till en risk för avlyssning.
Autentisering. Avvisade inloggningsuppgifter och ett förslag som inte passar ger olika fel men liknande symtom. Gatewayens logg är avgörande: den säger om förslaget var godtagbart innan den säger något om användaren.
Adress och DNS. Bekräfta att telefonen fick en adress från den dokumenterade poolen och lös sedan upp ett internt namn. En tunnel som kommer upp med en adress men utan resolver ser ansluten ut och beter sig som om ingenting fungerar.
Nåbarhet. Testa en tillåten destination på adress och sedan på namn. Fungerar adressen men inte namnet är du tillbaka på DNS. Fungerar ingen av dem, jämför prefixet du testar med den tillåtna listan innan du rör klienten.
Fellägen och återställningen
| Symptom | Contract item to re-check |
|---|---|
| Profile rejected at import | Protocol or client release unsupported for that service |
| No proposal chosen | IKE version or encryption proposal mismatch |
| Certificate error, correct credentials | Trust material or peer identity |
| Tunnel up, no address | Address pool or authorization on the gateway |
| Tunnel up, names fail | DNS servers or split-tunnel DNS behaviour |
Håll den tidigare fungerande profilen exporterad och dokumenterad innan du ändrar något, inklusive CA-aliaset och adresspoolen. Återställning betyder då att återställa en känd profil, inte att rekonstruera den ur minnet under ett avbrott.
När det fungerar, skriv ner de nio inventeringssvaren bredvid profilen. Nästa telefon, nästa OS-uppdatering och nästa gatewayändring blir alla en jämförelse med ett dokument i stället för ännu en eftermiddag av gissningar.