Удаленный рабочий стол

[Archangel]

Обязательно ли нужен пароль учетке, чтобы воспользоваться удаленным рабочим столом?

[Alder]

Обязательно ли нужен пароль учетке, чтобы воспользоваться удаленным рабочим столом?

Не скажу насчет обязателен, но, как минимум, из соображений безопастности желателен.

[Archangel]

Да мне дома настроить, чтобы с ноута на стационарник лазить можно было, а то они в разных комнатах стоят. Хотя бы вырубать второй, а то poweroff что-то не хочет, может пишу не правильно (shutdown -s -m //192.168.0.1), где //192.168.0.1 - комп который я хочу потушить?

[naxellar]

Archangel, без пароля нельзя подключится, то бишь если он пуст.

[San Diego]

(shutdown -s -m //192.168.0.1), где //192.168.0.1 - комп который я хочу потушить?

такое не работаеть.....лучше RAdmin подними...

[Alder]

лучше RAdmin подними...

Или VNC. Если русский язык не критичен. Вроде как бывают у него траблы с кирилицей.

[San Diego]

Или VNC. Если русский язык не критичен. Вроде как бывают у него траблы с кирилицей.

тож вариант))) хотя это решабельно, но чуть напрячься придетцо....

[tuft]

DameWare Mini Remote Control рулит. Вот только не знаю, насколько он универсален. У нас доменная сетка, и с ним прекрасно работаю. Лезет на чужой комп, инсталит своего клиента. Можно перелогиниваться на удалённой тачке.

[naxellar]

