IIS Manager રિમોટ એડમિન: પહેલાં WMSVCનું પોતાનું સરનામું તપાસો

તમારી સાઇટ ટનલ દ્વારા 443 પર જવાબ આપે છે, અને IIS Manager તો પણ સર્વર સાથે કનેક્ટ થઈ શકતું નથી. આ બે પરિણામો વિરોધાભાસ નથી, કારણ કે વેબસાઇટ અને રિમોટ એડમિનિસ્ટ્રેશન એન્ડપોઇન્ટ બે અલગ ગોઠવણી અને બે અલગ એક્સેસ નિયમો ધરાવતા બે શ્રોતા છે. એડમિનિસ્ટ્રેશન શ્રોતા વેબ મેનેજમેન્ટ સર્વિસનો છે, એટલે કે WMSVCનો, અને તેનું પોતાનું સરનામું, પોર્ટ, પ્રમાણપત્ર અને IPv4 પ્રતિબંધો છે. કોઈપણ રૂટને અડવા પહેલાં એ એન્ડપોઇન્ટ તપાસો.

બે શ્રોતા, બે અલગ સમસ્યાઓ

સાઇટ પરની વિનંતી તે સાઇટની HTTP.sys બાઇન્ડિંગ સુધી પહોંચે છે, જે applicationHost ગોઠવણીમાં દરેક સાઇટ અને દરેક પ્રોટોકોલ માટે વ્યાખ્યાયિત થાય છે. IIS Managerની વિનંતી WMSVC સુધી પહોંચે છે, જે ડિફોલ્ટ રીતે TCP 8172 પર HTTPS જવાબ આપે છે અને સર્વર સ્તરે ગોઠવાય છે. સાઇટની બાઇન્ડિંગમાં કંઈપણ WMSVC ક્યાં સાંભળે છે તે બદલતું નથી, અને WMSVCમાં કંઈપણ સાઇટ કયા સરનામે જવાબ આપે છે તે બદલતું નથી. તેઓ એક મશીન અને એક પ્રમાણપત્ર સ્ટોર વહેંચે છે, અને સામ્ય ત્યાં જ પૂરું થાય છે.

એટલે સફળ Test-NetConnection પોર્ટ 443 પર કહે છે કે સાઇટનો શ્રોતા પહોંચી શકાય તેવો છે, અને એડમિનિસ્ટ્રેશન વિશે કંઈ જ નહીં.

WMSVC ખરેખર કયા સરનામે બંધાયેલું છે તે શોધો

સર્વરને પૂછો કે તે હવે શું સાંભળે છે, વર્ષો પહેલાં શું સાંભળવા માટે ગોઠવાયું હતું તે નહીં. Get-NetTCPConnection -LocalPort 8172 -State Listen સ્થાનિક સરનામું છાપે છે, અને 0.0.0.0 અથવા :: નું મૂલ્ય બધા સરનામાં દર્શાવે છે, જ્યારે ચોક્કસ સરનામું ફક્ત તે જ દર્શાવે છે. જો સર્વરનું સરનામું બદલાયું હોય, તો નિવૃત્ત સરનામે હજી પિન થયેલો શ્રોતા એ જ ખામી છે જે આ તપાસ પકડે છે.

ગોઠવેલું મૂલ્ય સર્વર નોડ પર IIS Managerના Management Service પૃષ્ઠ પર રહે છે, અને તેની પાછળ administration.config ફાઇલમાં, inetsrv ગોઠવણી ડિરેક્ટરીમાં. બંને સરખાવો: ફાઇલ શું કહે છે, અને સોકેટ ખરેખર શેના સાથે બંધાયેલું છે.

પછી અસરગ્રસ્ત VPN ક્લાયંટ પરથી Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed ચલાવો અને ઉકેલાયેલું સરનામું તથા પસંદ કરેલું સ્રોત સરનામું વાંચો. VPN પર અલગ DNS જવાબ પૂરતો સામાન્ય છે, તેથી તેને વહેલા બાકાત કરવો યોગ્ય છે. ટિકિટમાં બરાબર એ જ હોસ્ટનામ અને પોર્ટ રાખો, કારણ કે પછી બીજા નામ સાથેની સરખામણી તમે કરેલા ફેરફાર વિશે કંઈ સાબિત કરતી નથી.

સર્વર જે સ્રોત સરનામું જુએ છે તે વાંચો

