Vi alklakas Konekti kaj la dialogo respondas preskaŭ tuj: malsukcesis pravalorizi la konektan subsistemon. Nenio atingis la enirejon, do ne estas atestila interŝanĝo, neniu akreditaĵo kaj neniu elekto de tunela grupo ĉe la alia flanko. Tio signifas, ke la protokoloj de la koncentrilo montros malplenan sesion kaj la helpa servo petos ekrankopion de dialogo, kiu neniam enhavis ion utilan. Laboru anstataŭe pri la finpunkto, laŭ fiksa ordo, kaj haltu ĉe la unua paŝo, kiu ŝanĝas la rezulton.

La tempo estas la plej valora pruvo, kiun vi havas, kaj registri ĝin kostas nenion. Notu, ĉu la eraro aperis antaŭ aŭ post la peto pri akreditaĵo, kaj ĉu ĝi komenciĝis post ĝisdatigo, Windows-ĝisdatigo aŭ nova sekureca agento. Tiuj tri respondoj kutime duonigas la liston de kandidatoj antaŭ ol vi tuŝas ajnan agordon.

Legu la tempon antaŭ ol ŝanĝi ion

Tri paneoj aspektas similaj kaj ne estas. Se la dialogo aperas en la momento, kiam vi premas Konekti, la kliento ne povis startigi sian propran infrastrukturon, kaj tion montras ĉi tiu mesaĝo. Se ĝi aperas post kiam vi tajpis akreditaĵojn, la tunela grupo estis atingita kaj la problemo estas pli antaŭe. Se la tunelo leviĝas kaj poste falas, la subsistemo pravaloriĝis bone kaj vi postkuras tute alian cimon. Konfuzi la tri forfandas posttagmezon en reinstaladoj, kiuj ne povas helpi.

Nur la unua kazo apartenas ĉi tien. La mesaĝo estas generita antaŭ ol iu ajn reta decido estas farita, do malĝusta enireja adreso, eksvalida atestilo aŭ malbona pasvorto ne produktos ĝin.

Paŝo 1: konfirmu, ke la agenta servo funkcias

La fenestro, kiun vi alklakas, estas fasado; la laboro okazas en la servo Cisco AnyConnect Secure Mobility Agent, registrita kiel vpnagent. Se tiu servo estas haltigita aŭ malŝaltita, la GUI havas nenion, kun kio paroli kaj raportas precize ĉi tiun pravalorizan paneon. Kontrolu la staton kaj la startan tipon el PowerShell-komanda invito kun altigitaj rajtoj:

Get-Service vpnagent | Select-Object Name, Status, StartType
sc.exe qc vpnagent
net start vpnagent

Instalilo, kiu respektis antaŭe permane agorditan startan tipon, estas la kutima kialo, ke ĉi tio finiĝas malŝaltita, do kontrolu StartType anstataŭ simple premi Start. Se la servo startas kaj haltas ene de sekundoj, legu la sisteman protokolon por la rikordoj de Service Control Manager antaŭ ol klaki Ripari:

Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Service Control Manager"} -MaxEvents 40

Blokita pelilo, kvarantenita dosiero aŭ filtra pelilo de triaparta sekureca produkto nomos sin en tiuj eventoj. Ripari reinstalas super la saman blokitan dosieron kaj ŝanĝas nenion, tial la eventa protokolo venas unue.

Paŝo 2: purigu la senretan staton, kiun raportas la HTTP-stako

La kliento elŝutas sian profilon kaj taksas politikon per la HTTP-komponentoj de Windows, do senreta flago agordita en la retaj agordoj de la uzanto povas rompi la pravalorizon, dum ĉiu retumilo daŭre ŝutas paĝojn. Kontrolu la valoron rekte:

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name GlobalUserOffline

Valoro 1 signifas, ke la WinINet-stako diras al alvokantoj, ke la maŝino havas neniun konekton; tiun staton kutime agordas la menuero Labori senrete en Internet Explorer aŭ aŭtomatiga skripto. Reagordu ĝin al 0, elsalutu kaj ensalutu denove, kaj reprovu la konekton antaŭ ol ŝanĝi ion alian.

Se vi heredis ĉi tiun maŝinon kaj ne povas diri, kial la flago estis agordita, notu tion en la bileto. Io alia en la maŝino eble intence agordis ĝin, kaj ĝi revenos ĉe la sekva ensaluto.

Paŝo 3: liberigu la virtualan adaptilon de Hyper-V aŭ ICS

Du roloj de Windows povas teni la pecojn, kiujn la kliento bezonas por krei sian adaptilon. Hyper-V estas la unua: kiam la servoj de la virtuala ŝaltilo funkcias, kreo de adaptilo povas malsukcesi tiel, ke ĝi aperas kiel ĉi tiu eraro. Haltigi la servojn estas diagnozo, ne riparo:

Get-Service vmms, vmcompute | Stop-Service
Get-NetAdapter | Where-Object InterfaceDescription -like "*Hyper-V*"

Se la kliento konektiĝas kun tiuj servoj haltigitaj, la konflikto estas konfirmita kaj vi nun scias, pri kio intertrakti kun la posedanto de la Hyper-V-gastiganto. Restartigu ilin poste, krom se la maŝino ne plu bezonas virtualigon.

Kunhavigo de interreta konekto estas la dua posedanto. Se konekto estas kunhavigata, la kliento povas panei antaŭ ol ĝi eĉ kreas tunelon. Konfirmu per Get-Service SharedAccess kaj, se ĝi funkcias kaj estas agordita al aŭtomata, trarigardu la adaptilojn por kunhavigita konekto kaj malŝaltu kunhavigon nur sur tiu adaptilo.

Estas ankaŭ pli malmultekosta klarigo, kiun oni devas unue forigi. Maŝino sen iu ajn funkcianta interreta aliro ofte montras ĉi tiun mesaĝon anstataŭ atingebla eraro, do konfirmu, ke Test-NetConnection al la enireja adreso kaj al publika gastiganto ambaŭ sukcesas antaŭ ol kulpigi la klienton.

Kontrolu, poste malfaru tion, kion vi ne bezonis

Kontrolo ne estas la verda ŝildo en la sistemplato. Konfirmu, ke la adaptilo ekzistas, havas adreson kaj pasigas trafikon: Get-NetAdapter -Name "Cisco AnyConnect*" devas montri ĝin aktiva, ipconfig /all devas montri la asignitan adreson kaj la DNS-servilojn, kaj reala peto al interna nomo devas solviĝi tra la tunelo anstataŭ tra la loka solvilo.

Tenu mallongan liston de ĉiu ŝanĝo dum vi iras, kun la valoro, kiun vi trovis, kaj la valoro, kiun vi agordis. Se la konekto funkcias post la tria paŝo, restarigu la servojn de Hyper-V kaj retestu antaŭ ol fermi la bileton, ĉar provizora solvo, kiu kviete malŝaltas virtualigon, estos malfarita de la sekva administranto, kiu rimarkas.

Se neniu el la tri paŝoj movas la eraron, ĉesu ŝanĝi la finpunkton. Kolektu la klientan version, la staton de la servo, la tempon el la supro de ĉi tiu paĝo kaj la diagnostikan pakaĵon, kiun la kliento povas produkti, poste transdonu ilin kun la preciza ordo, kiun vi provis. Tiu pakaĵo valoras pli por la sekva inĝeniero ol ekrankopio de la dialogo, kaj ĝi estas la sola artefakto, kiu montras, ĉu la subsistemo paneis antaŭ aŭ post ol ĝi tuŝis la reton.

Rilataj artikoloj