Чаму 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, альбо кіраванне пераходзіць на канал, які не залежыць ад маршруту хоста па змаўчанні. Абодва бараніць можна; маршрут хоста з угаданым шлюзам — не. Запішыце, які з іх вы абралі, і зафіксуйце адрас партнёра, які павінен быў выжыць.