WMSVCના IPv4 પ્રતિબંધો સર્વર પર પહોંચતા સરનામા સામે મૂલ્યાંકન થાય છે, અને તે હંમેશા એ સરનામું નથી જે તમારો લેપટોપ પોતાનું માને છે. જો VPN પૂલ માર્ગમાં ક્યાંક અનુવાદિત થાય, તો સર્વર અનુવાદિત સરનામું જુએ છે અને ક્લાયંટના આંતરિક સરનામેથી બનેલી મંજૂરી યાદી તેને નકારશે. એ નકાર ક્લાયંટની બાજુથી કનેક્શન નિષ્ફળતા જેવો લાગે છે, અને તેથી જ તેને ખોટી રીતે રૂટિંગ સમસ્યા તરીકે નિદાન કરવામાં આવે છે.

પ્રતિબંધ યાદી સંપાદિત કરતા પહેલાં કયું સ્રોત સરનામું ખરેખર આવ્યું તે જોવા માટે TCP પરીક્ષણનું વિગતવાર આઉટપુટ અને સર્વરનું પોતાનું કનેક્શન ટેબલ વાપરો.

બાઇન્ડિંગને સેવા ફેરફાર તરીકે બદલો

WMSVCની ગોઠવણી સંપાદિત કરતા પહેલાં સેવા બંધ કરવી પડે, તેથી તેને એવા ફેરફાર તરીકે યોજો જેમાં બીજો એડમિનિસ્ટ્રેશન માર્ગ ઉપલબ્ધ હોય, જેમ કે કન્સોલ એક્સેસ અથવા IIS Manager પર આધારિત ન હોય તેવું રિમોટ સેશન. સેવા બંધ કરો, સરનામું, પોર્ટ અથવા પ્રમાણપત્રનો ફેરફાર લાગુ કરો, પછી તેને ચાલુ કરો અને ખાતરી કરો કે શ્રોતા ખસ્યો છે. રિમોટ IIS એડમિનિસ્ટ્રેશન વાપરતા બીજા કોઈપણ વ્યક્તિનું સેશન તે સમયગાળામાં જતું રહેશે. સમયગાળો ખુલે તે પહેલાં બીજા એડમિનિસ્ટ્રેટરોને જણાવો; ફેરફારની વચ્ચે તે શોધવો એ જ રીતે બે લોકો એક જ શ્રોતાને સંપાદિત કરતા થાય છે.

બધા સરનામાં પસંદ કરવા એ કાયદેસર વિકલ્પ છે, પણ તેને શોર્ટકટ નહીં, એક્સેસ નિર્ણય તરીકે લો. પ્રતિબંધ યાદી ખુલ્લી રહેતાં શ્રોતાને પહોળો કરવો એ જ રીતે એડમિનિસ્ટ્રેશન એન્ડપોઇન્ટ એવા નેટવર્ક પર ખુલ્લો થાય છે જે કોઈએ ઇચ્છ્યું ન હતું. જો સર્વરમાં અનેક નેટવર્ક કાર્ડ હોય, તો શ્રોતાને એડમિનિસ્ટ્રેશન ઇન્ટરફેસ સુધી મર્યાદિત કરો, ડેટા માર્ગને અકબંધ રાખો, અને ખાતરી કરો કે સાઇટ હજી પોતાના સરનામે જવાબ આપે છે.

WMSVC જે પ્રમાણપત્ર રજૂ કરે છે તે સાઇટના પ્રમાણપત્રોથી અલગ રીતે પસંદ થાય છે. જો તમે સરનામું બદલો, તો ખાતરી કરો કે પ્રમાણપત્ર હજી ક્લાયંટ વાપરતા હોસ્ટનામ સાથે મેળ ખાય છે, નહીં તો કનેક્શન પછીથી TLS પગલે નિષ્ફળ જશે એવી ફરિયાદ સાથે જેનો રૂટિંગ સાથે કોઈ સંબંધ નથી.

પહોંચને વિશ્વાસ અને પરવાનગીઓથી અલગ કરો

TCP સફળ થયા પછી બાકીની નિષ્ફળતાઓ ક્રમમાં છે: એડમિનિસ્ટ્રેશન પ્રમાણપત્ર માટે TLS વિશ્વાસ, પછી Windows પ્રમાણીકરણ, પછી તે ખાતાને આપેલી IIS Manager પરવાનગીઓ. દરેક અલગ ભૂલ આપે છે, અને એક પણ રૂટ કે ફાયરવોલ નિયમથી સુધરતી નથી. સેવા ફરી ચાલુ કરવાને બદલે ભૂલનું લખાણ શબ્દશઃ વાંચો.

ચાર તપાસો એ જ ક્રમમાં કરો, એન્ડપોઇન્ટ, શ્રોતા, સ્રોત સરનામું, વિશ્વાસ, અને સામાન્ય રીતે નેટવર્ક સમસ્યા શોધતા પહેલાં જૂની બાઇન્ડિંગ મળી જશે.