IIS Manager ਰਿਮੋਟ ਪ੍ਰਬੰਧਨ: ਪਹਿਲਾਂ WMSVC ਦਾ ਆਪਣਾ ਪਤਾ ਜਾਂਚੋ

ਤੁਹਾਡੀ ਸਾਈਟ ਸੁਰੰਗ ਰਾਹੀਂ 443 'ਤੇ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਅਤੇ IIS Manager ਫਿਰ ਵੀ ਸਰਵਰ ਨਾਲ ਜੁੜ ਨਹੀਂ ਸਕਦਾ। ਇਹ ਦੋ ਨਤੀਜੇ ਵਿਰੋਧਾਭਾਸ ਨਹੀਂ ਹਨ, ਕਿਉਂਕਿ ਵੈੱਬਸਾਈਟ ਅਤੇ ਰਿਮੋਟ ਪ੍ਰਬੰਧਨ ਐਂਡਪੁਆਇੰਟ ਦੋ ਵੱਖਰੀਆਂ ਕਨਫਿਗਰੇਸ਼ਨਾਂ ਅਤੇ ਦੋ ਵੱਖਰੇ ਪਹੁੰਚ ਨਿਯਮ ਸਮੂਹਾਂ ਵਾਲੇ ਦੋ ਸਰੋਤੇ ਹਨ। ਪ੍ਰਬੰਧਨ ਵਾਲਾ ਸਰੋਤਾ Web Management Service, WMSVC ਦਾ ਹੈ ਅਤੇ ਇਸ ਦਾ ਆਪਣਾ ਪਤਾ, ਪੋਰਟ, ਸਰਟੀਫਿਕੇਟ ਅਤੇ IPv4 ਪਾਬੰਦੀਆਂ ਹਨ। ਇੱਕ ਵੀ ਰੂਟ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਐਂਡਪੁਆਇੰਟ ਦੀ ਜਾਂਚ ਕਰੋ।

ਦੋ ਸਰੋਤੇ, ਦੋ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ

ਸਾਈਟ ਲਈ ਬੇਨਤੀ ਉਸ ਸਾਈਟ ਦੀ HTTP.sys ਬਾਈਂਡਿੰਗ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ, ਜੋ applicationHost ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਹਰ ਸਾਈਟ ਅਤੇ ਹਰ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਪਰਿਭਾਸ਼ਿਤ ਹੁੰਦੀ ਹੈ। IIS Manager ਤੋਂ ਬੇਨਤੀ WMSVC ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ, ਜੋ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ TCP 8172 'ਤੇ HTTPS ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸਰਵਰ ਪੱਧਰ 'ਤੇ ਕਨਫਿਗਰ ਹੁੰਦਾ ਹੈ। ਸਾਈਟ ਦੀ ਬਾਈਂਡਿੰਗ ਵਿੱਚ ਕੁਝ ਵੀ ਇਹ ਨਹੀਂ ਬਦਲਦਾ ਕਿ WMSVC ਕਿੱਥੇ ਸੁਣਦਾ ਹੈ, ਅਤੇ WMSVC ਵਿੱਚ ਕੁਝ ਵੀ ਇਹ ਨਹੀਂ ਬਦਲਦਾ ਕਿ ਸਾਈਟ ਕਿਸ ਪਤੇ 'ਤੇ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਉਹ ਇੱਕ ਮਸ਼ੀਨ ਅਤੇ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਸਟੋਰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਸਮਾਨਤਾ ਉੱਥੇ ਖਤਮ ਹੁੰਦੀ ਹੈ।

ਇਸ ਲਈ ਪੋਰਟ 443 'ਤੇ ਸਫਲ Test-NetConnection ਦੱਸਦਾ ਹੈ ਕਿ ਸਾਈਟ ਦਾ ਸਰੋਤਾ ਪਹੁੰਚਯੋਗ ਹੈ, ਅਤੇ ਪ੍ਰਬੰਧਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।

ਉਹ ਪਤਾ ਲੱਭੋ ਜਿਸ ਨਾਲ WMSVC ਅਸਲ ਵਿੱਚ ਬੱਝਿਆ ਹੋਇਆ ਹੈ

