Cisco Secure Client Always-On: разположете профила първо
Cisco Secure Client Always-On изисква профилът на крайната точка да е на място преди прилагането: проверете обхвата преди вход, доставката, политиката при отказ и доверените мрежи.
Настройките от страна на устройството не могат да накарат нерегистриран лаптоп да се държи като управлявана крайна точка и повечето внедрявания на Always-On зациклят точно в тази разлика. Cisco Secure Client прилага политиката чрез профила, който стои на машината, затова доставката на този профил е част от плана за прилагане, а не негов детайл. Минете през петте стъпки по-долу по ред и спрете на първата, която не е изпълнена, защото по-късна стъпка не може да компенсира по-ранна липса.
Стъпка първа: решете дали правилото започва преди вход
Always-On установява тунела след като потребителят влезе, а документацията на доставчика казва направо, че не установява връзка, когато никой не е влязъл. Ако изискването ви е тунел, който съществува преди екрана за вход в Windows, това е грешната функция и никакво донастройване на профила не го променя. Предварителното разполагане на профила не превръща поведението след вход в поведение преди вход.
Запишете изискването като едно от четири различни поведения и после тествайте всяко поотделно. Една успешна връзка показва само обичайния случай, а другите три са откъдето идват тикетите за поддръжка. Отбележете кой ред наистина е нужен на изискването ви, защото екип, на който му трябва само поведение след вход, може да пропусне спора за вход. Таблицата е списък за приемане, а не списък с желания.
| Behaviour | What you are proving |
|---|---|
| First use on a new machine | The profile arrived before any user connection |
| After logon | The tunnel starts without the user opening the client |
| Trusted network entry | The client stays off where it should |
| Tunnel cannot establish | The failure policy does what you decided |
Ако изискването е само вторият ред, останалата част от тази страница все още важи, но тестът за приемане е по-евтин.
Стъпка втора: потвърдете, че профилът вече е на крайната точка
Прилагането чете локален профил, затова първият въпрос е дали този файл съществува преди потребителят изобщо да се свърже. Профил, изтеглен по време на първата успешна връзка, се доставя твърде късно за машина, която трябва да е защитена от първия си вход. Доставете го с инсталатора или с управлението на крайни точки и третирайте наличието на файла като проверка при изграждане, а не като надежда.
Get-Service vpnagent | Select-Object Status, StartType
Get-ChildItem 'C:\ProgramData\Cisco\Cisco Secure Client\VPN\Profile'
Get-Content 'C:\ProgramData\Cisco\Cisco Secure Client\VPN\Profile\profile.xml' | Select-String -Pattern AlwaysOn
По-старите инсталации на AnyConnect държат същия файл в папка с друго име, затова проверете пътя за версията на клиента, която внедрявате, вместо да копирате път от стар наръчник. Услугата трябва да работи и да е настроена да стартира автоматично, защото спрян агент е крайна точка без прилагане на политика, каквото и да казва профилът.
Ако профилът липсва, спрете тук. Поправянето на политиката при отказ или на списъка с доверени мрежи за машина без профил е работа по път, който никога не се изпълнява.
Стъпка трета: изберете поведението при отказ съзнателно
Какво се случва, когато тунелът не може да се вдигне, е отделно решение от това дали тунелът стартира автоматично. Политиката при отказ на връзката решава дали крайната точка може да ползва интернет, докато установяването продължава да се проваля, и двете настройки често се бъркат, защото и двете са близо до опциите на Always-On. Изберете една нарочно и запишете причината.
Блокирането на цялата свързаност звучи строго и създава свой клас инциденти: потребител в мрежа, където шлюзът е недостъпен, не може да изтегли поправката, която би възстановила услугата. Разрешаването на интернет достъп оставя машината използваема и отслабва гаранцията, че трафикът е защитен. Всеки от двата отговора може да е правилен, но нито един не е стойност по подразбиране, която да откривате по време на авария.
Поведението при повторни опити е част от същото решение. Клиент, който опитва вечно, скрива счупен шлюз от мониторинга, а клиент, който се отказва след един опит, изглежда счупен за потребителя. Решете колко дълго крайната точка трябва да опитва, преди политиката при отказ да поеме, и тествайте това време, вместо да го предполагате.
Стъпка четвърта: определете какво се брои за доверено
Откриването на доверена мрежа използва критериите в профила на клиента, като конфигурирани домейни на DNS или доверени DNS сървъри, за да реши, че крайната точка вече е в мрежа, където тунелът е ненужен. Този списък е цялата политика, затова празен или наследен списък прави функцията или бездейна, или непредвидима.
Не го заменяйте с предположение за категорията на мрежата в защитната стена на Windows. Машина може да е в мрежа с етикет на домейн и пак да е на място, на което не се доверявате, а машина с публичен профил може да е вътре в собствената ви сграда. Критериите за откриване трябва да описват вашите мрежи пряко, а не техен заместител.
Тествайте прехода в двете посоки, включително случая, когато крайната точка преминава от доверена към недоверена мрежа, докато сесията е отворена. Прекъсването и повторното свързване са отделни събития и политика, която се справя само с първото, оставя прозорец, в който тунелът липсва.
Стъпка пета: направете политиката на крайната точка трудна за отменяне
Прилагането на крайната точка е толкова силно, колкото са собствените контроли на крайната точка. Правата на локален администратор позволяват на потребителя да спре услугата на агента, да замени профила или да деинсталира клиента, а папка на профила, в която обикновените потребители могат да пишат, е политика, която всеки може да редактира. И двете са проблеми на управлението на крайни точки, които VPN главата не може да реши вместо вас. Попитайте екипа за работни станции кое от тези две условия е налице, преди да обещаете прилагане, и запишете отговора в плана за внедряване.
Определете нивото на заключване с оглед на пътя за възстановяване. Профил, който блокира на потребителя достъпа до интернет и също му пречи да поправи клиента, превръща обаждането в поддръжката в посещение на място, затова пазете документиран маршрут за възстановяване, който не зависи от вдигнат тунел.
Оставете проверката на сертификата на шлюза включена и разпространявайте профила само по канал, на който се доверявате. Заключен клиент, който приема профил от неочакван източник, е преместил границата на доверие, вместо да я наложи.