Paromshick
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Публикация одиночного сервера (мапинг порта 3389 TCP)
Публикация одиночного сервера TS, находящегося внутри периметра локальной сети, это самый простой вариант публикации, именуемый зачастую по-разному, как то: мапинг порта, проброс порта, публикация порта, PAT и т.п. в зависимости от терминологии принятой производителем оборудования или ПО.
Указанная публикация ничем не отличается от публикации любого другого сервиса, находящегося внутри локальной сети, использующей на шлюзе своего периметра технологию NAT (Network Address Translation).
Публикация осуществляется на шлюзе Интернет'а. Его могут называть так же Firewall, Proxy, Router, "раздатчик интернета" и т.д. Правильность подобных названий выходит за рамки поста. Простейшим вариантом является шлюз, потому оставим его.
Публикация, это по сути инструкция для ПО, что делать с пакетами пришедшими на определенный порт из интернета. В общем случае, пакеты пришедшие из интернета без запроса изнутри - отбрасываются. Устраивая публикацию на шлюзе, мы открываем порт для прослушивающего его демона. Шлюз начинает "слушать на порту". Пакет, пришедший на адрес шлюза и на прослушиваемый порт отправляется в соответствии с заданной инструкцией во внутреннюю сеть на определенный в инструкции адрес и в ней же определенный порт.
Для сервера это выглядит как запрос на подключение от клиента с внешним IP адресом и ответ на внешний IP адрес осуществляется, как правило, через шлюз по умолчанию.
Исключение, - это наличие маршрута к внешнему адресу через другой gateway, но это настолько редко, что автор подобным случаем пренебрегает.
Для внешнего клиента установление сеанса выглядит так, как будто он устанавливает соединение с внешним адресом шлюза. О наличии за шлюзом некоего сервера клиентская часть, как правило, "не знает".
В общем случае, для осуществления подобной публикации необходимо наличие следующих обязательных компонентов:
Наличие доступа к шлюзу из глобальной сети, то есть наличие "белого" IP адреса, либо пересылка на внешний адрес шлюза всего входящего трафика, поступающего на "белый" IP от коммутационного оборудования интернета (Cisco и т.п.).
Некоторые устройства и ПО шлюзов могут иметь настройки, при которых все подключения к шлюзу из глобальной сети запрещены и разрешены только внутренние подключения. Обычно, это встречается на устаревшем оборудовании, но тем не менее, проверьте. Пункт может называться Global Firewall из того, что встречал автор.
In usually подобные тонкости не применяются.
Наличие работающего внутри сети сервера и сервиса, к которому свободно подключаются внутренние клиенты.
Шлюз должен быть указан как шлюз по умолчанию на TS. В случае использования на шлюзе технологии Revers NAT (маскарадинг) этот пункт не обязателен.
То есть, всё просто. Есть подключенный Интернет, есть раздающий его роутер, есть сервер TS внутри сети.
Таким образом, сама публикация куда короче, чем преамбула к ней. Собственно, вся преамбула и была написана для понимания технологии работы.
В связи с тем, что оборудования и ПО для пограничной работы есть великое множество, автор берет первое попавшееся под руку устройство для "домашнего интернета" и приводит его настройки и скриншот.
На показанном экране, который в устройстве нашелся в дереве Сеть -- Домашняя сеть -- Серверы. Необходимо сделать следующее
1. Включить саму возможность проброса - перенаправления
2. Выбрать, какой протокол будет перенаправлен. В устройстве не нашлось протокола RDP потому пришлось вручную
3. указать порт 3389
4 Необходимо указать внутренний адрес сервера, обслуживающего запросы на соединения.
5. Опционально выбрать от кого разрешены поступающие запросы. То есть можно ограничить из соображений безопасности адреса, с которых разрешено подключаться к TS.
Rem 1. Рекомендуется не открывать к прослушиванию стандартный порт сервиса, а именно 3389 из соображений безопасности. Но устройство, найденное автором, не поддерживает переключение портов (port triggering). Обычно, её поддержка видна в интерфейсе устройства наличием такого поля, как "Внутренний порт", где-то в районе "Внутреннего адреса", либо разделом «переключение портов».
Если Ваше устройство поддерживает данную функцию, то рекомендую установить поле "Внешний порт" в некое нестандартное значение. Не рекомендуется использовать нижние адреса портов, т.к. они могут быть заняты стандартными сервисами.
Рекомендация автора - прибавить к 3389 одну цифру спереди, например, 5. получится 53389. Цифра должна быть не выше 6. Или придумать свой порт, не выше 65536 (216). Внутренний порт указывается стандартный - 3389.
Надеюсь вы поняли, что мы слегка подправили Инструкцию публикации. Прослушивающий демон стал "слушать" порт 53389, а отправлять, как и ранее на внутренний адрес и порт 3389.
Rem 2Указание в правиле публикации обоих протоколов, и TCP и UDP. Протокол UDP необходим новым клиентам RDS для так называемой проверки качества подключения.
В принципе, публикация окончена.
! Если установлен нестандартный порт, то со стороны внешнего клиента, при запросе соединения, необходимо его указать через двоеточие в окне клиента RDP, либо в командной стороке
Код:| mstsc /v mytermserver:53389 |
Текст предлагается как есть и открыт для правки. Пока что тлько через PM
|
Всего записей: 3019 | Зарегистр. 12-04-2013 | Отправлено: 10:28 19-09-2016 | Исправлено: Paromshick, 15:01 19-09-2016 |
|
