Rdp через vpn настройка
Rdp через vpn настройка
Вопрос
Ответы
Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку «Предложить как ответ» или «Проголосовать за полезное сообщение»
- Помечено в качестве ответа Vasilev Vasil Microsoft contingent staff, Moderator 28 апреля 2017 г. 11:08
:))) Imho, если доставить «шлюз RDP» и начать его настраивать, всё прозрачно. Создаётся политика авторизации подключений — кто вообще может куда-то подключаться (к RDP) через этот шлюз. И политика авторизации ресурсов — кто может подключаться к конкретным (указанным) целевым системам. И только когда предъявляемый логин и целевая система политикам соответствуют, происходит попытка аутентификации.
У вас подключаются извне трое (и, наверное, не к любым внутренним системам) — организовать соответствующие политики «на троих», при наличии попыток подключения под любыми иными учётками, для них просто не будет попыток аутентификации, соответственно, не будет и блокировок.
Кроме того, подключения происходят по SSL, и для успешного подключения на системе клиента должно быть обеспечено доверие сертификату шлюза. Если там «свой» сертификат, множество юных кулхацкеров отсеиваются уже на этом этапе 😉
P.S. В клиенте RDP шлюз для подключения указывается на вкладке «Дополнительно -> Параметры».
- Помечено в качестве ответа Vasilev Vasil Microsoft contingent staff, Moderator 28 апреля 2017 г. 11:09
В опсчем-с, я поступил иначе. У актуального антивируса, помимо модуля «Защита от сетевых атак» есть модуль — «Сетевой экран», я в нём, в разделе «Сетевые пакетные правила» создал три правила для моих трёх внешних RDP- подключений. И всё. Итак:
Открываем настройки Сетевых пакетных правил, и далее:
1. Создаём новое правило
2. Действие — Разрешать
3. Отмечаем Протокол и выбираем TCP
4. Направление — Входящее
5. Локальный порт — 3389
6. Удалённые адреса — Адреса из списка
6.1. Нажимаем Добавить и указываем IP адрес или группу адресов используя маски, как написано в примере в окне ввода адресов
7. Нажимаем ОК в окне нового сетевого правила
8. При помощи кнопки Вверх в окне Сетевых пакетных правил перемещаем новое правило выше правила запрещающего «Сетевая активность для работы технологии удаленного рабочего стола»
Применяем настройки сетевого экрана и проверяем доступность сервера при удалённом подключении. Вуаля. )) А вы мне «. VPN. TMG. » ))) Шучу! )) Всем очень признателен за уделённое время и помощь! ))
- Помечено в качестве ответа Joker Alvares 28 апреля 2017 г. 11:54
Все ответы
Если правильно понял вас проблема из-за неверно введенных паролей производится блокировка УЗ в AD. И вы решили вопрос поставив актуального антивируса и в отчетах нашли причну такова поведения, а именно Bruteforce.Generic.RDP ?
Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку «Предложить как ответ» или «Проголосовать за полезное сообщение»
- Помечено в качестве ответа Vasilev Vasil Microsoft contingent staff, Moderator 28 апреля 2017 г. 11:08
. По RDP извне официально подключаются трое пользователей. Поэтому, он всё таки нужен. Это если предложите отключить!)))) Есть мысль организовать VPN, и уже через него подключаться по RDP. .
В принципе, VPN на TMG поднимается на раз-два, в разнообразных вариантах, вроде и без мануалов понятно :).
Есть и другой вариант — поднять шлюз RDP и убрать возможность прямых подключений к RDP (только через шлюз). Основной фокус в проверке на соответствие политикам (предварительная авторизация) до аутентификации. При грамотно составленных политиках (какому эккаунту к какой системе подключаться можно) большинство попыток доступа отсеиваются без аутентификации (до), блокировки «популярного набора» учёток не будет. Дополнительный фокус — подключение по SSL/TLS, не каждый из ищущих открытых RDP будет туда ломиться. Компонент «шлюз RDP» на W2k8R2 вполне функционален.
- Помечено в качестве ответа Joker Alvares 28 апреля 2017 г. 3:21
- Снята пометка об ответе Joker Alvares 28 апреля 2017 г. 3:21
. По RDP извне официально подключаются трое пользователей. Поэтому, он всё таки нужен. Это если предложите отключить!)))) Есть мысль организовать VPN, и уже через него подключаться по RDP. .
В принципе, VPN на TMG поднимается на раз-два, в разнообразных вариантах, вроде и без мануалов понятно :).
Есть и другой вариант — поднять шлюз RDP и убрать возможность прямых подключений к RDP (только через шлюз). Основной фокус в проверке на соответствие политикам (предварительная авторизация) до аутентификации. При грамотно составленных политиках (какому эккаунту к какой системе подключаться можно) большинство попыток доступа отсеиваются без аутентификации (до), блокировки «популярного набора» учёток не будет. Дополнительный фокус — подключение по SSL/TLS, не каждый из ищущих открытых RDP будет туда ломиться. Компонент «шлюз RDP» на W2k8R2 вполне функционален.
Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку «Предложить как ответ» или «Проголосовать за полезное сообщение»
:))) Imho, если доставить «шлюз RDP» и начать его настраивать, всё прозрачно. Создаётся политика авторизации подключений — кто вообще может куда-то подключаться (к RDP) через этот шлюз. И политика авторизации ресурсов — кто может подключаться к конкретным (указанным) целевым системам. И только когда предъявляемый логин и целевая система политикам соответствуют, происходит попытка аутентификации.
У вас подключаются извне трое (и, наверное, не к любым внутренним системам) — организовать соответствующие политики «на троих», при наличии попыток подключения под любыми иными учётками, для них просто не будет попыток аутентификации, соответственно, не будет и блокировок.
Кроме того, подключения происходят по SSL, и для успешного подключения на системе клиента должно быть обеспечено доверие сертификату шлюза. Если там «свой» сертификат, множество юных кулхацкеров отсеиваются уже на этом этапе 😉
P.S. В клиенте RDP шлюз для подключения указывается на вкладке «Дополнительно -> Параметры».
- Помечено в качестве ответа Vasilev Vasil Microsoft contingent staff, Moderator 28 апреля 2017 г. 11:09
Cложновато для моего понимания!)))
:))) Imho, если доставить «шлюз RDP» и начать его настраивать, всё прозрачно. Создаётся политика авторизации подключений — кто вообще может куда-то подключаться (к RDP) через этот шлюз. И политика авторизации ресурсов — кто может подключаться к конкретным (указанным) целевым системам. И только когда предъявляемый логин и целевая система политикам соответствуют, происходит попытка аутентификации.
У вас подключаются извне трое (и, наверное, не к любым внутренним системам) — организовать соответствующие политики «на троих», при наличии попыток подключения под любыми иными учётками, для них просто не будет попыток аутентификации, соответственно, не будет и блокировок.
Кроме того, подключения происходят по SSL, и для успешного подключения на системе клиента должно быть обеспечено доверие сертификату шлюза. Если там «свой» сертификат, множество юных кулхацкеров отсеиваются уже на этом этапе 😉
P.S. В клиенте RDP шлюз для подключения указывается на вкладке «Дополнительно -> Параметры».
Есть нюанс: шлюз RDP (RD Gateway, RDG) на компьютер с TMG, на котором опубликованы по HTTPS внутренние серверы, так просто не поставить — он при настройках по умолчанию будет конфликтовать за порт 443 со службой, которая обеспечивает публикацию (она, к сожалению, не использует системный драйвер http.sys а прослушивает порт самостоятельно). Как установить RDG на сервере TMG в таком случае, я когда-то написал.
И ещё — про аутентификацию на RDG: если её сделать по доменной учётной записи, то эта запись точно так же будет блокироваться из-за попыток подбора пароля (хотя пароль будут пытаться подбирать не так часто, возможно). Я бы в таком случае подумал бы насчёт аутентификации на RDG по локальным учётным записям сервера, где стоит TMG. Это, конечно, создаёт неудобства для пользователей — им придётся при подключении использовать две разные учётные записи с двумя паролями, но зато проблем с блокировкой не будет.
RDP через проброшенный порт или VPN, что опаснее?
А почему опасность заражения становится выше?
Пользователи ходят без админ-прав?
Антивирус какой-нибудь стоит, который мелочи будет ловить запуск вредоноса?
Какие еще угрозы?
Если на терминальном сервере не хранить документы, диски на буквы не мапить, то в крайнем случае профайл пользователя почистил, все, пусть заново заходит.
Как не остановлю? Юзер ограничен, в систему не внедрится, антивирус файлы ловит, запустить не даст.
Вам 100.000% защита нужна? Так ее никто не обеспечит с такими условиями работы.
А 99% у вас будет при антивирусе на терминале и ограниченных правах пользователей.
Смена порта RDP или VPN вообще никак тут не влияют.
А что шифровальщик сделает на терминале?
Кроме того, все известные мне шифровальщики, шифруют исключительно локальные файлы. незамапленные сетевые диски они не трогают, а это был мой первый совет.
Изменение номера проброшенного порта на безопасность никак не влияет.
Если же VPN, то опасность заражения всякой шляпой становится выше.
Это бред какой-то.
На опасность заражения наличие или отсутствие VPN никак не влияет.
Безопасней использовать VPN.
Артур Артур: Вы подключаетесь к RDP .
RDP работает поверх сетевого подключения.
Поэтому если вы подключаетесь с зараженного компьютера по RDP к какому-то компьютеру, значит у вас в любом случае есть к нему доступ по сети.
И какая разница какими инструментами этот доступ организован? VPN или прямое подключение?
Remote Desktop Connection через VPN
![]() ![]() |
| ||||
Вернуться к началу | |||||
![]() | |||||
Зарегистрируйтесь и реклама исчезнет! | |||||
![]() | |||||
vlaryk Networks guru ![]() Зарегистрирован: 28.01.2009 |
| ||||
Вернуться к началу | |||||
![]() | |||||
avreolko Новичок Зарегистрирован: 22.10.2013 |
| ||||
Вернуться к началу | |||||
![]() | |||||
ssa555 Участник форума Зарегистрирован: 02.03.2004
|
| ||||
Вернуться к началу | |||||
![]() | |||||
AMADA Новичок Зарегистрирован: 22.11.2019 |
| ||||
Вернуться к началу | |||||
![]() | |||||
Андрай [+] Зарегистрирован: 24.03.2008 |
| ||||
Вернуться к началу | |||||
![]() | |||||
AMADA Новичок Зарегистрирован: 22.11.2019 |
| ||||
Вернуться к началу | |||||
![]() | |||||
AMADA Новичок Зарегистрирован: 22.11.2019 |
| ||||
Вернуться к началу | |||||
![]() | |||||
AMADA Новичок Зарегистрирован: 22.11.2019 Пример настройки подключения к домашнему компьютеру по RDPРассмотрим пример настройки интернет-центра Keenetic для возможности удаленного подключения к компьютеру локальной сети, по протоколу RDP ( Remote Desktop Protocol). Сетевой протокол удаленного рабочего стола используется для обеспечения удаленной работы пользователя с компьютером (сервером), на котором разрешено удаленное подключение к рабочему столу. В операционной системе Windows приложение удаленного рабочего стола (Remote Desktop) входит в состав операционной системы. NOTE: Важно! В настольных версиях ОС Windows 7/8/10 существуют лицензионные ограничения: 1. Возможность принимать удаленное подключение к компьютеру по RDP имеется только в профессиональных версиях Windows 7/8/10 Pro, максимальной версии Windows 7 Ultimate и корпоративных версиях Windows 7/8/10 Enterprise. В начальных и домашних версиях (Starter, Home) такой возможности нет. Владельцы этих систем смогут подключаться со своего компьютера к другим по RDP, но организовать подключение к своему компьютеру через удаленный рабочий стол не смогут. 2. Р азрешено подключение к удаленному рабочему столу только одного пользователя (одна сессия). Клиенты для подключения по протоколу RDP существуют практически для всех версий операционной системы Windows, Linux, Mac OS X, iOS, Android. По умолчанию для работы протокола RDP используется порт TCP 3389. Настройка интернет-центра Keenetic для организации удаленного подключения по протоколу RDP к компьютеру локальной сети будет отличаться в зависимости от того какой IP-адрес использует ваш роутер для доступа в Интернет — публичный («белый») или частный («серый»). Обратитесь, пожалуйста, к статье «В чем отличие «белого» и «серого» IP-адреса?». Из неё вы узнаете как самостоятельно определить, является ли ваш IP-адрес «белым» или «серым». Публичный IP-адресИмея на роутере публичный («белый») IP-адрес для доступа в Интернет, вы сможете напрямую подключаться к компьютеру домашней сети. Вам нужно будет только через веб-конфигуратор интернет-центра зарегистрировать компьютер в локальной сети, закрепить за компьютером постоянный IP-адрес, чтобы он каждый раз не менялся, и на странице «Переадресация» создать правило проброса порта TCP 3389 на ранее зарегистрированный компьютер. Нужно правильно указать значение поля «Вход». В этом поле нужно выбрать подключение или интерфейс, через которое Keenetic получает доступ в Интернет. В большинстве случаев следует выбирать интерфейс «Провайдер». Если у вас подключение к Интернету осуществляется через PPPoE, PPTP или L2TP, нужно выбрать соответствующее подключение. При подключении к Интернету через USB-модем 3G/4G следует указать именно это подключение, а при подключении через WISP, выберите подключение с названием сети, к которой подключается Keenetic. В поле «Выход» выберите устройство, подключение или интерфейс, которому будет переадресован подходящий трафик (в нашем примере это зарегистрированный в домашней сети компьютер PC). В поле «Выход» можно выбрать значение «Другое устройство» и указать IP-адрес. В поле «Протокол» укажите протокол из списка предустановленных, который будет использован при переадресации порта (в нашем примере это TCP/3389). NOTE: Важно! Дополнительную настройку межсетевого экрана производить не нужно, т.к. при использовании правила переадресации интернет-центр самостоятельно открывает доступ по указанному порту. Теперь с устройства из внешней сети (из Интернета) создайте подключение к удаленному рабочему столу. В качестве компьютера для подключения нужно будет указать WAN IP-адрес роутера или его имя KeenDNS / DDNS. Например: NOTE: Важно! При использовании доменного имени KeenDNS, в настройках сервиса нужно использовать режим «Прямой доступ» (для публичных IP-адресов). TIP: Совет: Для безопасного и защищенного подключения из Интернета к своему роутеру Keenetic и компьютеру домашней сети, рекомендуем использовать VPN-подключение. Включите L2TP/IPsec или PPTP VPN-сервер на интернет-центре Keenetic. Сначала установите с устройства из внешней сети (из Интернета) подключение к VPN-серверу и затем через него вы сможете получить доступ к домашнему компьютеру по протоколу RDP. В этом случае не нужно будет создавать правило проброса портов, а в качестве компьютера для подключения нужно будет указать IP-адрес компьютера в домашней сети. Например: 192.168.1.31 Частный IP-адресИмея на роутере частный («серый») IP-адрес для доступа в Интернет, вы не сможете напрямую подключаться к компьютеру домашней сети (для этого необходимо наличие публичного IP-адреса). Также не будет работать протокол RDP (TCP/3389) и через нашу облачную службу KeenDNS. KeenDNS в режиме «Через облако» поддерживает работу только по протоколам HTTP/HTTPS. Но можно использовать SSTP VPN-сервер на интернет-центре Keenetic. SSTP-сервер позволяет установить подключение между клиентом и сервером, даже при наличии частного IP-адреса. Вам нужно будет установить с устройства из внешней сети (из Интернета) подключение к VPN-серверу и затем уже через него сможете получить доступ к домашнему компьютеру по протоколу RDP. В этом случае RDP-подключение будет работать внутри SSTP-туннеля и ничто не будет мешать удаленному доступу по протоколу RDP. В веб-конфигураторе интернет-центра нужно зарегистрировать компьютер в локальной сети (к которому планируете организовать удаленное подключение) и закрепить за компьютером постоянный IP-адрес, чтобы он каждый раз не менялся. Затем выполните настройку SSTP-сервера на роутере Keenetic по инструкции «VPN-сервер SSTP». С устройства из внешней сети (из Интернета) установите подключение к VPN-серверу SSTP. Для подключения к серверу в качестве клиента можно использовать: Затем создайте подключение к удаленному рабочему столу. В качестве компьютера для подключения нужно будет указать IP-адрес компьютера в домашней сети. Например: 192.168.1.31 NOTE: Важно! Так как VPN-сервер SSTP в случае с частным IP-адресом работает через интернет-облако, в настройках сервиса KeenDNS нужно использовать только режим «Через облако». Пользователи, считающие этот материал полезным: 8 из 9 Adblock detector |