RDP спира след инсталиране на VPN клиент? Причината е защитната стена
Инсталаторът на потребителски VPN може да обърне профила на защитната стена на Windows и да прекъсне RDP. Върнете се през гостуващия агент, после стеснете правилото до порт 3389.
Минути след като потребителски VPN клиент завърши инсталацията, порталът все още твърди, че VM работи, публичният IP не е променен, а RDP не отговаря. Хората обикновено предполагат, че VM е паднала или че мрежовата група за сигурност е променена, и двете обикновено са грешни. Променил се е профилът на защитната стена на Windows, в който се намира машината, и правилото за RDP, което преди съвпадаше, вече не съвпада. Поправката започва с получаване на шел по път, който не зависи от RDP.
VM работи; правилото спря да съвпада
Правилата на защитната стена в Windows носят набор от профили и правило, ограничено до Частен или Домейн, не действа, докато машината е в Публичен профил. Инсталаторите на VPN добавят адаптери и маршрути и много от тях затягат Публичния профил като страничен ефект. Слушателят остава вързан към 3389 и пакетите все още пристигат, но несъответствието на профила ги отхвърля.
Състоянието на захранването и достъпността са отделни факти и работеща VM със затворен порт изглежда отвън точно като паднала.
Проверете порта, преди да промените каквото и да е. Опит за връзка към 3389, който приключва с изтичане на времето, докато команда на гостуващия агент все още връща изход, сочи към защитната стена на хоста. Порт, който отговаря, а RDP все още се проваля, означава, че повредата е над мрежовия слой и тази поправка няма да я докосне. Отбележете кой от двата случая видяхте, защото останалата част от плана зависи от това.
Две прегради се затварят независимо
Политиката на фабриката работи първа: мрежовата група за сигурност вижда пакета преди госта. Тази последователност прави безупречен запис в NSG безполезен, когато хостът отхвърли пакета, а отворено правило на хоста — безполезно, когато фабриката го откаже. Третирайте ги като отделни прегради и тествайте всяка сама.
Прочетете действащите правила на NSG в портала или CLI, после ги сравнете със собствените правила на госта. Не предполагайте, че последната промяна, която помните, е тази, която е влязла в сила.
Потребителски клиент може също да инсталира филтърен драйвер или ключ за убиване, който блокира трафика под защитната стена на Windows. Ако правилата изглеждат правилни, а портът все още се проваля, следващият заподозрян е този слой.
Използвайте гостуващия агент като път обратно
Две функции за отдалечено изпълнение, Run Command и Custom Script Extension, работят вътре в госта чрез агента на фабриката. Нито една не се нуждае от RDP, така че грешката със защитната стена не ги засяга. И двете връщат изхода на скрипта, което ги прави канал за диагностика и едновременно канал за поправка.
Прочетете активния профил и правилото за RDP, преди да промените което и да е от двете:
Get-NetConnectionProfile
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile
Повторното включване на входящи правила в този профил е временна мярка, а не цел. Използвайте го, за да получите сесия, после затворете пролуката както трябва:
Set-NetFirewallProfile -Name Public -AllowInboundRules True
Този превключвател отваря всяко входящо правило в профила, не само RDP. След като имате сесия, заменете го с ограничено правило и възстановете настройките, които наистина искате. Ако агентът също е недостъпен, резервният вариант е серийна конзола или пресъздаден диск и това е практическата причина да поддържате агента здрав.
Стеснете пролуката, преди да затворите сесията
Временната промяна на профила е врата, държана отворена за всяко входящо правило в този профил. Заменете я с правило, ограничено до вашия адрес на източника и порта RDP, после потвърдете, че профилът се е върнал в желаното състояние. Направете това, докато все още имате сесията, защото следващата грешка може да не е обратима отдалечено. Дръжте втори административен път, например Bastion или серийна конзола, по време на промяната.
Потвърдете резултата от работната си станция с тест на порта, а отвътре в госта — със списъка с правила:
Test-NetConnection -ComputerName 203.0.113.25 -Port 3389
Get-NetFirewallRule -DisplayName "RDP from admin" | Get-NetFirewallPortFilter
Включете регистриране на защитната стена за времетраенето на теста. Един ред за отхвърлен пакет, който посочва 3389 и активния профил, отговаря на въпроса по-бързо от още едно рестартиране.
Спрете следващия инсталатор да го направи отново
Ако този хост няма причина да пуска клиента, деинсталирайте го. Инсталираният клиент е постоянна покана следващата актуализация да пренапише профила отново и следващият човек ще отстранява същия проблем от портала.
Направете моментна снимка на диска, преди да позволите на нещо да пренапише мрежовите настройки, и дръжте втори административен път готов, преди да ви потрябва.
Запишете какво е променил инсталаторът: адаптери, маршрути, профили на защитната стена, филтърни драйвери и услуги. Този запис превръща следващия инцидент в известен модел вместо ново разследване. Когато VM се нуждае от тунел точно до една услуга, сложете клиента на работната си станция или изградете връзка между сайтове вместо да инсталирате на сървъра продукт за лаптопи. Потребителските клиенти са насочени към лаптопи, а сървър, който администрирате отдалечено, не е такъв.