A e mbështet Meraki MX juaj Cisco Secure Client?

Dy fije mbështetjeje nuk bien dakord nëse Meraki mund të bëjë AnyConnect, dhe të dyja gabojnë me të njëjtën siguri. Pyetja nuk është nëse një MX flet IKEv2, sepse AnyConnect në pajisje është shërbim TLS dhe jo IPsec. Përgjigjen e vendosin dy kontrolle të ndara, dhe asnjëra nuk është krahasim markash. Kryejini me radhë dhe merrni një regjistër përputhshmërie në vend të një mendimi.

Së pari modeli dhe versioni

Filloni me pajisjen e saktë dhe me softuerin që ajo ekzekuton, sepse funksioni është i kufizuar në të dyja. Meraki publikon një matricë me modelet e mbështetura dhe firmware-in minimal, dhe ajo matricë është autoriteti i vetëm që vlen të citohet. Një model në listë nuk është automatikisht në një version që e mbështet funksionin, dhe një version që e mbështet mund të mos jetë ai që po ekzekutoni. Regjistroni modelin dhe firmware-in e instaluar si dy fakte të ndara. Pastaj lexoni matricën për atë çift.

Mos arsyetoni nga një model i ngjashëm në të njëjtën familje. Lista është për model, dhe dallimet janë reale.

AnyConnect është shërbim SSL, jo IPsec

Meraki e përshkruan AnyConnect në MX si VPN të bazuar në aplikacione përmes TLS dhe DTLS, dhe e dokumenton pranë një shërbimi të veçantë VPN klienti përmes L2TP/IPsec. Këto janë dy produkte që ndajnë rastësisht një panel. Krahasimi i IKEv1 me IKEv2 ju tregon për shërbimin IPsec dhe asgjë për atë nëse shërbimi TLS ekziston në pajisjen tuaj. Nëse prova juaj është një tabelë e versioneve IKE, ju jeni përgjigjur një pyetjeje tjetër.

Identifikoni cilin shërbim ekspozon pajisja përpara se të krahasoni klientët. Një profil L2TP/IPsec që funksionon nuk bëhet profil AnyConnect sepse arrin të njëjtën organizatë, dhe të dy kërkojnë konfigurim të ndryshëm klienti.

Cilat funksione ofron në të vërtetë MX

Lista e funksioneve të ASA të Cisco nuk është lista e funksioneve të MX, dhe një klient që mbështet dymbëdhjetë gjëra nuk e bën portalin t'i mbështesë ato. Krahasoni funksionet që ju nevojiten vërtet: metoda e autentikimit, sjellja e tunelit të ndarë, trajtimi i DNS dhe e drejta që kërkon pajisja. Merrni secilën nga dokumentacioni i Meraki për versionin e vendosur.

Autentikimi është vendi ku kjo zakonisht kafshon. Një metodë që klienti e ofron dhe pajisja nuk mund ta konfigurojë është një rast mbështetjeje që pret të ndodhë.

Versioni i klientit dhe e drejta

Cisco Secure Client është emri aktual i të njëjtës familje klientësh, pra një dokument që përmend AnyConnect nuk është domosdoshmërisht i vjetëruar. Ajo që ka rëndësi është versioni që vendos organizata juaj dhe nëse versioni i pajisjes është validuar ndaj tij.

Kontrolloni kërkesën e licencës në të njëjtin udhëzues në vend që ta supozoni nga një platformë tjetër. Pastaj mbani emrin e pikës fundore, verifikimin e certifikatës dhe fluksin e miratuar të autentikimit së bashku në një regjistër shërbimi, sepse këto tre dështojnë në mënyrë të pavarur. Një paralajmërim certifikate që përdoruesit thjesht e kapërcejnë me klikim nuk është rezultat përputhshmërie, është konfigurim i paverifikuar. Aksesi në distancë është vetëm gjysma e punës, sepse përdoruesit i duhen ende rrugët dhe lejet për të arritur destinacionin.

Shkruani regjistrin me pesë fusha

Modeli, firmware-i, mënyra e aksesit në distancë, versioni i klientit dhe funksionet që kërkon vendosja. Pesë fusha, dhe përgjigja nëse mund të përdorim AnyConnect qëndron në kombinim dhe jo në ndonjë prej tyre veçmas. Ai regjistër i thotë edhe inxhinierit të radhës çfarë të rikontrollojë pas një përditësimi të firmware-it.

Pastaj provoni rrugën nga fillimi në fund: autentikohuni, zgjidhni një emër të brendshëm, arrini një burim të lejuar dhe konfirmoni që një burim që nuk duhet ta arrini refuzohet. Një hyrje që ka sukses me një burim që nuk ngarkohet kurrë është rezultat i pjesshëm, dhe gjysma që mungon është zakonisht rrugëtimi ose autorizimi, jo klienti. Arkivoni kombinimin e testuar bashkë me ndryshimin, që personi tjetër të trashëgojë prova dhe jo një slogan.