Cisco Secure Client blokuoja VPN iš RDP sesijos

Prisijungimas pavyksta, o tunelis vis tiek nekeliamas. Šis derinys klaidina, nes jis skaitomas kaip autentifikavimo problema, o paskui popietė praleidžiama iš naujo nustatant prisijungimo duomenis, kurie niekada nebuvo priežastis. Cisco Secure Client gali atsisakyti kurti VPN būtent todėl, kad bandymas atėjo iš Remote Desktop sesijos, ir šį sprendimą priima politika kliento pusėje.

Kur tai pasireiškia ryšio eigoje

Peržiūrėkite klientą iš viršaus. Profilis įkeliamas, prisijungimo duomenys surenkami, autentifikavimas baigiamas. Tada, prieš sukuriant bet kokį tunelį, klientas įvertina savo sesijos ir kūrimo nustatymus aplinkos, kurioje atsidūrė, atžvilgiu.

Tuo metu užsirašykite tris dalykus: tikslų pranešimą, kliento versiją ir kliente rodomą profilio pavadinimą. Šie trys paverčia neaiškų skundą paramos užklausa, su kuria kas nors gali ką nors padaryti. Padarykite dialogo ekrano kopiją, nes ilgi pranešimai žurnale sutrumpinami. Pažymėkite ir laiką, kad administratorius galėtų jį palyginti su pagrindiniu serveriu.

Nustatymas, kuris iš tikrųjų nusprendžia

Politika Windows VPN Establishment yra atitinkama kontrolė, ir ji turi dvi dokumentuotas reikšmes: tik vietiniai naudotojai ir leisti nuotolinius naudotojus. Antroji leidžia kurti tunelį iš Remote Desktop sesijos palaikomoje konfigūracijoje. Pirmoji yra numatytoji pozicija daugelyje įmonės profilių.

Nesumaišykite jos su Windows Logon Enforcement, kurią profilio vadovas dokumentuoja kaip atskirą politiką apie prisijungimo sesijas. Viena reglamentuoja, kuri sesija gali kurti tunelį, kita – vienalaikį arba prieš prisijungimą vykstantį elgesį. Neteisingos pakeitimas nesuteikia jokio matomo poveikio.

Skaitykite profilį, kuris iš tikrųjų taikomas

Valdomame diegime klientas gauna profilį iš pagrindinio serverio arba valdomos vietos, o diske redaguota kopija dažnai nėra galiojanti. Todėl vietinis XML pakeitimas gali atrodyti teisingai ir nieko nepakeisti.

Klauskite administratoriaus, kokį profilį ir kokią grupės politiką gauna įrenginys, o ne koks failas yra nešiojamajame kompiuteryje. Po versijos naujinimo šie du dažnai nesutampa. Pasenusi kopija vietiniame aplanke vis dar atidaroma redaktoriuje ir vis dar atrodo teisingai. Ji tiesiog nėra tai, ką klientas pritaikė.

RDP kelias po to, kai tunelis pakyla

Nuotolinio kūrimo leidimas negarantuoja, kad jūsų Remote Desktop sesija išliks. Kai tunelis keičia maršrutus arba vietines prieigos taisykles, sesija, kuri jus įvedė, gali prarasti ją palaikantį kelią.

Suplanuokite atkūrimo kanalą prieš pakeitimą: prieigą prie konsolės, už juostos esantį valdymo kelią arba dokumentuotą prisijungimo iš naujo procedūrą. Nuspręsti tai po fakto paprastai reiškia kelionę prie mašinos.

Nenaudokite sesijų vagystės gudrybių, alternatyvių nuotolinio valdymo įrankių ar scenarijuje įrašyto slaptažodžio politikai apeiti. Jei organizacija neleidžia šio darbo proceso, teisingas žingsnis yra administravimo kelias, kurį ji palaiko.

Ką siųsti administratoriui

Duokite jam pranešimo tekstą, kliento versiją, aktyvaus profilio pavadinimą, sesijos tipą, per kurį prisijungėte, ir ar bandymas iš vietinės konsolės elgiasi kitaip. Pridėkite laiko žymą.

Būtent paskutinis palyginimas taupo laiką, nes atskiria atmetimą pagal sesijos politiką nuo viso įrenginio gedimo.

Patikrinkite po patvirtinto pakeitimo

Atnaujinus profilį, sukurkite naują RDP sesiją ir prisijunkite dar kartą, tada sąmoningai atlikite atsijungimo seką. Patvirtinkite, kad tunelis pakyla, valdymo kelias išlieka ir jūsų paskyra vis dar gali prisijungti prie darbalaukio.

Priėmimas į VPN, sesijos išlikimas ir Windows prisijungimo leidimas yra trys atskiri patikrinimai. Vieno praėjimas nieko nesako apie kitus du.