Stöder din Meraki MX Cisco Secure Client?
Det avgörs av två olika kontroller: MX-modellen med sin firmwareversion, och vilken fjärråtkomsttjänst enheten faktiskt exponerar.
Två supporttrådar är oense om Meraki kan använda AnyConnect, och båda har på samma sätt självsäkert fel. Frågan är inte om en MX talar IKEv2, eftersom AnyConnect på enheten är en TLS-tjänst och inte IPsec. Två separata kontroller avgör svaret, och ingen av dem är en varumärkesjämförelse. Ta dem i ordning och du får en kompatibilitetsregistrering i stället för en åsikt.
Modell och version först
Börja med den exakta enheten och programvaran den kör, eftersom funktionen är begränsad till båda. Meraki publicerar en matris med stödda modeller och minimifirmware, och den matrisen är den enda auktoritet som är värd att citera. En modell i listan kör inte automatiskt en version som stöder funktionen, och en version som stöder den är kanske inte den du kör. Registrera modellen och den installerade firmwaren som två separata fakta. Läs sedan matrisen för det paret.
Resonera inte utifrån en liknande modell i samma familj. Listan gäller per modell, och skillnaderna är verkliga.
AnyConnect är en SSL-tjänst, inte IPsec
Meraki beskriver AnyConnect på MX som en applikationsbaserad VPN över TLS och DTLS, och dokumenterar den vid sidan av en separat klient-VPN-tjänst över L2TP/IPsec. Det är två produkter som råkar dela en instrumentpanel. Att jämföra IKEv1 med IKEv2 säger dig om IPsec-tjänsten och ingenting om huruvida TLS-tjänsten finns på din enhet. Om ditt bevis är en tabell över IKE-versioner har du svarat på en annan fråga.
Identifiera vilken tjänst enheten exponerar innan du jämför klienter. En fungerande L2TP/IPsec-profil blir inte en AnyConnect-profil för att den når samma organisation, och de två kräver olika klientkonfiguration.
Vilka funktioner MX faktiskt erbjuder
Ciscos ASA-funktionslista är inte MX-funktionslistan, och en klient som stöder tolv saker gör inte att gatewayen stöder dem. Jämför de funktioner du faktiskt behöver: autentiseringsmetod, beteende för delad tunnel, DNS-hantering och den rättighet enheten kräver. Ta var och en från Meraki-dokumentationen för den utrullade versionen.
Autentisering är där detta brukar bita. En metod som klienten erbjuder och enheten inte kan konfigurera är ett supportärende som väntar på att inträffa.
Klientversion och rättighet
Cisco Secure Client är det nuvarande namnet på samma klientfamilj, så ett dokument som nämner AnyConnect är inte nödvändigtvis inaktuellt. Det som spelar roll är den version din organisation rullar ut och om enhetens version är validerad mot den.
Kontrollera licenskravet i samma guide i stället för att anta det från en annan plattform. Håll sedan slutpunktsnamnet, certifikatverifieringen och det godkända autentiseringsflödet tillsammans i en enda tjänsteregistrering, eftersom dessa tre misslyckas oberoende av varandra. En certifikatvarning som användarna bara klickar sig förbi är inte ett kompatibilitetsresultat, det är en overifierad konfiguration. Fjärråtkomst är bara halva jobbet, eftersom användaren fortfarande behöver rutter och behörigheter för att nå målet.
Skriv registreringen med fem fält
Modell, firmware, fjärråtkomstläge, klientversion och de funktioner som utrullningen kräver. Fem fält, och svaret på om vi kan använda AnyConnect ligger i kombinationen och inte i något enskilt av dem. Den registreringen berättar också för nästa ingenjör vad som ska kontrolleras igen efter en firmwareuppgradering.
Testa sedan vägen från början till slut: autentisera, slå upp ett internt namn, nå en tillåten resurs och bekräfta att en resurs du inte borde nå avvisas. En inloggning som lyckas med en resurs som aldrig laddas är ett delresultat, och den saknade halvan är oftast routing eller auktorisering, inte klienten. Arkivera den testade kombinationen med ändringen, så att nästa person ärver bevis i stället för en slogan.