AnyConnect přepisuje váš profil? Jde o kolizi názvů

Koluje historka, že AnyConnect ztratil vaši druhou bránu, nebo že je klient příliš starý na dva profily. Nestalo se ani jedno. Stalo se to, že klient ukládá každý profil, který viděl, jako soubor pojmenovaný podle toho, co poslal server, a vaše dvě brány svému souboru říkají stejně. Na disku je pro to jméno jedno místo, takže druhé stažení zabere místo prvního.

Dvě složky a jen jedna je vaše

Kopie, která se neustále mění, je pracovní kopie pod vaším uživatelským profilem, obvykle %LOCALAPPDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\preferences.xml. Tento soubor zaznamenává poslední připojení, které jste provedli, a který profil při něm byl použit. Protože leží ve vaší složce, klient ho při každém připojení přepíše, aniž by žádal zvýšení oprávnění.

Seznam v rozbalovací nabídce je něco jiného. Každý profil, který počítač kdy přijal, se zkopíruje do %PROGRAMDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\Profile a klient vypisuje, co tam leží. Zápis do této složky vyžaduje práva správce, což vysvětluje příznak, který lidé špatně čtou: ruční přidání profilu jako běžný uživatel vypadá, že funguje, a pak položka zmizí.

Soubor pro daného uživatele je tedy ukazatel a složka pro celý počítač je knihovna. Chybějící položka znamená, že se změnila knihovna, ne ukazatel.

Klient páruje soubory podle jména, ne podle brány

Identitou profilu v tomto klientovi je jméno souboru. Dvě zařízení, která obě posílají company.xml, jsou z pohledu místního úložiště profilů tentýž profil publikovaný dvakrát. Druhé stažení přepíše první a položka v okně dál ukazuje na jeden soubor, který teď popisuje druhé místo.

Proto porucha vypadá tak podivně. Jméno v seznamu se pořád čte jako místo, které očekáváte, ověřování pořád uspěje proti bráně, která je skutečně nakonfigurovaná, a nic nehlásí chybu. Změnil se obsah za štítkem, kterému jste věřili.

Čtěte HostAddress, ne štítek

Otevřete soubor v textovém editoru a podívejte se na seznam serverů. Profil nese prvek HostName, což je zobrazovaný štítek, a prvek HostAddress, což je brána, se kterou klient skutečně komunikuje. Štítek je volný text, který může upravit kdokoli, a adresa rozhoduje, kam se dostanete.

Porovnejte tyto dva s bránou, kterou jste chtěli dosáhnout, než usoudíte, že je klient rozbitý.

Zachování obou bran, popořadě

Získejte přijatý profil pro každé místo, buď z místa, nebo z počítače, který se už připojuje. Přejmenujte každý soubor tak, aby se obě jména lišila, například site-a.xml a site-b.xml. Jako správce umístěte oba do složky profilů pro celý počítač a originály, které jste obdrželi, si ponechte. Potom restartujte klienta a ověřte, že se v rozbalovací nabídce objeví obě položky.

Po připojení ke každé znovu otevřete preferences.xml a zkontrolujte, které jméno profilu teď zaznamenává jako naposledy použité. Pokud jméno odpovídá položce, na kterou jste klikli, místní mapování se chová správně. Pokud ne, něco vám stále posílá soubor přes přejmenovanou kopii.

Co přejmenování neřeší

Nové jméno souboru mění místní štítek a nic jiného. Adresa brány, metoda ověřování, certifikát, který server předkládá, i jakýkoli výběr skupiny uvnitř profilu zůstávají, jak byly. Přejmenovaná kopie špatného profilu je pořád špatný profil a připojí vás ke špatnému místu pod přesvědčivým jménem.

Nepřežije ani správní push, který cílí na původní jméno souboru.

Když to příští push zruší

Pokud vaše organizace distribuuje profily podle jména, aktualizace nahradí každý soubor, který to jméno sdílí. Berte přejmenované kopie jako místní pohodlí a po každé aktualizaci klienta zopakujte test připojení, přičemž kontrolujte adresu, ne štítek.

Pro trvalé řešení požádejte o podporované nastavení s více branami místo ruční údržby souborů. Úpravy v adresáři programu jsou první, co upgrade odstraní, a soubor uživatelských předvoleb se přepisuje záměrně.

Veďte jeden řádek na bránu: jméno souboru, HostAddress a ve které složce leží. Tahle poznámka odpoví na příští hlášení o špatném místě rychleji než reinstalace.