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 ಅನುಮತಿಗಳು. ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ದೋಷವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ ಮತ್ತು ಯಾವುದೂ ಮಾರ್ಗ ಅಥವಾ ಫೈರ್ವಾಲ್ ನಿಯಮದಿಂದ ಸರಿಪಡಿಸುವುದಿಲ್ಲ. ಸೇವೆಯನ್ನು ಮತ್ತೆ ಮರುಪ್ರಾರಂಭಿಸುವ ಬದಲು ದೋಷ ಪಠ್ಯವನ್ನು ಅಕ್ಷರಶಃ ಓದಿ.

ನಾಲ್ಕು ಪರಿಶೀಲನೆಗಳನ್ನು ಆ ಕ್ರಮದಲ್ಲಿ ಮಾಡಿ: ಎಂಡ್ಪಾಯಿಂಟ್, ಶ್ರೋತೃ, ಮೂಲ ವಿಳಾಸ, ವಿಶ್ವಾಸ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆಗಿಂತ ಮೊದಲು ಹಳೆಯ ಬೈಂಡಿಂಗ್ ಸಿಗುತ್ತದೆ.