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 అనుమతులు. వాటిలో ప్రతి ఒక్కటి వేరే లోపాన్ని ఇస్తుంది, ఏదీ మార్గం లేదా ఫైర్వాల్ నియమంతో సరిచేయబడదు. సేవను మళ్లీ ప్రారంభించడం బదులు లోపం వచనాన్ని అక్షరాలా చదవండి.

ఆ క్రమంలో నాలుగు తనిఖీలు చేయండి: ఎండ్పాయింట్, శ్రోత, మూల చిరునామా, విశ్వాసం, సాధారణంగా నెట్వర్క్ సమస్యకు ముందు పాత బైండింగ్ను కనుగొంటారు.