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 — гэта тры асобныя праверкі. Паспяховае праходжанне адной нічога не кажа пра дзве іншыя.