Két támogatási szál vitatkozik arról, tud-e a Meraki AnyConnectet, és mindkettő ugyanúgy magabiztosan téved. A kérdés nem az, hogy az MX beszél-e IKEv2-t, mert az eszközön az AnyConnect TLS-szolgáltatás, nem IPsec. Két külön ellenőrzés dönti el a választ, és egyik sem márkaösszehasonlítás. Végezze el őket sorrendben, és vélemény helyett kompatibilitási rekordot kap.

Először a modell és a verzió

Kezdje a pontos eszközzel és a rajta futó szoftverrel, mert a funkció mindkettőhöz kötött. A Meraki közzétesz egy mátrixot a támogatott modellekről és a minimális firmware-ről, és ez a mátrix az egyetlen idézésre érdemes forrás. Egy listán szereplő modell nem automatikusan fut olyan kiadáson, amely támogatja a funkciót, és egy azt támogató kiadás nem biztos, hogy az, amelyet Ön futtat. Rögzítse a modellt és a telepített firmware-t két külön tényként. Ezután olvassa el a mátrixot erre a párra.

Ne következtessen egy hasonló modellből ugyanabban a családban. A lista modellenként értendő, és a különbségek valósak.

Az AnyConnect SSL-szolgáltatás, nem IPsec

A Meraki az MX AnyConnectjét TLS- és DTLS-alapú alkalmazás-VPN-ként írja le, és egy külön L2TP/IPsec kliens VPN-szolgáltatás mellett dokumentálja. Ez két termék, amelyek véletlenül közös irányítópulton osztoznak. Az IKEv1 és az IKEv2 összehasonlítása az IPsec-szolgáltatásról mond valamit, és semmit arról, létezik-e a TLS-szolgáltatás az eszközén. Ha a bizonyítéka egy IKE-verziótáblázat, akkor más kérdésre válaszolt.

Azonosítsa, melyik szolgáltatást kínálja az eszköz, mielőtt klienseket hasonlít össze. Egy működő L2TP/IPsec profil nem lesz AnyConnect profil attól, hogy ugyanazt a szervezetet éri el, és a kettő eltérő klienskonfigurációt igényel.

Milyen funkciókat kínál valójában az MX

A Cisco ASA funkciólistája nem az MX funkciólistája, és egy tizenkét dolgot támogató kliens nem teszi az átjárót azzá, hogy támogassa őket. Hasonlítsa össze a valóban szükséges funkciókat: hitelesítési módszer, osztott alagút viselkedése, DNS-kezelés és a jogosultság, amelyet az eszköz megkövetel. Mindegyiket a Meraki dokumentációjából vegye a telepített kiadáshoz.

A hitelesítés az a pont, ahol ez általában fáj. Egy módszer, amelyet a kliens kínál, de az eszköz nem tud beállítani, olyan támogatási eset, amely csak vár arra, hogy megtörténjen.

Kliensverzió és jogosultság

A Cisco Secure Client ugyanannak a klienscsaládnak a jelenlegi neve, tehát az AnyConnectet említő dokumentum nem feltétlenül elavult. Az számít, hogy a szervezete melyik verziót telepíti, és hogy az eszköz kiadása validált-e vele szemben.

Ellenőrizze a licenckövetelményt ugyanabban az útmutatóban, ne feltételezze egy másik platformról. Ezután tartsa a végpont nevét, a tanúsítvány-ellenőrzést és a jóváhagyott hitelesítési folyamatot együtt egy szolgáltatási rekordban, mert ez a három egymástól függetlenül hibázik. Az a tanúsítványfigyelmeztetés, amelyen a felhasználók átkattintanak, nem kompatibilitási eredmény, hanem ellenőrizetlen konfiguráció. A távoli hozzáférés csak a munka fele, mert a felhasználónak még mindig útvonalakra és engedélyekre van szüksége a cél eléréséhez.

Írja le a rekordot öt mezővel

Modell, firmware, távoli hozzáférési mód, kliensverzió és a telepítés által igényelt funkciók. Öt mező, és az a válasz, hogy használhatjuk-e az AnyConnectet, a kombinációban rejlik, nem bármelyikben önmagában. Ez a rekord azt is megmondja a következő mérnöknek, mit kell újra ellenőrizni firmware-frissítés után.

Ezután tesztelje az útvonalat elejétől a végéig: hitelesítsen, oldjon fel egy belső nevet, érjen el egy engedélyezett erőforrást, és győződjön meg arról, hogy egy elérhetetlen erőforrás elutasításra kerül. Az a bejelentkezés, amely sikerül, de az erőforrás soha nem töltődik be, részeredmény, és a hiányzó fél általában az útválasztás vagy a jogosultság, nem a kliens. Archiválja a tesztelt kombinációt a változtatással, hogy a következő ember bizonyítékot örököljön szlogen helyett.

Kapcsolódó cikkek