AnyConnect oorskryf jou profiel? Dit is ’n naamkonflik

Die verhaal wat rondgaan is dat AnyConnect jou tweede gateway verloor het, of dat die kliënt te oud is om twee profiele te hou. Nie een het gebeur nie. Wat gebeur het, is dat die kliënt elke profiel wat hy gesien het, stoor as ’n lêer met die naam wat die bediener gestuur het, en jou twee gateways noem albei hul lêer dieselfde. Daar is een plek op skyf vir daardie naam, so die tweede aflaai neem die plek van die eerste.

Twee vouers, en net een is joune

Die kopie wat verander, is die werkkopie onder jou eie gebruikersprofiel, gewoonlik %LOCALAPPDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\preferences.xml. Daardie lêer teken die laaste verbinding aan wat jy gemaak het en watter profiel dit gebruik het. Omdat dit in jou vouer is, herskryf die kliënt dit by elke verbinding sonder om verhoging te vra.

Die lys in die aftreklys is iets anders. Elke profiel wat die masjien ooit ontvang het, word na %PROGRAMDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\Profile gekopieer, en die kliënt lys wat ook al daar staan. Om na daardie vouer te skryf, vereis administrateurregte, wat ’n simptoom verduidelik wat mense verkeerd lees: om ’n profiel met die hand as gewone gebruiker by te voeg, lyk of dit werk, dan verdwyn die inskrywing.

Dus is die per-gebruiker lêer ’n wyser en die masjienwye vouer die biblioteek. ’n Vermiste inskrywing beteken die biblioteek het verander, nie die wyser nie.

Die kliënt pas lêers op naam, nie op gateway nie

Profielidentiteit in hierdie kliënt is die lêernaam. Twee toestelle wat albei company.xml stuur, is, sover die plaaslike profielstoor betref, dieselfde profiel wat twee keer gepubliseer is. Die tweede aflaai oorskryf die eerste, en die inskrywing in die venster bly wys na een lêer wat nou die ander terrein beskryf.

Dit is hoekom die faling so vreemd lyk. Die naam in die lys lees nog steeds soos die plek wat jy verwag, verifikasie slaag nog steeds teen watter gateway ook al werklik opgestel is, en niks rapporteer ’n fout nie. Wat verander het, is die inhoud agter ’n etiket wat jy vertrou het.

Lees HostAddress, nie die etiket nie

Maak die lêer in ’n teksredigeerder oop en kyk na die bedienerlys. ’n Profiel dra ’n HostName-element, wat ’n vertoonetiket is, en ’n HostAddress-element, wat die gateway is waaraan die kliënt werklik kontak maak. Die etiket is vrye teks wat enigiemand kan wysig, en die adres bepaal waar jy beland.

Vergelyk daardie twee met die gateway wat jy bedoel het, voordat jy tot die gevolgtrekking kom dat die kliënt stukkend is.

Albei gateways hou, in orde

Kry die aanvaarde profiel vir elke terrein, hetsy van die terrein of van ’n masjien wat reeds verbind. Hernoem elke lêer sodat die twee name verskil, byvoorbeeld site-a.xml en site-b.xml. As administrateur, plaas albei in die masjienwye profielvouer en hou die oorspronklikes wat jy ontvang het. Herbegin dan die kliënt en bevestig dat albei inskrywings in die aftreklys verskyn.

Nadat jy aan elkeen verbind het, maak preferences.xml weer oop en kyk watter profielnaam dit nou as laas gebruik aanteken. As die naam ooreenstem met die inskrywing waarop jy gekliek het, werk die plaaslike kartering. So nie, stuur iets nog steeds ’n lêer oor jou hernoemde kopie.

Wat hernoeming nie regmaak nie

’n Nuwe lêernaam verander ’n plaaslike etiket en niks anders nie. Die gateway-adres, die verifikasiemetode, die sertifikaat wat die bediener aanbied en enige groepkeuse in die profiel bly soos dit was. ’n Hernoemde kopie van die verkeerde profiel is nog steeds die verkeerde profiel, en dit sal jou onder ’n oortuigende naam aan die verkeerde terrein koppel.

Dit oorleef ook nie ’n bestuursstoot wat die oorspronklike lêernaam teiken nie.

Wanneer die volgende stoot dit ongedaan maak

As jou organisasie profiele op naam versprei, vervang ’n opdatering enige lêer met daardie naam. Beskou die hernoemde kopieë as ’n plaaslike gerief en herhaal die verbindingstoets na elke kliëntopdatering, en kyk na die adres eerder as die etiket.

Vir ’n permanente reëling, vra vir ’n ondersteunde multi-gateway-opstelling eerder as om lêers met die hand te onderhou. Wysigings in die programmap het ’n opgradering eerste verwyder, en die per-gebruiker voorkeurlêer word volgens ontwerp herskryf.

Hou een reël per gateway: lêernaam, HostAddress en watter vouer dit in woon. Daardie nota beantwoord die volgende verkeerde-terrein-verslag vinniger as ’n herinstallasie.