Cisco Secure Client блокира VPN от RDP сесия

Влизането успява, а тунелът така и не се вдига. Тази комбинация обърква хората, защото я четат като проблем с удостоверяването и после прекарват следобеда в нулиране на идентификационни данни, които никога не са били причината. Cisco Secure Client може да откаже да изгради VPN именно защото опитът е дошъл от Remote Desktop сесия, и това решение се взема от политика от страна на клиента.

Къде се появява това в потока на свързване

Проследете клиента отначало. Профилът се зарежда, идентификационните данни се събират и удостоверяването завършва. След това, преди да бъде изграден какъвто и да е тунел, клиентът оценява настройките си за сесия и изграждане спрямо средата, в която се намира.

Запишете три неща в този момент: точния текст на съобщението, версията на клиента и името на профила, показано в клиента. Тези три превръщат неясно оплакване в заявка за поддръжка, по която някой може да действа. Направете екранна снимка на диалога, защото дългите съобщения се отрязват в журнала. Отбележете и часа, за да може администраторът да го съпостави с главата.

Настройката, която всъщност решава

Политиката Windows VPN Establishment е съответстващият контрол и има две документирани стойности: само локални потребители и разрешаване на отдалечени потребители. Втората позволява изграждане на тунел от Remote Desktop сесия в поддържана конфигурация. Първата е позата по подразбиране в много корпоративни профили.

Не я бъркайте с ръководството за профила, което документира Windows Logon Enforcement като отделна политика за сесиите за вход. Едната определя коя сесия може да изгради тунела, другата определя поведението при едновременен вход или преди вход. Промяната на грешната не дава видим ефект.

Четете профила, който действително се прилага

При управлявано внедряване клиентът получава профила си от главата или от управлявано място, а копие, редактирано на диска, често не е това, което е в сила. Затова локална промяна в XML може да изглежда правилна и да не промени нищо.

Попитайте администратора кой профил и коя групова политика получава устройството, а не кой файл съществува на лаптопа. Двете често се разминават след надграждане на версията. Остаряло копие в локалната папка все още се отваря в редактора и все още изглежда правилно. Просто не е това, което клиентът е приложил.

RDP пътят след вдигане на тунела

Разрешаването на отдалечено изграждане не гарантира, че Remote Desktop сесията ви ще оцелее. Когато тунелът промени маршрути или локални правила за достъп, сесията, която ви е въвела, може да загуби пътя, който я поддържа.

Планирайте канал за възстановяване преди промяната: достъп до конзола, извънлентов път за управление или документирана процедура за повторно свързване. Решаването на това след факта обикновено означава пътуване до машината.

Не използвайте трикове за открадване на сесии, алтернативни инструменти за отдалечен контрол или парола, записана в скрипт, за да заобиколите политиката. Ако организацията не разрешава този работен процес, правилната стъпка е пътят за администриране, който тя поддържа.

Какво да изпратите на администратора

Дайте им текста на съобщението, версията на клиента, името на активния профил, типа сесия, през която сте се свързали, и дали опит от локална конзола се държи различно. Добавете времевата марка.

Точно последното сравнение спестява време, защото отделя отказа по политика на сесията от повреда в цялото устройство.

Проверка след одобрена промяна

След като профилът е актуализиран, установете нова RDP сесия и се свържете отново, после умишлено преминете през последователността за прекъсване. Потвърдете, че тунелът се вдига, пътят за управление оцелява и акаунтът ви все още може да влезе в работния плот.

Допускането до VPN, оцеляването на сесията и разрешението за вход в Windows са три отделни проверки. Преминаването на една не казва нищо за другите две.