ਸਰਵਰ ਨੂੰ ਪੁੱਛੋ ਕਿ ਉਹ ਹੁਣ ਕੀ ਸੁਣ ਰਿਹਾ ਹੈ, ਨਾ ਕਿ ਕਈ ਸਾਲ ਪਹਿਲਾਂ ਕੀ ਕਨਫਿਗਰ ਕੀਤਾ ਗਿਆ ਸੀ। Get-NetTCPConnection -LocalPort 8172 -State Listen ਸਥਾਨਕ ਪਤਾ ਛਾਪਦਾ ਹੈ, ਅਤੇ 0.0.0.0 ਜਾਂ :: ਮੁੱਲ ਦਾ ਮਤਲਬ ਸਾਰੇ ਪਤੇ ਹਨ, ਜਦਕਿ ਖਾਸ ਪਤਾ ਦਾ ਮਤਲਬ ਸਿਰਫ ਉਹੀ ਹੈ। ਜੇ ਸਰਵਰ ਦੇ ਪਤੇ ਬਦਲੇ ਗਏ ਹਨ, ਤਾਂ ਰਿਟਾਇਰ ਹੋਏ ਪਤੇ ਨਾਲ ਅਜੇ ਵੀ ਜੁੜਿਆ ਸਰੋਤਾ ਠੀਕ ਉਹੀ ਖਰਾਬੀ ਹੈ ਜੋ ਇਹ ਜਾਂਚ ਫੜਦੀ ਹੈ।

ਕਨਫਿਗਰ ਕੀਤਾ ਮੁੱਲ ਸਰਵਰ ਨੋਡ 'ਤੇ IIS Manager ਦੇ Management Service ਸਫੇ 'ਤੇ ਹੈ, ਅਤੇ ਇਸ ਦੇ ਪਿੱਛੇ inetsrv ਕਨਫਿਗਰੇਸ਼ਨ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ administration.config ਵਿੱਚ। ਦੋਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ: ਫਾਈਲ ਕੀ ਕਹਿੰਦੀ ਹੈ, ਅਤੇ ਸਾਕਟ ਅਸਲ ਵਿੱਚ ਕਿਸ ਨਾਲ ਬੱਝਿਆ ਹੈ।

ਫਿਰ ਪ੍ਰਭਾਵਿਤ VPN ਕਲਾਇੰਟ ਤੋਂ Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed ਚਲਾਓ ਅਤੇ ਹੱਲ ਹੋਇਆ ਪਤਾ ਅਤੇ ਚੁਣਿਆ ਸਰੋਤ ਪਤਾ ਪੜ੍ਹੋ। VPN 'ਤੇ ਵੱਖਰਾ DNS ਜਵਾਬ ਆਮ ਹੈ, ਇਸ ਲਈ ਜਲਦੀ ਬਾਹਰ ਕਰਨਾ ਲਾਭਦਾਇਕ ਹੈ। ਟਿਕਟ ਵਿੱਚ ਉਹੀ ਸਹੀ ਹੋਸਟਨਾਮ ਅਤੇ ਪੋਰਟ ਰੱਖੋ, ਕਿਉਂਕਿ ਬਾਅਦ ਵਿੱਚ ਕਿਸੇ ਹੋਰ ਨਾਮ ਨਾਲ ਤੁਲਨਾ ਕਰਨਾ ਤੁਹਾਡੇ ਕੀਤੇ ਬਦਲਾਅ ਦਾ ਕੋਈ ਸਬੂਤ ਨਹੀਂ ਦਿੰਦਾ।

ਸਰਵਰ ਜੋ ਸਰੋਤ ਪਤਾ ਦੇਖਦਾ ਹੈ ਉਹ ਪੜ੍ਹੋ

