Аддалены працоўны стол праз VPN: на якой стадыі збою вы знаходзіцеся?

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

Чатыры збоі, якія выглядаюць як адзін

Стадыі ўпарадкаваныя: імя развязаецца ў прыватны адрас, які прадугледжвае дызайн, порт адказвае на TCP-рукапоцісканне, хост прымае злучэнне па сваёй палітыцы, а ўваход у сесію ўдаецца. Кожная стадыя робіць наступную немагчымай для праверкі, таму змена налад RDP да стабілізацыі сеткі стварае толькі шум. Сімптом з боку карыстальніка выглядае аднолькава ва ўсіх чатырох выпадках. Раздзяляе іх толькі паведамленне кліента.

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

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

Ці слухае нешта порт 3389?

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

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

Затым праверце порт, а не хост. Завершанае TCP-рукапоцісканне на 3389 аддзяляе дасяжнасць ад усёго, што вышэй:

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

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

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

Чытайце паведамленне раней за канфігурацыю

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

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

Уваход у сесію — асобная мяжа

Аўтэнтыфікацыя належыць службе працоўнага стала, а не VPN. Ідэнтычнасць тунэля і ўліковы запіс працоўнага стала — асобныя пасведчанні з асобнымі палітыкамі блакавання, таму працоўны тунэль даказвае толькі, што тунэль вас прыняў. Блакаванне ўліковага запісу працоўнага стала не перашкаджае тунэлю, і наадварот таксама.

Трымайце абодва цэлымі. Калі прыватнага маршруту няма, выправіце маршрут, бо публікацыя слухача ў інтэрнэт абменьвае памылку дасяжнасці на адкрыты працоўны стол. Не аслабляйце таксама праверкі ідэнтычнасці сесіі, каб абысці папярэджанне пра сертыфікат, якое з’явілася адначасова. Самападпісаны сертыфікат на слухачы RDP паводле дызайну выдае папярэджанне, таму яго прыняцце — рашэнне, а не крок.

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

Што сесія можа пераносіць і дзе гэта застаецца

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

Затым вырашыце, што сесія можа пераносіць, бо буфер абмену, перанакіраваныя дыскі, перанакіраванне прынтара і перадача файлаў перамяшчаюць даныя паміж лакальнай і аддаленай сістэмамі там, дзе палітыка дазваляе. Апублікаваная праграма, якая працуе на далёкім баку, не з’яўляецца аўтаматычна мяжой без спампоўкі, а сесія, што выглядае толькі для чытання, усё роўна можа пераносіць буфер абмену. Правярайце рэальную задачу, а не злучэнне: адкрыйце файл, скарыстайцеся праграмай і пацвердзіце перанакіраванне, якое вам патрэбна. Кіраўніцтва Microsoft пра доступ да аддаленага працоўнага стала звонку апісвае падтрыманыя варыянты адкрыцця, і гэта лепшая спасылка, чым публічны слухач, дададзены пад ціскам.