Android-VPN na Cisco IOS: die kontrak wat jy eerste moet kry
Voordat jy 'n Android-kliënt vir 'n Cisco IOS-gateway installeer, versamel protokol, verifikasie, identiteit en roetering. 'n Runbook vir daardie intakeproses.
Die foon moet 'n Cisco-gateway bereik. Iemand het reeds die kliënt genoem wat geïnstalleer moet word. Dit is die verkeerde kant van die proses, en dit is hoekom die tonnel misluk nadat jy 'n uur lank aanmeldingsgegewens oorgetik het.
Wat jy eerste nodig het, is 'n verbindingskontrak: protokol, verifikasie, identiteit, vertrouensmateriaal, adrestoewysing en roetering, neergeskryf deur die persoon wat die gateway bestuur.
Kry dit skriftelik en die keuse van kliënt word 'n naslaan. Laat dit weg en elke mislukking lyk soos 'n verkeerde wagwoord.
Voer die intakeproses uit voordat jy iets installeer
Stuur vir die gateway-eienaar 'n lys en vra om antwoorde, nie 'n produknaam nie. Nege items dek 'n profiel vir afstandtoegang volledig:
- Gateway-gasheernaam of -adres wat die kliënt moet skakel, en of dit van buite bereikbaar is.
- Die protokol en weergawe: IKEv2, 'n ander IPsec-generasie, of 'n TLS-gebaseerde diens.
- Die eweknie-identiteit wat die gateway verwag, en wat dit terug aanbied.
- Vertrouensmateriaal: watter CA die gateway-sertifikaat onderteken, of 'n voorafgedeelde sleutel gebruik word.
- Gebruikersverifikasie: sertifikaat, EAP-gebruikersnaam en -wagwoord, of 'n voorafgedeelde sleutel.
- Die adrespoel waarin die kliënt beland, met masker en gateway.
- DNS-bedieners om binne die tonnel te gebruik, en of die kliënt dit moet aanvaar.
- Toegelate bestemmingsvoorvoegsels, en of verkeer buite hulle geblokkeer moet word.
- Die ondersteunde kliëntweergawes en foonbedryfstelselweergawes, plus enige inskrywingsvereiste.
Twee van daardie items veroorsaak die meeste vermybare mislukkings. Sonder die vertrouensmateriaal kan jy nie die gateway valideer nie, so 'n korrekte kliënt lyk stukkend. Sonder die toegelate voorvoegsels kan jy nie 'n roeteringsbeperking van 'n diensprobleem onderskei nie.
Die verskaffernaam is nie 'n protokol nie
Cisco IOS en IOS XE bied verskeie reëlings vir afstandtoegang, en hulle deel nie 'n draadformaat nie. IKEv2 met 'n FlexVPN-agtige profiel is nie dieselfde diens as 'n ouer IKEv1-konfigurasie nie, en 'n TLS-gebaseerde kliëntdiens is weer 'n ander produk, dikwels op 'n ander platform in dieselfde omgewing.
So 'n kliënt wie se naam die roeteervervaardiger noem, bewys niks. Dit kan een van daardie dienste goed implementeer en niks anders nie. Vra watter diens opgestel is, en kyk dan of die kliënt se dokumentasie daardie diens as ondersteun noem.
Cisco se eie IKEv2-dokumentasie skei die voorstel, beleid, profiel en sleutelring as afsonderlike objekte. Daardie struktuur is nuttig wanneer jy 'n konfigurasie lees wat iemand vir jou plak: dit sê vir jou watter objek die instellings hou wat vir 'n afstandfoon saak maak, in plaas daarvan om die hele lêer as een klomp te behandel.
Wat Android se ingeboude stapel dek
Android bied 'n platform-IKEv2/IPsec-profiel deur Ikev2VpnProfile, met aparte verifikasietypes vir 'n voorafgedeelde sleutel, 'n RSA-sertifikaat, en EAP-gebruikersnaam en -wagwoord. Die Ikev2VpnProfile-verwysing is die gesag oor wat die bouer aanvaar, insluitend die gateway-gasheernaam en die bediener-wortel-CA wat gebruik word om dit te valideer.
Daardie API is 'n vermoëverklaring, nie 'n versoenbaarheidsbelofte nie. Dit sê die platform kan IKEv2 met daardie verifikasietypes doen. Dit sê nie 'n gegewe OEM-instellingsskerm wys elke veld nie, en ook nie dat 'n profiellêer wat uit 'n ander produk uitgevoer is, sal invoer nie.
Dit beteken ook die ingeboude stapel sal jou nie red as die gateway 'n diens dra wat die platform nie implementeer nie. In daardie geval het jy die verskaffer-kliënt nodig wat die operateur ondersteun, geïnstalleer en opgestel soos die operateur dokumenteer, eerder as 'n oplossing wat op 'n protokol gebou is wat die foon nie praat nie.
Toets in die volgorde waarin die kontrak geskryf is
Valideer een laag op 'n slag en stop by die eerste mislukking, want latere toetse is betekenisloos totdat die vroeëre deurkom.
Vertroue. As die kliënt die gateway-sertifikaat verwerp, maak niks anders saak nie. Bevestig die CA wat jy gekry het, onderteken die sertifikaat wat die gateway aanbied, en bevestig die gasheernaam wat jy geskakel het daarin verskyn. Hou validering aan; om dit af te skakel verander 'n identiteitsprobleem in 'n onderskeppingsrisiko.
Verifikasie. 'n Verwerpte aanmeldingsgegeven en 'n passende voorstel lewer verskillende foute maar soortgelyke mislukkings. Die gateway-log is die deurbraak: dit sal sê of die voorstel aanvaarbaar was voordat dit iets oor die gebruiker sê.
Adres en DNS. Bevestig die foon het 'n adres uit die gedokumenteerde poel ontvang, en los dan een interne naam op. 'n Tonnel wat met 'n adres opkom en geen oplosser het nie, lyk verbind en gedra hom asof niks werk nie.
Bereikbaarheid. Toets een toegelate bestemming per adres, dan per naam. As die adres werk en die naam nie, is jy terug by DNS. As nie een werk nie, vergelyk die voorvoegsel wat jy toets met die toegelate lys voordat jy die kliënt aanraak.
Mislukkingsmodusse en die terugrol
| 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 |
Hou die vorige werkende profiel uitgevoer en gedokumenteer voordat jy iets verander, insluitend die CA-alias en die adrespoel. Terugrol beteken dan om 'n bekende profiel te herstel, nie om een uit geheue tydens 'n onderbreking te herkonstrueer nie.
Wanneer dit werk, teken die nege intake-antwoorde langs die profiel aan. Die volgende foon, die volgende bedryfstelselopdatering en die volgende gateway-verandering word almal 'n vergelyking met 'n dokument in plaas van nog 'n middag van raaiwerk.