Аддаленае адміністраванне IIS Manager: спачатку праверце ўласны адрас WMSVC

Ваш сайт адказвае на 443 праз тунель, а IIS Manager усё яшчэ не можа падключыцца да сервера. Гэтыя два вынікі не супярэчаць адзін аднаму, бо вэб-сайт і канечны пункт аддаленага адміністравання — гэта два слухачы з двума канфігурацыямі і двума наборамі правілаў доступу. Кіраўнічы слухач належыць Службе кіравання вэб-сайтамі, WMSVC, і мае свой адрас, порт, сертыфікат і абмежаванні IPv4. Праверце гэты канечны пункт, перш чым кранаць хоць адзін маршрут.

Два слухачы, дзве розныя праблемы

Запыт да сайта даходзіць да прывязкі HTTP.sys для гэтага сайта, якая вызначаецца для кожнага сайта і кожнага пратакола ў канфігурацыі applicationHost. Запыт ад IIS Manager даходзіць да WMSVC, які па змаўчанні адказвае праз HTTPS на TCP 8172 і наладжваецца на ўзроўні сервера. Нішто ў прывязцы сайта не змяняе, дзе слухае WMSVC, і нішто ў WMSVC не змяняе, на які адрас адказвае сайт. Яны дзеляць адну машыну і адно сховішча сертыфікатаў, і на гэтым падабенства спыняецца.

Такім чынам, паспяховы Test-NetConnection на порце 443 кажа, што слухач сайта дасяжны, і зусім нічога не кажа пра кіраванне.

Знайдзіце адрас, да якога WMSVC сапраўды прывязаны

Спытайце ў сервера, што ён слухае зараз, а не што ён быў наладжаны слухаць гады таму. Get-NetTCPConnection -LocalPort 8172 -State Listen выводзіць лакальны адрас, і значэнне 0.0.0.0 або :: азначае ўсе адрасы, а канкрэтны адрас — толькі яго. Калі ў сервера змянілася адрасацыя, слухач, які ўсё яшчэ прывязаны да выведзенага з эксплуатацыі адраса, — гэта менавіта тая няспраўнасць, якую ловіць гэтая праверка.

Наладжанае значэнне знаходзіцца на старонцы Службы кіравання ў IIS Manager на вузле сервера, а за ёй — у administration.config у каталогу канфігурацыі inetsrv. Параўнайце дзве рэчы: што гаворыць файл і да чаго сапраўды прывязаны сокет.

Затым запусціце Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed з пацярпелага кліента VPN і прачытайце развязаны адрас і выбраны адрас крыніцы. Іншы адказ DNS праз VPN — звычайная справа, і яго варта выключыць як мага раней. Захавайце ў заяўцы менавіта гэтае імя хоста і порт, бо пазнейшае параўнанне з іншым імем нічога не дакажа пра зробленую змену.

Прачытайце адрас крыніцы, які бачыць сервер

Абмежаванні IPv4 у WMSVC ацэньваюцца па адрасе, які даходзіць да сервера, а гэта не заўсёды той адрас, які ваш ноўтбук лічыць сваім. Калі пул VPN дзесьці на шляху транслюецца, сервер бачыць трансляваны адрас, і спіс дазволаў, пабудаваны з унутранага адраса кліента, адхіліць яго. Гэтая адмова выглядае як збой падключэння з боку кліента, таму яе памылкова дыягнастуюць як праблему маршрутызацыі.

Выкарыстайце падрабязны вывад тэсту TCP і ўласную табліцу злучэнняў сервера, каб убачыць, які адрас крыніцы сапраўды прыйшоў, перш чым правіць спіс абмежаванняў.

Змяняйце прывязку як змену паслугі

WMSVC трэба спыніць, перш чым рэдагаваць яго канфігурацыю, таму плануйце гэта як змену з іншым даступным шляхам кіравання: доступ праз кансоль або аддаленую сесію, якая не залежыць ад IIS Manager. Спыніце паслугу, унясіце змену адраса, порта або сертыфіката, затым запусціце яе і пацвердзіце, што слухач перамясціўся. Усе, хто карыстаецца аддаленым адміністраваннем IIS, страцяць сесію на працягу гэтага акна. Папярэдзьце іншых адміністратараў да адкрыцця акна; выявіць гэта ў сярэдзіне змены — так два чалавекі пачынаюць рэдагаваць адзін і той жа слухач.

Выбраць усе адрасы — законны варыянт, але стаўцеся да гэтага як да рашэння аб доступе, а не як да хуткага шляху. Пашырэнне слухача пры адкрытым спісе абмежаванняў — гэта тое, як кіраўнічы канечны пункт аказваецца адкрытым у сетцы, якую ніхто не меў на ўвазе. Калі ў сервера некалькі сеткавых карт, абмяжуйце слухача інтэрфейсам кіравання, пакіньце шлях даных у спакоі і пацвердзіце, што сайт па-ранейшаму адказвае на сваім адрасе.

Сертыфікат, які падае WMSVC, выбіраецца асобна ад сертыфікатаў сайта. Калі вы змянілі адрас, пацвердзіце, што сертыфікат па-ранейшаму адпавядае імені хоста, якое выкарыстоўваюць кліенты, інакш падключэнне пазней збаіць на этапе TLS са скаргай, якая не мае нічога агульнага з маршрутызацыяй.

Аддзяліце дасяжнасць ад даверу і правоў

Пасля паспяховага TCP астатнія збоі ідуць па парадку: давер TLS да сертыфіката кіравання, затым аўтэнтыфікацыя Windows, затым правы IIS Manager, выдадзеныя гэтаму ўліковаму запісу. Кожны з іх дае розную памылку, і ні адзін не выпраўляецца маршрутам або правілам міжсеткавага экрана. Чытайце тэкст памылкі літаральна, замест таго каб зноў перазапускаць паслугу.

Прайдзіце чатыры праверкі ў гэтым парадку: канечны пункт, слухач, адрас крыніцы, давер, — і вы звычайна знойдзеце састарэлую прывязку раней, чым знойдзеце праблему сеткі.