WMSVC ਦੀਆਂ IPv4 ਪਾਬੰਦੀਆਂ ਸਰਵਰ 'ਤੇ ਪਹੁੰਚਣ ਵਾਲੇ ਪਤੇ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ, ਜੋ ਹਮੇਸ਼ਾ ਉਹ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਜੋ ਤੁਹਾਡਾ ਲੈਪਟਾਪ ਆਪਣੇ ਕੋਲ ਮੰਨਦਾ ਹੈ। ਜੇ ਰਸਤੇ ਵਿੱਚ ਕਿਤੇ VPN ਪੂਲ ਦਾ ਅਨੁਵਾਦ ਹੋਵੇ, ਤਾਂ ਸਰਵਰ ਅਨੁਵਾਦਿਤ ਪਤਾ ਦੇਖਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਦੇ ਅੰਦਰੂਨੀ ਪਤੇ ਤੋਂ ਬਣੀ ਮਨਜ਼ੂਰੀ ਸੂਚੀ ਉਸ ਨੂੰ ਰੱਦ ਕਰੇਗੀ। ਇਹ ਰੱਦ ਕਰਨਾ ਕਲਾਇੰਟ ਪਾਸੋਂ ਕਨੈਕਸ਼ਨ ਫੇਲ੍ਹ ਹੋਣ ਵਾਂਗ ਦਿਸਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਅਕਸਰ ਰਾਊਟਿੰਗ ਸਮੱਸਿਆ ਵਜੋਂ ਗਲਤ ਨਿਦਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਪਾਬੰਦੀ ਸੂਚੀ ਨੂੰ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਦੇਖਣ ਲਈ ਕਿ ਕਿਹੜਾ ਸਰੋਤ ਪਤਾ ਅਸਲ ਵਿੱਚ ਪਹੁੰਚਿਆ, TCP ਟੈਸਟ ਦਾ ਵਿਸਥਾਰਿਤ ਆਉਟਪੁੱਟ ਅਤੇ ਸਰਵਰ ਦੀ ਆਪਣੀ ਕਨੈਕਸ਼ਨ ਸਾਰਣੀ ਵਰਤੋ।

ਬਾਈਂਡਿੰਗ ਨੂੰ ਸੇਵਾ ਬਦਲਾਅ ਵਜੋਂ ਬਦਲੋ

WMSVC ਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਨੂੰ ਰੋਕਣਾ ਪੈਂਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਕੰਸੋਲ ਪਹੁੰਚ ਜਾਂ IIS Manager 'ਤੇ ਨਿਰਭਰ ਨਾ ਕਰਨ ਵਾਲੇ ਰਿਮੋਟ ਸੈਸ਼ਨ ਵਰਗੇ ਦੂਜੇ ਉਪਲਬਧ ਪ੍ਰਬੰਧਨ ਰਸਤੇ ਵਾਲੇ ਬਦਲਾਅ ਵਜੋਂ ਯੋਜਨਾ ਬਣਾਓ। ਸੇਵਾ ਰੋਕੋ, ਪਤਾ, ਪੋਰਟ ਜਾਂ ਸਰਟੀਫਿਕੇਟ ਬਦਲਾਅ ਲਾਗੂ ਕਰੋ, ਫਿਰ ਇਸ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਰੋਤਾ ਹਿਲ ਗਿਆ ਹੈ। ਉਸ ਸਮੇਂ ਦੌਰਾਨ ਰਿਮੋਟ IIS ਪ੍ਰਬੰਧਨ ਵਰਤਣ ਵਾਲਾ ਹਰ ਹੋਰ ਵਿਅਕਤੀ ਆਪਣਾ ਸੈਸ਼ਨ ਗੁਆ ਦਿੰਦਾ ਹੈ। ਸਮਾਂ ਖੁੱਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਹੋਰ ਪ੍ਰਬੰਧਕਾਂ ਨੂੰ ਦੱਸੋ; ਬਦਲਾਅ ਦੇ ਵਿਚਕਾਰ ਇਹ ਪਤਾ ਲੱਗਣਾ ਹੀ ਦੋ ਲੋਕਾਂ ਦੇ ਇੱਕੋ ਸਰੋਤੇ ਨੂੰ ਸੋਧਣ ਦਾ ਰਾਹ ਹੈ।

