Android VPN Cisco IOS-hez: a szerződés, amelyet először be kell szerezni

A telefonnak el kell érnie egy Cisco átjárót. Valaki már megnevezte a telepítendő klienst. Ez a folyamat rossz vége, és ezért sikertelen az alagút egy órányi hitelesítőadat-újragépelés után.

Először egy kapcsolati szerződésre van szüksége: protokoll, hitelesítés, identitás, bizalmi anyag, címkiosztás és útválasztás, amelyet az átjárót üzemeltető ír le.

Szerezze meg írásban, és a kliensválasztás puszta kereséssé válik. Hagyja ki, és minden hiba rossz jelszónak látszik.

A felmérést még azelőtt végezze el, hogy bármit telepítene

Küldjön listát az átjáró tulajdonosának, és válaszokat kérjen, ne terméknevet. Kilenc pont teljesen lefedi a távoli hozzáférési profilt:

1. Az átjáró gazdagépneve vagy címe, amelyet a kliensnek hívnia kell, és hogy elérhető-e kívülről.
2. A protokoll és a verzió: IKEv2, másik IPsec-generáció vagy TLS-alapú szolgáltatás.
3. A társ identitása, amelyet az átjáró elvár, és amit ő maga visszaküld.
4. Bizalmi anyag: melyik CA írja alá az átjáró tanúsítványát, vagy előre megosztott kulcsot használnak-e.
5. Felhasználói hitelesítés: tanúsítvány, EAP-felhasználónév és jelszó, vagy előre megosztott kulcs.
6. A címkészlet, amelybe a kliens kerül, maszkkal és átjáróval.
7. Az alagúton belül használandó DNS-kiszolgálók, és hogy a kliensnek el kell-e fogadnia őket.
8. Az engedélyezett cél-előtagok, és hogy az azokon kívüli forgalmat blokkolni kell-e.
9. A támogatott kliensekiadások és telefon operációsrendszer-verziók, valamint bármilyen regisztrációs követelmény.

E pontok közül kettő okozza a legtöbb elkerülhető hibát. Bizalmi anyag nélkül nem tudja érvényesíteni az átjárót, így a helyes kliens hibásnak látszik. Az engedélyezett előtagok nélkül nem tudja megkülönböztetni az útválasztási korlátozást egy szolgáltatási problémától.

A szállító neve nem protokoll

A Cisco IOS és az IOS XE több távoli hozzáférési megoldást kínál, és nem osztoznak egyetlen átviteli formátumon. Az IKEv2 FlexVPN-szerű profillal nem ugyanaz a szolgáltatás, mint egy régebbi IKEv1-konfiguráció, a TLS-alapú kliensszolgáltatás pedig megint más termék, gyakran más platformon ugyanabban a környezetben.

Tehát egy kliens, amelynek nevében a router szállítója szerepel, semmit sem bizonyít. Jól megvalósíthatja az egyik ilyen szolgáltatást, a többit pedig egyáltalán nem. Kérdezze meg, melyik szolgáltatás van beállítva, majd ellenőrizze, hogy a kliens dokumentációja támogatottként nevezi-e meg azt.

A Cisco saját IKEv2-dokumentációja külön objektumként választja szét a javaslatot, a szabályzatot, a profilt és a kulcskarikát. Ez a szerkezet akkor hasznos, amikor egy Önnek beillesztett konfigurációt olvas: megmondja, melyik objektum tartja a távoli telefon szempontjából fontos beállításokat, ahelyett hogy az egész fájlt egyetlen tömegként kezelné.

Mit fed le az Android beépített verme

Az Android a platform IKEv2/IPsec-profilját Ikev2VpnProfile révén teszi elérhetővé, külön hitelesítéstípusokkal előre megosztott kulcshoz, RSA-tanúsítványhoz, valamint EAP-felhasználónévhez és jelszóhoz. Az Ikev2VpnProfile-referencia a mérvadó forrás arról, mit fogad el az építő, beleértve az átjáró gazdagépnevét és az érvényesítéséhez használt kiszolgáló gyökér-CA-t.

Ez az API képességi nyilatkozat, nem kompatibilitási ígéret. Azt mondja, hogy a platform képes IKEv2-re ezekkel a hitelesítéstípusokkal. Nem mondja, hogy egy adott OEM beállítási képernyő minden mezőt megjelenít, és azt sem, hogy egy másik termékből exportált profilfájl importálható.

Ez azt is jelenti, hogy a beépített verem nem menti meg, ha az átjáró olyan szolgáltatást futtat, amelyet a platform nem valósít meg. Ebben az esetben az üzemeltető által támogatott szállítói kliensre van szükség, az üzemeltető dokumentációja szerint telepítve és beállítva, nem pedig egy olyan protokollra épített kerülőútra, amelyet a telefon nem beszél.

A szerződés írásának sorrendjében teszteljen

Egyszerre egy réteget érvényesítsen, és álljon meg az első hibánál, mert a későbbi tesztek értelmetlenek, amíg a korábbiak nem mennek át.

Bizalom. Ha a kliens elutasítja az átjáró tanúsítványát, semmi más nem számít. Erősítse meg, hogy a kapott CA írja alá az átjáró által bemutatott tanúsítványt, és hogy a hívott gazdagépnév szerepel benne. Tartsa bekapcsolva az érvényesítést; kikapcsolása az identitásproblémát lehallgatási kockázattá alakítja.

Hitelesítés. Az elutasított hitelesítő adatok és a nem illeszkedő javaslat különböző hibákat, de hasonlóan kinéző hibákat eredményez. Az átjáró naplója dönt: megmondja, elfogadható volt-e a javaslat, mielőtt bármit mondana a felhasználóról.

Cím és DNS. Erősítse meg, hogy a telefon a dokumentált készletből kapott címet, majd oldjon fel egy belső nevet. Az az alagút, amely cím mellett feloldó nélkül jön fel, csatlakozottnak látszik, és úgy viselkedik, mintha semmi sem működne.

Elérhetőség. Teszteljen egy engedélyezett célt cím szerint, majd név szerint. Ha a cím működik és a név nem, visszajutott a DNS-hez. Ha egyik sem működik, hasonlítsa össze a tesztelt előtagot az engedélyezett listával, mielőtt a klienshez nyúl.

Hibamódok és a visszaállítás

Tartsa a korábbi működő profilt exportálva és dokumentálva, mielőtt bármit módosít, beleértve a CA-álnevet és a címkészletet. A visszaállítás ekkor ismert profil helyreállítását jelenti, nem pedig annak kiesés közbeni, emlékezetből történő újraépítését.

Ha működik, jegyezze fel a kilenc felmérési választ a profil mellé. A következő telefon, a következő rendszerfrissítés és a következő átjáróváltozás mind egy dokumentummal való összehasonlítássá válik egy újabb találgatós délután helyett.