VPN d'Android a Cisco IOS: el contracte que cal obtenir primer

El telèfon ha d'arribar a una passarel·la Cisco. Algú ja ha nomenat el client que cal instal·lar. Aquest és el final equivocat del procés, i per això el túnel falla després d'una hora de tornar a escriure credencials.

El que necessiteu primer és un contracte de connexió: protocol, autenticació, identitat, material de confiança, assignació d'adreces i encaminament, escrit per qui gestiona la passarel·la.

Aconseguiu-ho per escrit i l'elecció del client es converteix en una consulta. Ometeu-ho i cada fallada sembla una contrasenya incorrecta.

Feu la recollida abans d'instal·lar res

Enviau a l'amo de la passarel·la una llista i demaneu respostes, no un nom de producte. Nou punts cobreixen completament un perfil d'accés remot:

1. El nom d'amfitrió o l'adreça de la passarel·la a la qual el client ha de marcar, i si és accessible des de fora.
2. El protocol i la versió: IKEv2, una altra generació d'IPsec o un servei basat en TLS.
3. La identitat de parell que espera la passarel·la i què presenta ella a canvi.
4. Material de confiança: quina CA signa el certificat de la passarel·la o si s'utilitza una clau compartida prèviament.
5. Autenticació d'usuari: certificat, nom d'usuari i contrasenya EAP o una clau compartida prèviament.
6. El pool d'adreces on cau el client, amb màscara i passarel·la.
7. Els servidors DNS a utilitzar dins del túnel i si el client els ha d'acceptar.
8. Els prefixos de destinació permesos i si el trànsit fora d'ells s'ha de bloquejar.
9. Les versions de client admeses i les versions del sistema operatiu del telèfon, més qualsevol requisit d'alta.

Dos d'aquests punts causen la majoria de fallades evitables. Sense el material de confiança no podeu validar la passarel·la, així que un client correcte sembla espatllat. Sense els prefixos permesos no podeu distingir una restricció d'encaminament d'un problema de servei.

El nom del fabricant no és un protocol

Cisco IOS i IOS XE ofereixen diverses disposicions d'accés remot i no comparteixen un mateix format de transmissió. IKEv2 amb un perfil a l'estil FlexVPN no és el mateix servei que una configuració IKEv1 més antiga, i un servei de client basat en TLS és encara un altre producte, sovint en una altra plataforma dins del mateix entorn.

Per tant, un client el nom del qual esmenta el fabricant del router no demostra res. Pot implementar bé un d'aquells serveis i cap dels altres. Pregunteu quin servei està configurat i després comproveu que la documentació del client nomena aquest servei com a admès.

La documentació pròpia d'IKEv2 de Cisco separa la proposta, la política, el perfil i l'anell de claus com a objectes diferents. Aquesta estructura és útil quan llegiu una configuració que algú us enganxa: us diu quin objecte conté els paràmetres que importen per a un telèfon remot, en lloc de tractar tot el fitxer com una sola massa.

Què cobreix la pila integrada d'Android

Android exposa un perfil IKEv2/IPsec de plataforma mitjançant Ikev2VpnProfile, amb tipus d'autenticació separats per a una clau compartida prèviament, un certificat RSA i nom d'usuari i contrasenya EAP. La referència d'Ikev2VpnProfile és l'autoritat sobre què accepta el constructor, inclòs el nom d'amfitrió de la passarel·la i la CA arrel del servidor utilitzada per validar-lo.

Aquesta API és una declaració de capacitat, no una promesa de compatibilitat. Diu que la plataforma pot fer IKEv2 amb aquests tipus d'autenticació. No diu que una pantalla de configuració d'OEM concret exposi tots els camps, ni que un fitxer de perfil exportat d'un altre producte s'importarà.

També vol dir que la pila integrada no us salvarà si la passarel·la executa un servei que la plataforma no implementa. En aquest cas necessiteu el client del fabricant que l'operador admet, instal·lat i configurat com documenta l'operador, en lloc d'una solució improvisada sobre un protocol que el telèfon no parla.

Proveu en l'ordre en què està escrit el contracte

Valideu una capa alhora i atureu-vos a la primera fallada, perquè les proves posteriors no tenen sentit fins que passin les anteriors.

Confiança. Si el client rebutja el certificat de la passarel·la, res més importa. Confirmeu que la CA que us han donat signa el certificat que presenta la passarel·la i que el nom d'amfitrió que heu marcat hi apareix. Manteniu la validació activa; desactivar-la converteix un problema d'identitat en un risc d'intercepció.

Autenticació. Unes credencials rebutjades i una proposta que no coincideix produeixen errors diferents però fallades d'aspecte similar. El registre de la passarel·la és el desempat: dirà si la proposta era acceptable abans de dir res sobre l'usuari.

Adreça i DNS. Confirmeu que el telèfon ha rebut una adreça del pool documentat i després resoleu un nom intern. Un túnel que s'aixeca amb una adreça i sense resolutor sembla connectat i es comporta com si res funcionés.

Abast. Proveu una destinació permesa per adreça i després per nom. Si l'adreça funciona i el nom no, torneu a ser a DNS. Si no funciona cap, compareu el prefix que proveu amb la llista permesa abans de tocar el client.

Modes de fallada i la reversió

Manteniu el perfil de treball anterior exportat i documentat abans de canviar res, inclòs l'àlies de la CA i el pool d'adreces. Aleshores la reversió significa restaurar un perfil conegut, no reconstruir-lo de memòria durant una interrupció.

Quan funcioni, anoteu les nou respostes de la recollida al costat del perfil. El proper telèfon, la propera actualització del sistema i el proper canvi de passarel·la esdevenen una comparació amb un document en lloc d'una altra tarda d'endevinar.