Cisco Secure Client blokas VPN el RDP-sesio

La ensaluto sukcesas kaj la tunelo tamen ne leviĝas. Tiu kombinaĵo konfuzas homojn, ĉar ili legas ĝin kiel problemon de aŭtentigo, kaj poste pasigas posttagmezon restarigante akreditaĵojn, kiuj neniam estis la kaŭzo. Cisco Secure Client povas rifuzi starigi VPN ĝuste ĉar la provo venis el Remote Desktop-sesio, kaj tiun decidon faras politiko ĉe la klientsufero.

Kie tio aperas en la konekta fluo

Trairu la klienton de la komenco. La profilo ŝargiĝas, akreditaĵoj kolektiĝas kaj la aŭtentigo finiĝas. Poste, antaŭ ol iu ajn tunelo estas konstruata, la kliento taksas siajn agordojn de sesio kaj starigo rilate al la medio, en kiu ĝi troviĝas.

Notu tri aferojn en tiu momento: la ĝustan mesaĝon, la klientan version kaj la profilan nomon montratan en la kliento. Tiuj tri transformas malprecizan plendon en subtenpeton, pri kiu iu povas agi. Faru ekrankopion de la dialogo, ĉar longaj mesaĝoj estas tranĉataj en la protokolo. Notu ankaŭ la horon, por ke la administranto povu kompari ĝin kun la ĉefnodo.

La agordo, kiu fakte decidas

La politiko Windows VPN Establishment estas la koncerna regilo, kaj ĝi havas du dokumentitajn valorojn: nur lokaj uzantoj, kaj permesi remotajn uzantojn. La dua permesas starigi tunelon el Remote Desktop-sesio en subtenata agordo. La unua estas la defaŭlta sinteno en multaj entreprenaj profiloj.

Ne konfuzu ĝin kun Windows Logon Enforcement, kiun la profila gvidilo dokumentas kiel apartan politikon pri ensalutaj sesioj. Unu regas, kiu sesio rajtas konstrui la tunelon, la alia regas samtempan konduton aŭ konduton antaŭ ensaluto. Ŝanĝi la malĝustan havas neniun videblan efikon.

Legu la profilojn, kiuj efektive aplikiĝas

En administrata disfalo la kliento ricevas sian profilon de la ĉefnodo aŭ de administrata loko, kaj kopio redaktita sur la disko ofte ne estas la valida. Tial loka XML-ŝanĝo povas ŝajni ĝusta kaj ŝanĝi nenion.

Demandu la administranton, kiun profilon kaj kiun grupan politikon la aparato ricevas, prefere ol kiun dosieron havas la tekkomputilo. La du ofte malkonsentas post versia ĝisdatigo. Malnova kopio en la loka dosierujo ankoraŭ malfermiĝas en la redaktilo kaj ankoraŭ aspektas ĝusta. Ĝi simple ne estas tio, kion la kliento aplikis.

La RDP-vojo post kiam la tunelo leviĝas

Permesi remontan starigon ne garantias, ke via Remote Desktop-sesio postvivos. Kiam la tunelo ŝanĝas itinerojn aŭ lokajn alirregulojn, la sesio, kiu enkondukis vin, povas perdi la vojon, kiu ĝin subtenas.

Planu rekuperan kanalon antaŭ la ŝanĝo: konsola aliro, eksterbenda administrada vojo aŭ dokumentita rekonekta proceduro. Decidi tion poste kutime signifas vojaĝon al la maŝino.

Ne uzu trukojn por ŝteli sesiojn, alternativajn teleregajn ilojn aŭ pasvorton skribitan en skripton por ĉirkaŭiri la politikon. Se la organizo ne rajtigas ĉi tiun laborfluon, la ĝusta paŝo estas la administrada vojo, kiun ĝi subtenas.

Kion sendi al la administranto

Donu al ili la mesaĝan tekston, la klientan version, la nomon de la aktiva profilo, la sesian tipon per kiu vi konektiĝis, kaj ĉu provo el loka konzolo kondutas alie. Aldonu la tempomarkon.

Ĝuste tiu lasta komparo ŝparas tempon, ĉar ĝi apartigas rifuzon pro sesia politiko de tutapadata paneo.

Kontrolu post aprobita ŝanĝo

Post kiam la profilo ĝisdatiĝis, starigu novan RDP-sesion kaj konektiĝu denove, poste intence trairu la malkonektan sekvencon. Konfirmu, ke la tunelo leviĝas, ke la administrada vojo postvivas kaj ke via konto ankoraŭ povas ensaluti al la labortablo.

VPN-akcepto, sesia postvivo kaj Windows-ensaluta permeso estas tri apartaj kontroloj. Trapasi unu diras nenion pri la aliaj du.