VPN Android către Cisco IOS: contractul care trebuie obținut mai întâi

Telefonul trebuie să ajungă la un gateway Cisco. Cineva a numit deja clientul care trebuie instalat. Acesta este capătul greșit al procesului și de aceea tunelul eșuează după o oră de rescriere a acreditărilor.

De ce aveți nevoie mai întâi este un contract de conectare: protocol, autentificare, identitate, material de încredere, alocarea adreselor și rutare, scris de cel care administrează gateway-ul.

Obțineți-l în scris și alegerea clientului devine o simplă căutare. Omiteți-l și fiecare eșec pare o parolă greșită.

Faceți colectarea înainte de a instala ceva

Trimiteți proprietarului gateway-ului o listă și cereți răspunsuri, nu un nume de produs. Nouă puncte acoperă complet un profil de acces la distanță:

1. Numele de gazdă sau adresa gateway-ului pe care clientul trebuie să îl apeleze, și dacă este accesibil din exterior.
2. Protocolul și versiunea: IKEv2, o altă generație IPsec sau un serviciu bazat pe TLS.
3. Identitatea de partener pe care o așteaptă gateway-ul și ce prezintă el însuși în schimb.
4. Material de încredere: ce CA semnează certificatul gateway-ului sau dacă se folosește o cheie prepartajată.
5. Autentificarea utilizatorului: certificat, nume de utilizator și parolă EAP sau o cheie prepartajată.
6. Pool-ul de adrese în care ajunge clientul, cu mască și gateway.
7. Serverele DNS de folosit în tunel și dacă clientul trebuie să le accepte.
8. Prefixele de destinație permise și dacă traficul din afara lor trebuie blocat.
9. Versiunile de client acceptate și versiunile sistemului de operare al telefonului, plus orice cerință de înregistrare.

Două dintre aceste puncte cauzează majoritatea eșecurilor evitabile. Fără materialul de încredere nu puteți valida gateway-ul, așa că un client corect pare defect. Fără prefixele permise nu puteți distinge o restricție de rutare de o problemă de serviciu.

Numele furnizorului nu este un protocol

Cisco IOS și IOS XE oferă mai multe aranjamente de acces la distanță și nu împart un singur format de transmisie. IKEv2 cu un profil de tip FlexVPN nu este același serviciu ca o configurație IKEv1 mai veche, iar un serviciu de client bazat pe TLS este încă un alt produs, adesea pe altă platformă în același mediu.

Așadar, un client al cărui nume menționează furnizorul routerului nu dovedește nimic. Poate implementa bine unul dintre aceste servicii și niciunul dintre celelalte. Întrebați ce serviciu este configurat și apoi verificați dacă documentația clientului menționează acel serviciu ca fiind acceptat.

Documentația IKEv2 a Cisco separă propunerea, politica, profilul și inelul de chei ca obiecte distincte. Această structură este utilă când citiți o configurație pe care cineva o lipește la dvs.: vă spune care obiect deține setările importante pentru un telefon la distanță, în loc să trateze tot fișierul ca un singur bloc.

Ce acoperă stiva integrată a Android

Android expune un profil IKEv2/IPsec de platformă prin Ikev2VpnProfile, cu tipuri de autentificare separate pentru o cheie prepartajată, un certificat RSA și nume de utilizator și parolă EAP. Referința Ikev2VpnProfile este autoritatea privind ce acceptă constructorul, inclusiv numele de gazdă al gateway-ului și CA rădăcină a serverului folosită pentru validarea lui.

Acest API este o declarație de capacitate, nu o promisiune de compatibilitate. Spune că platforma poate face IKEv2 cu acele tipuri de autentificare. Nu spune că un anumit ecran de setări OEM expune fiecare câmp și nici că un fișier de profil exportat din alt produs va fi importat.

Înseamnă și că stiva integrată nu vă salvează dacă gateway-ul rulează un serviciu pe care platforma nu îl implementează. În acest caz aveți nevoie de clientul furnizorului acceptat de operator, instalat și configurat conform documentației operatorului, nu de o soluție ocolitoare construită pe un protocol pe care telefonul nu îl vorbește.

Testați în ordinea în care este scris contractul

Validați un singur strat o dată și opriți-vă la primul eșec, pentru că testele ulterioare nu au sens până când cele anterioare nu trec.

Încredere. Dacă clientul respinge certificatul gateway-ului, nimic altceva nu contează. Confirmați că CA primită semnează certificatul prezentat de gateway și că numele de gazdă apelat apare în el. Lăsați validarea activă; dezactivarea ei transformă o problemă de identitate într-un risc de interceptare.

Autentificare. Acreditările respinse și o propunere nepotrivită produc erori diferite, dar eșecuri cu aspect similar. Jurnalul gateway-ului este decisiv: va spune dacă propunerea a fost acceptabilă înainte de a spune ceva despre utilizator.

Adresă și DNS. Confirmați că telefonul a primit o adresă din pool-ul documentat, apoi rezolvați un nume intern. Un tunel care urcă cu adresă și fără resolver pare conectat și se comportă ca și cum nimic nu ar funcționa.

Accesibilitate. Testați o destinație permisă după adresă, apoi după nume. Dacă adresa funcționează, iar numele nu, ați revenit la DNS. Dacă niciuna nu funcționează, comparați prefixul testat cu lista permisă înainte de a atinge clientul.

Moduri de eșec și revenirea

Păstrați profilul anterior funcțional exportat și documentat înainte de a schimba ceva, inclusiv aliasul CA și pool-ul de adrese. Atunci revenirea înseamnă restaurarea unui profil cunoscut, nu reconstruirea lui din memorie în timpul unei întreruperi.

Când funcționează, notați cele nouă răspunsuri ale colectării lângă profil. Următorul telefon, următoarea actualizare de sistem și următoarea modificare a gateway-ului devin o comparație cu un document în loc de încă o după-amiază de presupuneri.