Войти

Показать полную графическую версию : Терминальный доступ на внешний хостинг. Серия вопросов к "практикующим"...


Lucky_SV
26-01-2014, 23:39
Ситуация - сервер на внешнем хостинге, консоли обычно не бывает - пока только РДП. Вин 2008 Р2. Надо обеспечить подключение из неск. офисов и для моб. пользователей. Домена и пр. - нет, ИМЯ СЕРВЕРА может быть прописано (при необходимости) в ДНС-е для доступа извне.

1. Хотелось бы иметь ССЛ туда. Настройки сделаны на сервере узла сеансов, сертификат подтянут в корень ПК клиента, занчек "замочек" на клиенте в заголовке окна терминала - отображается. При запуске клиента ругается на непроверенного издателя РДП-файла, но сертификат (самоподписной) - хавает вроде бы как нормально, в настройках шлюза - автоматический режим. В свойствах службы - уровень безопасности - ССЛ, уровень шифрования - ВЫСОКИЙ. При запуске - привычного для РДП окошка с авторизацией логин-пароль) - нет. Т.е. вроде бы - работает, но...

Что смущает - если на сервере в службах зайти в свойства соединения - напротив "Уровень шифрования" - ПУСТО! Всегда - вне зависимости от того, какой режим (РДП, ССЛ или согласование) выбран. Все остальные поля (вплоть до "разрешения экрана") - заполнены.
И риторическое - где посмотреть еще - как проверить?

2. Есть ли смысл разворачивать службу шлюзов РДП на сервере? Какие реальные плюсА это даст в ДАННОЙ ситуации?

3. Есть ли смысл разворачивать службу сертификации на этом сервере? Понятно, самоподписной сертификат - неайс, но стоит ли ради ухода от него так усложнять?
Может - прощеЕ купить (кто порекомендует - Хде незадорого именно такой и года на 3?)

Для прокатывани самоподписного сертификата исп-ся файл ХОСТС сейчас. Могу прописать на внешнем ДНС-е его имя "а-ля доменное" с последующим развертыванием СА, чтобы уйти от ХОСТс. Плюс придется это мутить, если придется (а есть желание) подтянуть аладдиновские "токены". Но стоит ли оно того?

4. Хотелось бы из офисов ВПН туда с "железок" сделать. Отзывы разные - стоит ли? Или жестко прописать в политиках исходящие (офисов) адреса соединений, открыв ВПН только для мобильных клиентов?

Буду рад услышать мнения тех, кто уже сталкивался с данными вопросами...
СПАИСБО!

Lucky_SV
27-01-2014, 01:23
Вдогонку. Просматривал соседние темы.
Если его (шлюза) - нет, то вне зависимости от настроек (и даже от наличия сертификата сервера на клиенте) - соединение ВСЕ ТАКИ УСТАНАВЛИВАЕТСЯ. С "замочком" в заголовке окна терминала или без оного - зависит от правильности ввода имени сервера и наличия адекватного (имени) сер-та в нужном месте.

Но если ТРЕБОВАТЬ этого-самого SSL - значит, на тех ПК, где сертификата нет (или он не занесен в хранилище ПК) - доступа не будет? Соответственно - клиенту - "подтянуть и положить куда надо" - не получится, и доступа в дальнейшем - тоже?

В чем я неправ?

Lucky_SV
27-01-2014, 04:27
Итак - есть чем продолжить. Поставил шлюз - все работает. Как ни странно - именно через шлюз. Соответственно - еще вопросы.
1. Наконец-то проявилось "защищенность" - в заголовке окна теперь слева светится гаечный ключ и мелькает в свойствах слово "зашифровано".
Вопрос - как? Потому как диспетчер служб по-прежнему хранит молчание на этот счет, а диспетчер шлюза - кажет РДП, но не ССЛ.

И вообще - можно как-то детальные логи посмотреть на всю эту вакханалию?
В общесистемных разбираться - тоскливо...

2. Все также отказываются открыть тайну защищенности "свойства соединения". Т.е. там - все так же пусто.

3. Не дает покоя NPS. Сделаны 2 политики стандартные в процессе установки шлюза - пускать админ-ов и ремоут-ов на любые сетевые ресурсы.
Судя по общесистемным лог-ам - политики эти (созданные при установке) - отрабатываются.

Вопросы к экспертам
3.1 можно оттуда что-то полезное выцепить для моего случая или лучше не трогать?
3.2 по умолчанию можно использовать ЛЮБОЕ шифрование, даже "никакое". Если сбросить эту птичку ("не использовать")- что произойдет?
Это относительно того, КАК ЗАПРЕТИТЬ незащищенное соединение?

Экспериментировать стремно - во многих случаях службы удаленнного доступа сохраняют свойства текущих соединений, давая возможность экспериментировать на новых. А вот тут - непонятно...

3.3 Как можно блокировать прямое (минуя шлюз) подключение? Пока можно и через него, и минуя - что отражается и на логах шлюза, и видно в заголовке окна терминала.

4. Все это WIN-хозяйство трудится под HIPER-V, масштабов которого я знаю понаслышке только.
Можно ли как-то ненамеренно (в ходе экспериментов) вывести виртуальную машину из под контроля оператора всего пула?
Оч. не хотелось бы ссориться с "хозяевами", потому как только через них вся "поддержка"....

СПАСИБО!

zavgar
30-01-2014, 16:17
3.3 Как можно блокировать прямое (минуя шлюз) подключение? Пока можно и через него, и минуя - что отражается и на логах шлюза, и видно в заголовке окна терминала. »
Я в Брандмауэр Windows сервера закрываю все порты кроме 443




© OSzone.net 2001-2012