Zure guneak 443an erantzuten du tunelaren bidez, eta IIS Managerrek oraindik ezin du zerbitzarira konektatu. Bi emaitza horiek ez dira kontraesana, gunea eta urruneko administrazioaren amaiera-puntua bi entzule baitira, bi konfigurazio eta sarbide-arauen bi multzorekin. Kudeaketa-entzulea Web Management Service zerbitzuarena da, WMSVC, eta bere helbidea, ataka, ziurtagiria eta IPv4 murrizketak ditu. Egiaztatu amaiera-puntu hori ibilbide bakarra ukitu aurretik.

Bi entzule, bi arazo desberdin

Gunera egindako eskaera gune horren HTTP.sys loturara iristen da, eta lotura hori gune eta protokolo bakoitzeko definitzen da applicationHost konfigurazioan. IIS Managerren eskaera WMSVCra iristen da, eta horrek lehenespenez HTTPS erantzuten du TCP 8172an eta zerbitzari mailan konfiguratzen da. Guneko loturan ezerk ez du aldatzen WMSVCk non entzuten duen, eta WMSVCn ezerk ez du aldatzen guneak zein helbidetan erantzuten duen. Makina bat eta ziurtagiri biltegi bat partekatzen dituzte, eta han amaitzen da antzekotasuna.

Beraz, Test-NetConnection arrakastatsu batek 443 atakan esaten dizu gunearen entzulea irisgarria dela, eta ezer ez kudeaketaz.

Aurkitu WMSVC benetan lotuta dagoen helbidea

Galdetu zerbitzariari orain zer entzuten duen, duela urte batzuk zer entzuteko konfiguratu zen ez baizik. Get-NetTCPConnection -LocalPort 8172 -State Listen tokiko helbidea inprimatzen du, eta 0.0.0.0 edo :: balioak helbide guztiak esan nahi ditu, helbide zehatz batek soilik hura esan nahi duen bitartean. Zerbitzari bati helbideratzea aldatu bazaio, erretiratutako helbide bati oraindik itsatsita dagoen entzulea da egiaztapen honek harrapatzen duen hutsegitea.

Konfiguratutako balioa zerbitzari-nodoan IIS Managerren Management Service orrian dago, eta haren atzean administration.config fitxategian, inetsrv konfigurazio direktorioan. Konparatu biak: fitxategiak zer dioen eta socketak zerari lotuta dagoen.

Ondoren exekutatu Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed kaltetutako VPN bezeroan eta irakurri ebatzitako helbidea eta hautatutako iturburu-helbidea. VPN bidezko DNS erantzun desberdina nahiko ohikoa da goiz baztertzeko. Gorde host-izen eta ataka zehatz horiek tiketeko, geroago beste izen batekin egindako konparaketak ez baitu ezer frogatzen egin duzun aldaketaz.

Irakurri zerbitzariak ikusten duen iturburu-helbidea

WMSVCren IPv4 murrizketak zerbitzarira iristen den helbidearen aurka ebaluatzen dira, eta ez da beti zure eramangarriak duela uste duen helbidea. VPN igerilekua bidean nonbait itzultzen bada, zerbitzariak itzulitako helbidea ikusten du, eta bezeroaren barne-helbidetik eraikitako baimenduen zerrendak ukatuko du. Ukapen horrek bezeroaren aldetik konexio-hutsegitea dirudi, eta horregatik oker diagnostikatzen da bideratze-arazo gisa.

Erabili TCP probaren irteera xehea eta zerbitzariaren beraren konexio-taula jakiteko zein iturburu-helbide iritsi zen benetan murrizketa-zerrenda editatu aurretik.

Aldatu lotura zerbitzu-aldaketa gisa

WMSVC gelditu behar da haren konfigurazioa editatu aurretik, beraz planifikatu ezazu beste kudeaketa-bide bat eskura duen aldaketa gisa, hala nola kontsolako sarbidea edo IIS Managerren menpe ez dagoen urruneko saioa. Gelditu zerbitzua, aplikatu helbide, ataka edo ziurtagiriaren aldaketa, gero abiarazi eta egiaztatu entzulea mugitu dela. IIS urruneko administrazioa erabiltzen duen edonork galduko du saioa leiho horretan. Esan beste administratzaileei leihoa ireki aurretik; aldaketaren erdian aurkitzea da bi pertsona entzule bera editatzen amaitzeko modua.

Helbide guztiak hautatzea legezko aukera da, baina tratatu sarbide-erabaki gisa, ez lasterbide gisa. Entzulea zabaltzea murrizketa-zerrenda irekita dagoela da kudeaketa-amaiera-puntua inork nahi ez zuen sare batean agerian geratzeko modua. Zerbitzariak hainbat sare-txartel baditu, mugatu entzulea kudeaketa-interfazera, utzi datu-bidea bakean, eta egiaztatu guneak bere helbidean erantzuten jarraitzen duela.

WMSVCk aurkezten duen ziurtagiria guneko ziurtagirietatik bereiz hautatzen da. Helbidea aldatzen baduzu, egiaztatu ziurtagiria oraindik bezeroek erabiltzen duten host-izenarekin bat datorrela, bestela konexioak TLS urratsean huts egingo du bideratzearekin zerikusirik ez duen kexa batekin.

Bereizi irisgarritasuna konfiantzatik eta baimenetatik

TCP lortu ondoren, gainerako hutsegiteak ordenatuta daude: kudeaketa-ziurtagiriaren TLS konfiantza, gero Windows autentifikazioa, gero kontu horri emandako IIS Manager baimenak. Bakoitzak errore desberdina sortzen du, eta bat ere ez da konpontzen ibilbide edo suebaki-arau batekin. Irakurri errore-testua literalki zerbitzua berriro abiarazi beharrean.

Egin lau egiaztapenak ordena horretan, amaiera-puntua, entzulea, iturburu-helbidea, konfiantza, eta normalean zaharkitutako lotura aurkituko duzu sare-arazoa aurkitu aurretik.

Erlazionatutako artikuluak