Comments 15
Этой публикацией я не хотел показать 1001-ый способ удаленного администрирования серверов за натом, скорее всего это просто «запасной вход», когда по каким-то причинам не отрабатывают стандартные средства, такие как групповые политики или системы централизованного управления конфигурацией.
По моему мнению для технической поддержки клиентских Windows машин должны использоваться стандартные средства: Remote Assistance или SCCM Remote Control (в зависимости от размеров вашей организации), в случае же если ваша организация профессионально занимается поддержкой внешних клиентов, то тогда это должно быть что-то вроде TeamViewer. А для администрирования Windows серверов, когда их больше 10 в одной организации, «удаленный рабочий стол» должен использоваться только в экстренных случаях.
А как же NetSupport Manager?
Его вполне можно использовать для удаленного администрирования.
Смотря, что вы понимаете под удаленным администрированием.
- Если это техническая поддержка пользователей и настройка рабочих станций (в одном лесу доменов, в одной объединенной сети), тогда зачем, что-то устанавливать дополнительно, когда есть Remote Assistance. Эта утилита уже встроена в Windows имеет достаточный функционал и при этом вписывается даже в самые строгие политики информационной безопасности почти любой организации (ну может кроме банков и т.п.).
- Если это конфигурирование серверов, тогда при условии, что у вас несколько десятков серверов и более, используя любое решение, которое «показывает» вам «Рабочий стол» и вы настраиваете сервер используя мышь – вы только и будете прыгать между «Рабочими столами».
- Если это все-таки конфигурирование серверов и их небольшое количество, тогда любое решение имеет право на жизнь, в том числе и NetSupport Mangaer и ему подобные. Главное, что бы это решение не противоречило политике информационной безопасности организации и не принесло дополнительной потенциально возможной дыры.
Создаем туннель. На удаленном сервере необходимо выполнить команду:
В смысле — не компьютере, который прячется за NAT'ом?
Вообще да, забавная идея — т.е. работать это должно даже тогда, когда у обоих компьютеров серые ай-пи, и оба сидят за своими NAT'ами (но пускают SSH-порты)?
На первом рисунке (схеме) видно, что используется еще и третье звено. А вообще на Хабре уже не раз поднималась эта тема. SSH-туннель
Но команда установления соединения исполняется при этом на том компьютере, к которому даётся доступ.
Так мне помнится.
Да, так и есть. В моем случае эта команда отдается через систему мониторинга icinga2, к которой удаленный компьютер уже подключен. При старте клиент (агент) icinga2 устанавливает с сервером мониторинга соединение на порту 5665, это соединение остается открытым, через которое и отдаются команды клиенту мониторинга на проверки различных состояний в том числе возможна и отправка команды на запуск скрипта создания туннеля.
Создаем туннель. На удаленном сервере необходимо выполнить команду:
Эта фраза входила в теоретическую часть.
Да, конечно можно поднять что-то вроде openVPN или воспользоваться TeamViewer, но опять же такие варианты не всегда приемлемы.
TeamViewer, AmmyAdmin и подобные действительно могут противоречить политике информационной безопасности, поскольку вынуждают доверять третьей стороне.
Но OpenVPN с собственным сервером администратора чем не угодил? Он работает по любому порту, который пропускает аплинк, на сервере можно принимать соединения хоть по всем портам, используя NAT (PAT).
Я вижу только один вариант, когда описанный способю является единственным доступным: работа админом в подразделении организации, в которой «голова» запретила все соединения из внутреннего сегмента подразделения, кроме SSH на вебсервер.
Это решение не претендует на промышленную эксплуатацию от всего лишь "запасной вход". Например, из-за 2-3 мелких филиалов, думаю нет смысла поднимать OpenVPN, а удаленный доступ к ним может понадобиться 2-3 раза в год. Единственная серьезная точка отказа в таком решении, это сама система мониторинга, точнее клиент (агент) мониторинга, когда он по каким-то причинам не сможет подключиться к серверу мониторинга. Скорее это решение дополнительная фишка к уже имеющейся системе мониторинга, а не система удаленного доступа.
Обратный туннель для доступа по RDP с использованием putty и icinga2