Android VPN mot Cisco IOS: kontrakten som må på plass først
Før en Android-klient installeres mot en Cisco IOS-gateway, må protokoll, autentisering, identitet og ruting avklares. En sjekkliste for den fasen.
Telefonen skal koble seg til en Cisco-gateway. Klienten er kanskje allerede bestemt av noen andre. Det er å begynne i feil ende, og forklarer hvorfor tunnelen svikter etter en times retasting av påloggingsinformasjon.
Først trengs en avtale om tilkoblingen: protokoll, autentisering, identitet, tillitsmateriale, adressetildeling og ruting, nedfelt av den som forvalter gatewayen.
Er dette dokumentert, blir klientvalget en ren oppslagssak. Mangler det, fremstår hver feil som et galt passord.
Kartlegg før du installerer noe som helst
Be gateway-eieren om svar på en punktliste, ikke om et produktnavn. Ni punkter gir full dekning av en fjernaksessprofil:
- Hvilket vertsnavn eller hvilken adresse klienten skal koble til, og om den er tilgjengelig utenfra.
- Protokoll og versjon: IKEv2, en annen IPsec-generasjon, eller en TLS-basert tjeneste.
- Hvilken partneridentitet gatewayen forventer, og hva den selv viser tilbake.
- Tillitsmateriale: hvilken CA som har signert gateway-sertifikatet, eller om forhåndsdelt nøkkel benyttes.
- Brukerautentisering: sertifikat, EAP-brukernavn med passord, eller forhåndsdelt nøkkel.
- Hvilken adressepool klienten havner i, med maske og gateway.
- DNS-servere inne i tunnelen, og om klienten plikter å bruke dem.
- Tillatte destinasjonsprefikser, og om trafikk utenfor skal stenges.
- Støttede klientversjoner og OS-versjoner på telefonen, samt krav om registrering.
To punkter står bak de fleste unødvendige feilene. Uten tillitsmaterialet lar gatewayen seg ikke validere, og en riktig klient ser da ødelagt ut. Uten de tillatte prefiksene kan en rutebegrensning forveksles med en tjenestefeil.
Leverandørnavnet er ikke en protokoll
Både Cisco IOS og IOS XE har flere varianter av fjernaksess, og de bruker ikke samme overføringsformat. IKEv2 med FlexVPN-lignende profil er en annen tjeneste enn en eldre IKEv1-konfigurasjon, og en TLS-basert klienttjeneste er atter et annet produkt, ofte på en annen plattform i samme installasjon.
En klient som bare viser til ruterleverandøren i navnet, sier derfor ingenting. Den kan ha god støtte for én av tjenestene og ingen av de øvrige. Finn ut hvilken tjeneste som faktisk er satt opp, og kontroller at klientens dokumentasjon oppgir støtte for nettopp den.
Ciscos egen dokumentasjon for IKEv2 holder forslag, policy, profil og nøkkelring som separate objekter. Det er nyttig når en konfigurasjon klistres inn: du ser hvilket objekt som rommer innstillingene som gjelder for en ekstern telefon, i stedet for å behandle hele filen som én enhet.
Dekningen i Androids innebygde stack
Android tilbyr en plattformprofil for IKEv2/IPsec gjennom Ikev2VpnProfile, med egne autentiseringstyper for forhåndsdelt nøkkel, RSA-sertifikat og EAP-brukernavn med passord. Referansen for Ikev2VpnProfile er fasiten for hva byggeren godtar, inkludert vertsnavnet til gatewayen og serverens rot-CA som brukes ved validering.
Dette API-et er en kapasitetsbeskrivelse, ikke en garanti for kompatibilitet. Det sier at plattformen behersker IKEv2 med disse autentiseringstypene. Det sier ikke at en bestemt OEM-innstillingsskjerm viser alle felt, eller at en profilfil fra et annet produkt lar seg importere.
Følgelig hjelper ikke den innebygde stacken dersom gatewayen kjører en tjeneste plattformen ikke har. Da trengs leverandørens klient, forutsatt at operatøren støtter den, installert og satt opp i tråd med operatørens dokumentasjon, ikke en nødløsning på en protokoll telefonen ikke behersker.
Verifiser i samme rekkefølge som kontrakten
Ta ett lag om gangen, og avbryt ved første feil. Tester lenger ut er verdiløse så lenge de foregående ikke er grønne.
Tillit. Avvises gateway-sertifikatet av klienten, er alt annet irrelevant. Kontroller at CA-en du fikk, har signert sertifikatet gatewayen viser, og at vertsnavnet du koblet til, står i det. Ikke skru av valideringen; det gjør en identitetsfeil om til en avlyttingsrisiko.
Autentisering. Avviste påloggingsdata og et forslag som ikke matcher gir forskjellige feilkoder, men like feilsymptomer. Gateway-loggen avgjør: den viser om forslaget ble godtatt før den sier noe om brukeren.
Adresse og DNS. Kontroller at telefonen har fått adresse fra den dokumenterte poolen, og slå deretter opp ett internt navn. En tunnel med adresse men uten resolver ser oppe ut, men oppfører seg som om ingenting virker.
Nåbarhet. Prøv én tillatt destinasjon på adresse, deretter på navn. Virker adressen men ikke navnet, er DNSen tilbake. Virker ingen av dem, sammenlign prefikset du tester med den tillatte listen før klienten endres.
Feilmønstre og tilbakerulling
| 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 |
Sørg for at forrige fungerende profil er eksportert og dokumentert før endringer, inkludert CA-alias og adressepool. Da innebærer tilbakerulling å gjenopprette en kjent profil, ikke å bygge den på nytt fra hukommelsen midt i en driftsstans.
Når det virker, noter de ni kartleggingssvarene ved profilen. Neste telefon, neste OS-oppdatering og neste gateway-endring blir da sammenlignet mot et dokument, ikke nok en ettermiddag med gjetting.