Comments 15

Этой публикацией я не хотел показать 1001-ый способ удаленного администрирования серверов за натом, скорее всего это просто «запасной вход», когда по каким-то причинам не отрабатывают стандартные средства, такие как групповые политики или системы централизованного управления конфигурацией.


По моему мнению для технической поддержки клиентских Windows машин должны использоваться стандартные средства: Remote Assistance или SCCM Remote Control (в зависимости от размеров вашей организации), в случае же если ваша организация профессионально занимается поддержкой внешних клиентов, то тогда это должно быть что-то вроде TeamViewer. А для администрирования Windows серверов, когда их больше 10 в одной организации, «удаленный рабочий стол» должен использоваться только в экстренных случаях.

А как же NetSupport Manager?
Его вполне можно использовать для удаленного администрирования.

Смотря, что вы понимаете под удаленным администрированием.


  • Если это техническая поддержка пользователей и настройка рабочих станций (в одном лесу доменов, в одной объединенной сети), тогда зачем, что-то устанавливать дополнительно, когда есть Remote Assistance. Эта утилита уже встроена в Windows имеет достаточный функционал и при этом вписывается даже в самые строгие политики информационной безопасности почти любой организации (ну может кроме банков и т.п.).
  • Если это конфигурирование серверов, тогда при условии, что у вас несколько десятков серверов и более, используя любое решение, которое «показывает» вам «Рабочий стол» и вы настраиваете сервер используя мышь – вы только и будете прыгать между «Рабочими столами».
  • Если это все-таки конфигурирование серверов и их небольшое количество, тогда любое решение имеет право на жизнь, в том числе и NetSupport Mangaer и ему подобные. Главное, что бы это решение не противоречило политике информационной безопасности организации и не принесло дополнительной потенциально возможной дыры.
Создаем туннель. На удаленном сервере необходимо выполнить команду:


В смысле — не компьютере, который прячется за NAT'ом?
Вообще да, забавная идея — т.е. работать это должно даже тогда, когда у обоих компьютеров серые ай-пи, и оба сидят за своими NAT'ами (но пускают SSH-порты)?

На первом рисунке (схеме) видно, что используется еще и третье звено. А вообще на Хабре уже не раз поднималась эта тема. SSH-туннель

«Третье звено» — SSH-сервер — подразумевается для любого тоннеля, а для обратного он практически обязателен. Т.е. ценность его именно в том, что можно дать удалённый доступ «себе» из-за NAT'а.
Но команда установления соединения исполняется при этом на том компьютере, к которому даётся доступ.
Так мне помнится.

Да, так и есть. В моем случае эта команда отдается через систему мониторинга icinga2, к которой удаленный компьютер уже подключен. При старте клиент (агент) icinga2 устанавливает с сервером мониторинга соединение на порту 5665, это соединение остается открытым, через которое и отдаются команды клиенту мониторинга на проверки различных состояний в том числе возможна и отправка команды на запуск скрипта создания туннеля.

Создаем туннель. На удаленном сервере необходимо выполнить команду:

Эта фраза входила в теоретическую часть.

Просто может сложиться ложное впечатление, что команду нужно исполнить на SSH-сервере.

Интересная статья. Реализовал подобное на node.js + socket.


На работе пк за натом, всё залочино типа тимвювера, хамачи и проч; дома комп с прямым айпи.


Рабочий комп устанавливает соединение с моим домашним компом, открывая тунель. Далее никакой магии, запускаю рдп, подключаюсь на localhost:9876 (порт можно предварительно задать любой, разумеется).


Если нужно не рдп или рдп на другой рабочий комп, не проблема, просто указал другой айпи/порт :)


Если кому-то интересно — пишите.
Прошу прощения за офытоп

Описанное решение сложно в настройке и содержит несколько точек отказа. Преимущество только одно: можно продиктовать (прислать в SMS) пользователю команду и получить вход. Но в статье описан предварительно настроенный туннель, при том, что есть более простые и надёжные альтернативы.

Да, конечно можно поднять что-то вроде openVPN или воспользоваться TeamViewer, но опять же такие варианты не всегда приемлемы.


TeamViewer, AmmyAdmin и подобные действительно могут противоречить политике информационной безопасности, поскольку вынуждают доверять третьей стороне.
Но OpenVPN с собственным сервером администратора чем не угодил? Он работает по любому порту, который пропускает аплинк, на сервере можно принимать соединения хоть по всем портам, используя NAT (PAT).

Я вижу только один вариант, когда описанный способю является единственным доступным: работа админом в подразделении организации, в которой «голова» запретила все соединения из внутреннего сегмента подразделения, кроме SSH на вебсервер.

Это решение не претендует на промышленную эксплуатацию от всего лишь "запасной вход". Например, из-за 2-3 мелких филиалов, думаю нет смысла поднимать OpenVPN, а удаленный доступ к ним может понадобиться 2-3 раза в год. Единственная серьезная точка отказа в таком решении, это сама система мониторинга, точнее клиент (агент) мониторинга, когда он по каким-то причинам не сможет подключиться к серверу мониторинга. Скорее это решение дополнительная фишка к уже имеющейся системе мониторинга, а не система удаленного доступа.

Для единичных подключений использовал PPtP. На нужном сервере/маршрутизаторе/etc настраивается подключение, запускаемое при старте. В центре стоял выделенный маршрутизатор с поднятым PPtP сервером, к учетке привязан IP (использовал Микротик). Просто как палка/веревка.
Only those users with full accounts are able to leave comments. Log in, please.