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 се три одделни проверки. Поминувањето на едната не кажува ништо за другите две.