Зошто RDP замрзнува кога далечниот компјутер се поврзува со 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-профилот, или управувањето се префрла на канал што не зависи од стандардната рута на домаќинот. И двете се одржливи; рута до домаќин со погодена порта не е. Запишете која ја избравте и забележете ја адресата на партнерот што мораше да преживее.