Հաճախորդը պտտվում է securing communications փուլում և երբեք չի ցուցադրում մուտքագրման հուշում, և միակ փոփոխությունը էմուլյատորի տեղադրումն էր։ Այս օրինաչափությունը մատնանշում է վիրտուալ ադապտերը, ոչ թե պրոֆիլը կամ գաղտնաբառը։ Որոշումը հետևյալն է՝ ադապտերը կապված է Hyper-V փոխարկիչի՞ն, որտեղ չպետք է լինի, թե՞ այն ընդհանրապես չի բարձրացել։

Այս երկու վիճակները հաճախորդում նույնն են թվում և տարբեր վերանորոգում են պահանջում։ Մեկը կապ է, որը կարող եք չեղարկել, մյուսը՝ դրայվերի խնդիր, որին արձակումը չի դիպչի։

Ինչի է սպասում securing communications փուլը

Նախքան թունելի կառուցումը, հաճախորդին անհրաժեշտ է աշխատող տեղական ցանցային ուղի դեպի դարպասը։ Այն տեղադրում է իր վիրտուալ ադապտերը և օգտագործում այն որպես այդ ուղու մաս։ Եթե Hyper-V-ը այդ ադապտերը միացնում է էմուլյատորի համար ստեղծված փոխարկիչին, ադապտերը կարող է դադարել օգտագործելի ուղի տրամադրել։

Հաճախորդը չի հաղորդում, թե որ ադապտերին է սպասում։ Մատյանը սովորաբար ավարտվում է վերջին հասած փուլում, և նույն ձախողումը հայտնվում է յուրաքանչյուր դարպասի հասցեի համար։ Այդ պատճառով տեղադրման պատմությունն ավելի կարևոր է, քան սխալի տեքստը։ Մատյանը դեռ արժե պահել. այն ասում է փուլը, ոչ պատճառը։

Նույնականացման տվյալների վերաներմուծումը կամ պրոֆիլի վերատեղադրումը չեն կարող փոխել փոխարկիչի կապը։ Եթե դրանք ձեր առաջին երկու քայլերն են, դուք վերանորոգում եք սխալ շերտը։

Առաջին որոշումը՝ VPN ադապտերը կապվա՞ծ է սխալ փոխարկիչին

Բացեք Hyper-V Manager-ը, ապա Virtual Switch Manager-ը և կարդացեք յուրաքանչյուր փոխարկիչի ադապտերների ցանկը։ Cisco ադապտերը չպետք է հայտնվի որպես էմուլյատորի փոխարկիչի կցորդ։ Եթե հայտնվում է, դա ձեր սխալն է, և վերանորոգումը այն այդ փոխարկիչից հեռացնելն է։

Նախ վերագործարկեք, որ հաճախորդը մաքուր սկսի, ոչ թե կիսամիացված։ Հեռացրեք կապը, կիրառեք այն և թողեք մյուս ադապտերներին հանգիստ, մինչև չփորձարկեք։ Փոփոխությունը շրջելի է և ոչինչ չի հեռացնում, բայց գրեք, թե որ ադապտերներն արձակեցիք։

Միացրեք հաճախորդը և փորձեք կապը։ Եթե այն դեռ կախված է, արձակեք մնացած վիրտուալ ադապտերները մեկ առ մեկ և փորձարկեք յուրաքանչյուրից հետո, որպեսզի իմանաք, թե որն էր կարևոր։

Երկրորդ որոշումը՝ ադապտերը միացված է, բայց հասցե չունի՞

Գործարկեք ipconfig /all-ը բարձրացված հրամանի տողից, որպեսզի թաքնված ադապտերները նույնպես ներառվեն, և համեմատեք ցանկը նրա հետ, ինչ հիշում եք տեղադրումից առաջ։ Առանց հասցեի և անջատված կրիչի վիճակով ադապտերը սովորաբար նշանակում է, որ դրայվերը չի գործարկվել։ Դա չի վերանորոգվում արձակմամբ։ Գրանցեք ճշգրիտ վիճակը նախքան որևէ բան փոխելը։

Այն ադապտերը, որը միացված է, բայց կապված է սխալ փոխարկիչին, նախորդ բաժնի դեպքն է։ Հասցեի վիճակն է, ինչով տարբերում եք երկուսը։

Վերականգնեք էմուլյատորը՝ չվերականգնելով խափանումը

Երբ թունելն աշխատում է, նորից միացրեք էմուլյատորի սեփական ադապտերը իր փոխարկիչին և հաստատեք, որ VM-ը հասցե է ստանում։ Չմիացնեք VPN ադապտերը։ Մեկ անգամ էլ փորձարկեք և՛ էմուլյատորը, և՛ հաճախորդը նախքան գործն ավարտված համարելը։

Կառավարվող աշխատանքային կայանում ասեք ադմինիստրատորին, թե որ կապն եք փոխել։ Հետագա քաղաքականության թարմացումը կարող է վերականգնել հին կցումը, և կախումը կվերադառնա առանց ակնհայտ պատճառի։

Գրանցեք ադապտերի անունը, փոխարկիչը, որին այն կապված էր, և ipconfig վիճակը առաջ ու հետո։ Եթե կախումը վերադառնա թարմացումից հետո, այդ գրառումը հինգ րոպեի ստուգման և զրոյից սկսելու տարբերությունն է։

Առնչվող հոդվածներ