Защо RDP замръзва, когато отдалеченият компютър се свърже към VPN

VPN се свързва успешно, а работният плот замръзва: тунелът промени обратния път на сесията ви. Първо запишете адреса на партньора, маршрута и профила на защитната стена.

Вие сте в прозореца на RDP, на екрана е работният плот и натискате Connect в VPN клиента, който работи на онази отдалечена машина. Секунди по-късно прозорецът замръзва и после се затваря. Тунелът се вдигна, точно това ще отбележи VPN журналът, и това е най-малко полезният факт в целия инцидент. Сесията загина, защото машината, с която разговаряхте, промени начина, по който ви отговаря, затова проверете обратния път, преди да пипате тунела.

Отбележете крайната точка, която сесията ви реално използва

Адресът, въведен в RDP клиента, не е задължително адресът, на който отдалеченият компютър отговаря. NAT, RD Gateway или балансьор на натоварването пред хоста могат да го пренапишат, а обратният път се определя от адреса на източника, който отдалечената машина вижда по установената връзка. Грешка тук ви изпраща да търсите маршрут, който никога не е участвал.

На отдалечения компютър, преди VPN да е свързан, избройте установените сесии и прочетете адреса на партньора от таблицата. После го запишете някъде извън тази машина, защото няма да можете да го прочетете, след като сесията падне.

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

Приемайте този адрес като нещото, което трябва да остане достъпно. Ако е частен адрес в управленски VLAN, тунелът трябва да остави този път на мира. Ако е публичен адрес, отговорът трябва да излезе през същия интерфейс, който е внесъл заявката.

Прочетете маршрута, който отговаря на тази крайна точка

Windows избира интерфейс за всяка дестинация и Find-NetRoute показва решението, което би взел в момента. Пуснете го за адреса на партньора преди свързване, после отново с вдигнат тунел, и сравнете индекса на интерфейса и следващия хоп в двата отговора. Смяната на интерфейса е целият дефект в един ред изход.

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

Профилът за пълен тунел инсталира маршрут по подразбиране през тунела, както описва ръководството на Windows за маршрутизиране на VPN, затова всеки отговор вече излиза през VPN и зависи от това дали отсрещната страна маршрутизира обратно към вашия клиент. Профилът за разделен тунел е по-безопасен по подразбиране, но не е имунизиран, защото конкретен маршрут, който покрива адреса на партньора, все още може да победи физическия маршрут по подразбиране. Както и да е, въпросът е идентичен: след като тунелът се вдигне, адресът на партньора все още ли се разрешава до интерфейса, който е внесъл сесията?

Ако не, поправката е в профила или в изричен изключващ маршрут, одобрен от собственика на VPN политиката. Ръчното редактиране на маршрутната таблица на продукционен хост по време на инцидент е начинът, по който временно заобикаляне се превръща в недокументирана конфигурация.

Следете смяната на профила на защитната стена

Новият интерфейс се класифицира, когато се появи, и класификацията решава по кой профил на защитната стена се оценява трафикът му. Тунелен адаптер, който попадне в категория Public, може тихо да спре входящия RDP, дори маршрутната таблица да изглежда безупречна. Това е вторият режим на отказ и дава различен симптом: маршрутът е верен, пакетите пристигат, а хостът отказва връзката.

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

Сравнете профила, прикачен към тунелния интерфейс, с профилите, за които са обхванати правилата на Remote Desktop. Правило, включено само за Domain и Private, не прави нищо за интерфейс, класифициран като Public, и никаква корекция на маршрута не променя това. Някои VPN клиенти също по дизайн ограничават достъпа до локалната подмрежа, което дава същата форма на отказ от различен контрол.

Тествайте прехода от място, от което можете да се възстановите

Изпълнете цялата последователност от извънлентова конзола или втори път за управление, в този ред: потвърдете съществуващата сесия, свържете VPN, отворете нова сесия, после прекъснете VPN и отворете още една. Всяка стъпка тества различен преход и първата, която се провали, ви казва кой контрол е отговорен.

Планирайте връщането назад преди да започнете, например планирана задача, която изпълнява rasdial "Work VPN" /disconnect след зададен интервал. Това превръща загубената сесия в петминутно прекъсване вместо посещение на място, и е най-евтината застраховка в цялата процедура.

Върнете се вътре, когато сесията вече е изчезнала

Ако хостът вече е недостъпен, спрете да опитвате нови RDP връзки от същия клиент и използвайте канала за възстановяване, който средата вече има: RD Gateway, конзола на хипервайзора или извънлентов интерфейс за управление. Помолете човека с достъп до конзолата да изпълни същите команди Find-NetRoute и Get-NetConnectionProfile, за да оцелеят доказателствата след възстановяването.

После решете постоянното положение, а не най-бързото. Или пътят за управление е изрично запазен от VPN профила, или управлението се мести към канал, който не зависи от маршрута по подразбиране на хоста. И двете са защитими; маршрут до хост с предположен шлюз не е. Запишете кой от двата избрахте и отбележете адреса на партньора, който трябваше да оцелее.

Подобни статии