Да мне дома настроить, чтобы с ноута на стационарник лазить можно было, а то они в разных комнатах стоят. Хотя бы вырубать второй, а то poweroff что-то не хочет, может пишу не правильно (shutdown -s -m //192.168.0.1), где //192.168.0.1 - комп который я хочу потушить?

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

[San Diego]

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

[naxellar]

San Diego, XP глушится так у нас в школе

[San Diego]

могет быть....

[Archangel]

Все работает, надо было настроить локальную политику безопасности. И слэши не в ту сторону.

[SV]

Уважаемые коллеги! Верните во мне веру к сети!

Ситуация: есть у меня основной офис и удаленный филиал. В основном офисе стоит роутер Cisco 851. Он является VPN сервером. Локальная сеть основного офиса 192.168.0.0 /24. Есть в ней чудесная машинка 192.168.0.N, к которой надо удаленно подключатся, чтобы работать с 1С через удаленный рабочий стол.

На моё несчастье есть у нас еще филиал. Живет он в Горловке. На всех компах XP SP1. Внутренняя сеть 192.168.50.0 /24. Выход в Инет осуществляется с одного из этих компов-шлюза (у него две сетвухи) при помощи чудесной прокси Usergate древнейшей версии (2.сколько-то). Внешняя сетевуха так же имеет серый адрес из сети 10.2.0.0 /22.

Задача: поставить на нескольких компах внутри сети 192.168.50.0 Cisco VPN клиент и подключится удаленным рабочим столом к 192.168.0.N дабы бухгалтеры могли совершать свои делишки.

Что было сделано: с горем пополам был поднят НАТ, VPN клиент на внутренних машинах поставился, айпишку клиент получил, пинговать 192.168.0.N может. Но! И вот тут начинаются грабли: подключение удаленным рабочим столом, radmin'ом или чем либо еще не возможно.

Ладно, подумал я и поставил VPN клиент на шлюз. И, о чудо! Со шлюза адресок 192.168.0.N пингуется, и, главное, подключение к удаленному рабочему столу таки есть!

Но фишка в том, что местные друзья хотят иметь клиент на каждом нужном им компе - это раз. Да и головняки с таблицами маршрутизации на роутере будут иметь место быть, если я захочу пробросить свою сеть 192.168.50.0 на удаленный роутер через VPN.

Логично предположить, что если у меня живет третий уровень, то проблема закралась где-то выше. Интуиция мне подсказывает, что это какой-то баг с TCP-портами. Но! Проверены и компы и шлюз, нужные мне порты (конкретно 3389 TCP) открыты везде! Файерволы на локальных компах выключены. Более того: внутри этой сети можно доступится по удаленному десктопу и на внутренний адрес шлюза 192.168.50.А и на внешний адрес шлюза 10.2.0.А. Точно так же и с шлюза наоборот. Итого, предположение что баг с портами отпадает.

Долго я думал и в общем ничего умного не придумал. По идее пакет адресованный с интересного мне компьютера где стоит VPN-клиент (адрес источника 192.168.1.N) имеет адрес назначения 192.168.0.100 и порт назначения 3389 TCP. Этот пакет шифруется и отправляется через VPN на роутер. Там он дешифруется и по таблице маршрутизации рулит на 192.168.0.100. Следовательно порт назначения и порт отправителя будут известны лишь на компе-клиенте, на роутере и в локальной сети главного офиса. А значит запрет портов например в сети провайдера не должен сказываться. Он пропускает пакет (4500 порт TCP, кажется). А что скрыто внутри пакета его не интересует. По идее - это потому что я так это себе представляю Тогда  у меня возникает вопрос: так почему же я со шлюза могу доступится на этот комп, а из локалки горловского филиала-нет.

Словом сабж: поясните глупцу в чем я не прав. И верните веру в сети и стек протоколов TCP/IP!

[San Diego]

я чет не буя не понял:

////По идее пакет адресованный с интересного мне компьютера где стоит VPN-клиент (адрес источника 192.168.1.N) /////

откуда взялся адресс из сети 192.168.1.0, это раз, не существенно каешно, но из какой сети айпишник на внешнем интерфейсе циски головного офиса, это два.

[SV]

адресс из сети 192.168.1.0

этот адрес выдается автоматически VPN-адаптеру на удаленной машине при подключении vpn-клиента к vpn-серверу (91.193.N.N).

айпишник на внешнем интерфейсе циски головного офиса

на внешнем интерфейсе цыски реальная айпишка 91.193.N.N

[San Diego]

погоди, на удаленной стороне ведь сеть 192.168.50.0

[SV]

ну и что? ты не заворачиваешь сеть 192.168.50.0 в VPN туннель, а строишь свою сеть 192.168.1.0 между VPN сервером и клиентом. Сеть 192.168.50.0, все внешние сети это исключительно внешняя оболочка IP пакета внутри которого идет пакет с адресом назначения 192.168.0.100 и адресом источника 192.168.1.N. На циске поднята маршрутизация между сетями 192.168.1.N и 192.168.0.0   

[San Diego]

так хорошо, что у тебя маршрутизирует трафик внутри сети 192.168.50.0?

[SV]

Не так сформулировал:

ну и что? ты не заворачиваешь сеть 192.168.50.0 в VPN туннель, а строишь свою сеть 192.168.1.0 между VPN сервером и клиентом. Сеть 192.168.50.0, все внешние сети это исключительно внешняя оболочка IP пакета внутри которого идет пакет с адресом назначения 192.168.0.100 и адресом источника 192.168.1.N. На циске поднята маршрутизация между сетями 192.168.1.N и 192.168.0.0  

читать как: внешний IP-пакет имеет адрес источника: мой комп 192.168.50.N и адрес назначения 91.193.N.N. Понятное дело происходит процедура ната. Внутри этого пакета скрыт еще один (шифрованный) пакет с адресом источника 192.168.1.N и адресом назначения 192.168.0.100. Для внешнего (транспортного, не знаю как правильно назвать) пакета это всего лишь данные. Этот транспортный пакет приходит на циску из него извлекается внутренний пакет, дешифруется и передается узлу 192.168.0.100. Так вроде правильнее. Опять же, это как я себе понимаю этот процесс.

так хорошо, что у тебя маршрутизирует трафик внутри сети 192.168.50.0?

Ну насколько я понял вопрос, то тебя интересует, через что сеть 192.168.50.0 ходит в инет. Ходит через софтину Usergate 2.сколько-то-там. Древняя зараза, но ничего не поделаешь. Эта софтина установлена на одном из компов. У него две сетевухи. Одна с адресом из сети 192.168.50.0, вторая с адресом из сети 10.16.2.0. Вторая сеть - это локалка провайдера