ਸਾਰੇ ਪਤੇ ਚੁਣਨਾ ਜਾਇਜ਼ ਵਿਕਲਪ ਹੈ, ਪਰ ਇਸ ਨੂੰ ਸ਼ਾਰਟਕਟ ਨਹੀਂ, ਪਹੁੰਚ ਫੈਸਲਾ ਸਮਝੋ। ਪਾਬੰਦੀ ਸੂਚੀ ਖੁੱਲ੍ਹੀ ਰਹਿੰਦਿਆਂ ਸਰੋਤੇ ਨੂੰ ਚੌੜਾ ਕਰਨਾ ਹੀ ਅਜਿਹਾ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਪ੍ਰਬੰਧਨ ਐਂਡਪੁਆਇੰਟ ਕਿਸੇ ਦੇ ਵੀ ਨਾ ਸੋਚੇ ਨੈੱਟਵਰਕ 'ਤੇ ਖੁੱਲ੍ਹਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਜੇ ਸਰਵਰ ਵਿੱਚ ਕਈ NIC ਹਨ, ਤਾਂ ਸਰੋਤੇ ਨੂੰ ਪ੍ਰਬੰਧਨ ਇੰਟਰਫੇਸ ਤੱਕ ਸੀਮਿਤ ਕਰੋ, ਡੇਟਾ ਰਸਤੇ ਨੂੰ ਛੇੜੋ ਨਾ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਾਈਟ ਅਜੇ ਵੀ ਆਪਣੇ ਪਤੇ 'ਤੇ ਜਵਾਬ ਦਿੰਦੀ ਹੈ।

WMSVC ਜੋ ਸਰਟੀਫਿਕੇਟ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਉਹ ਸਾਈਟ ਦੇ ਸਰਟੀਫਿਕੇਟਾਂ ਤੋਂ ਵੱਖਰਾ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਪਤਾ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਰਟੀਫਿਕੇਟ ਅਜੇ ਵੀ ਕਲਾਇੰਟਾਂ ਦੇ ਵਰਤੇ ਹੋਸਟਨਾਮ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਕਨੈਕਸ਼ਨ ਬਾਅਦ ਵਿੱਚ TLS ਪੜਾਅ 'ਤੇ ਰਾਊਟਿੰਗ ਨਾਲ ਕੋਈ ਸਬੰਧ ਨਾ ਰੱਖਣ ਵਾਲੀ ਸ਼ਿਕਾਇਤ ਨਾਲ ਫੇਲ੍ਹ ਹੋਵੇਗਾ।

ਪਹੁੰਚਯੋਗਤਾ ਨੂੰ ਭਰੋਸੇ ਅਤੇ ਇਜਾਜ਼ਤਾਂ ਤੋਂ ਵੱਖ ਕਰੋ

ਇੱਕ ਵਾਰ TCP ਸਫਲ ਹੋ ਜਾਣ 'ਤੇ, ਬਾਕੀ ਖਰਾਬੀਆਂ ਕ੍ਰਮ ਵਿੱਚ ਹੁੰਦੀਆਂ ਹਨ: ਪ੍ਰਬੰਧਨ ਸਰਟੀਫਿਕੇਟ ਲਈ TLS ਭਰੋਸਾ, ਫਿਰ Windows ਪ੍ਰਮਾਣੀਕਰਨ, ਫਿਰ ਉਸ ਖਾਤੇ ਨੂੰ ਦਿੱਤੀਆਂ IIS Manager ਇਜਾਜ਼ਤਾਂ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵੱਖਰੀ ਗਲਤੀ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਰੂਟ ਜਾਂ ਫਾਇਰਵਾਲ ਨਿਯਮ ਨਾਲ ਠੀਕ ਨਹੀਂ ਹੁੰਦਾ। ਸੇਵਾ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਬਜਾਏ ਗਲਤੀ ਦਾ ਪਾਠ ਸ਼ਬਦੀ ਪੜ੍ਹੋ।

ਉਸ ਕ੍ਰਮ ਵਿੱਚ ਚਾਰ ਜਾਂਚਾਂ ਕਰੋ: ਐਂਡਪੁਆਇੰਟ, ਸਰੋਤਾ, ਸਰੋਤ ਪਤਾ, ਭਰੋਸਾ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆ ਤੋਂ ਪਹਿਲਾਂ ਪੁਰਾਣੀ ਬਾਈਂਡਿੰਗ ਮਿਲ ਜਾਂਦੀ ਹੈ।