IIS Manager-ի հեռակառավարում՝ նախ ստուգեք WMSVC-ի սեփական հասցեն

Ձեր կայքը պատասխանում է 443-ին թունելի միջով, և IIS Manager-ը դեռ չի կարողանում միանալ սերվերին։ Այս երկու արդյունքները հակասություն չեն, որովհետև վեբկայքը և հեռակառավարման վերջնակետը երկու լսողներ են՝ երկու կազմաձևով և մուտքի կանոնների երկու հավաքածուով։ Կառավարման լսողը պատկանում է վեբ կառավարման ծառայությանը՝ WMSVC-ին, և ունի իր հասցեն, պորտը, վկայականը և IPv4 սահմանափակումները։ Ստուգեք այդ վերջնակետը՝ նախքան որևէ երթուղու դիպչելը։

Երկու լսող, երկու տարբեր խնդիր

Կայքին ուղղված հարցումը հասնում է այդ կայքի HTTP.sys կապին, որը սահմանվում է յուրաքանչյուր կայքի և յուրաքանչյուր արձանագրության համար applicationHost կազմաձևում։ IIS Manager-ից եկող հարցումը հասնում է WMSVC-ին, որը լռելյայն պատասխանում է HTTPS-ով TCP 8172-ի վրա և կազմաձևվում է սերվերի մակարդակում։ Կայքի կապի մեջ ոչինչ չի փոխում, թե որտեղ է լսում WMSVC-ը, և WMSVC-ում ոչինչ չի փոխում, թե որ հասցեով է պատասխանում կայքը։ Նրանք կիսում են մեկ մեքենա և մեկ վկայականների պահոց, և այստեղ ավարտվում է նմանությունը։

Այսպիսով, հաջող Test-NetConnection 443 պորտի վրա ասում է, որ կայքի լսողը հասանելի է, և ոչինչ՝ կառավարման մասին։

Գտեք այն հասցեն, որին WMSVC-ը իրականում կապված է

Հարցրեք սերվերին, թե ինչի է այն լսում հիմա, ոչ թե ինչի լսելու համար էր կազմաձևվել տարիներ առաջ։ Get-NetTCPConnection -LocalPort 8172 -State Listen տպում է տեղական հասցեն, և 0.0.0.0 կամ :: արժեքը նշանակում է բոլոր հասցեները, մինչդեռ կոնկրետ հասցեն նշանակում է միայն այն։ Եթե սերվերի հասցեավորումը փոխվել է, ապա թոշակի անցած հասցեին դեռ ամրացված լսողը հենց այն խափանումն է, որը բռնում է այս ստուգումը։

Կազմաձևված արժեքը գտնվում է սերվերի հանգույցի IIS Manager-ի Management Service էջում, իսկ դրա հետևում՝ administration.config ֆայլում, inetsrv կազմաձևի պանակում։ Համեմատեք երկուսը՝ ինչ է ասում ֆայլը, և ինչին է սվոքը իրականում կապված։

Այնուհետև գործարկեք Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed տուժած VPN հաճախորդից և կարդացեք լուծված հասցեն և ընտրված աղբյուրի հասցեն։ VPN-ի միջոցով տարբեր DNS պատասխան բավական տարածված է, որ արժե վաղ բացառել։ Պահեք հենց այդ հոսթի անունը և պորտը տոմսի մեջ, քանի որ ավելի ուշ այլ անվան հետ համեմատությունը ոչինչ չի ապացուցում ձեր արած փոփոխության մասին։

Կարդացեք աղբյուրի հասցեն, որը տեսնում է սերվերը

WMSVC-ի IPv4 սահմանափակումները գնահատվում են սերվերին հասնող հասցեի նկատմամբ, և դա միշտ չէ այն հասցեն, որը ձեր նոթբուքը կարծում է, թե ունի։ Եթե VPN լողավազանը ճանապարհին ինչ-որ տեղ թարգմանվում է, սերվերը տեսնում է թարգմանված հասցեն, և հաճախորդի ներքին հասցեից կառուցված թույլատրելիների ցանկը կմերժի այն։ Այդ մերժումը հաճախորդի կողմից երևում է որպես միացման խափանում, և դրա համար էլ այն սխալմամբ ախտորոշվում է որպես երթուղավորման խնդիր։

Օգտագործեք TCP թեստի մանրամասն ելքը և սերվերի սեփական կապերի աղյուսակը՝ տեսնելու, թե որ աղբյուրի հասցեն իրականում հասավ, նախքան սահմանափակումների ցանկը խմբագրելը։

Փոխեք կապը որպես ծառայության փոփոխություն

WMSVC-ն պետք է կանգնեցվի նախքան դրա կազմաձևի խմբագրումը, ուստի պլանավորեք այն որպես փոփոխություն՝ կառավարման մեկ այլ ուղի հասանելի պահելով, օրինակ՝ վահանակի մուտք կամ հեռակա սեսիա, որը կախված չէ IIS Manager-ից։ Կանգնեցրեք ծառայությունը, կիրառեք հասցեի, պորտի կամ վկայականի փոփոխությունը, ապա գործարկեք այն և հաստատեք, որ լսողը տեղափոխվել է։ Ցանկացած մեկը, ով օգտագործում է IIS-ի հեռակա կառավարում, այդ պատուհանի ընթացքում կկորցնի իր սեսիան։ Ասացեք մյուս ադմինիստրատորներին նախքան պատուհանի բացվելը. այն փոփոխության կեսին հայտնաբերելը հենց այն է, ինչից երկու մարդ սկսում են խմբագրել նույն լսողին։

Բոլոր հասցեները ընտրելը օրինական տարբերակ է, բայց վերաբերվեք դրան որպես մուտքի որոշում, ոչ թե կարճ ճանապարհ։ Լսողի ընդլայնումը, մինչ սահմանափակումների ցանկը բաց է մնում, հենց այն է, ինչից կառավարման վերջնակետը հայտնվում է ցանցում, որը ոչ ոք չէր նախատեսել։ Եթե սերվերն ունի մի քանի ցանցային քարտ, սահմանափակեք լսողը կառավարման միջերեսով, թողեք տվյալների ուղին անփոփոխ և հաստատեք, որ կայքը դեռ պատասխանում է իր սեփական հասցեով։

WMSVC-ի ներկայացրած վկայականը ընտրվում է կայքի վկայականներից առանձին։ Եթե փոխեք հասցեն, հաստատեք, որ վկայականը դեռ համապատասխանում է հաճախորդների օգտագործած հոսթի անվանը, հակառակ դեպքում միացումը ավելի ուշ կձախողվի TLS քայլում՝ բողոքով, որը կապ չունի երթուղավորման հետ։

Առանձնացրեք հասանելիությունը վստահությունից և թույլտվություններից

Երբ TCP-ն հաջողվում է, մնացած խափանումները դասավորված են՝ TLS վստահություն կառավարման վկայականին, ապա Windows նույնականացում, ապա այդ հաշվին տրված IIS Manager թույլտվությունները։ Նրանցից յուրաքանչյուրը տարբեր սխալ է առաջացնում, և ոչ մեկը չի ուղղվում երթուղով կամ firewall կանոնով։ Կարդացեք սխալի տեքստը բառացիորեն՝ ծառայությունը նորից գործարկելու փոխարեն։

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