КИТА unofficial

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ситуация: есть у меня основной офис и удаленный филиал. В основном офисе стоит роутер 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!

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

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

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

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

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

ну и что? ты не заворачиваешь сеть 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   

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

в принципе, исходя из написанного все теоретически правильно, хотя можно можно сделать так: в филиале на нужных машинах дополнительно прописывается сеть 192.168.1.0, на головном оффисе делается та же самая процедура, то есть всего ты имеешь 3 сети: это 2 собственно сети главного оффиса и филиала (192.168.0.0 и 192.168.50.0) , сама VPN сеть (в которой у тебя и будут находиться все твои машины которые должны связываться между собой 192.1681.0). Хотя можно тупо загнать можно загнать все в одну сеть, но тут мну подсказывает что-то, что тебе следует избавиться от прокси, и поднять маршрутизацию стандартными средствами ОС.

Дело в том, что выше я писал о том, что не понимаю причину глюка. Я включаю ВПН-клиент на любом компе удаленного офиса и спокойно пингую машину 192.168.0.100. Т.е. проблем с маршрутизацией нет. Есть проблемы на одном из верхних уровней. Транспортный уровень - нет. Ведь пакет с моего компа 192.168.1.N на 192.168.0.100 является всего лишь зашифрованными данными и закрытие кaких-тo портов (у прова например) не должно на это влиять. В офисе соотв. порты открыты. 

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

SV, либо впн настроен не совсем корректно, либо сам юзергейт настроен не совсем корректно. Покопай в обоих направлениях.

Проблему решил переустановкой винды и переустановкой юзергейта на относительно свежий. В общем как обычно: танцы с бубном + нормальная настройка ната. Спасибо за сегодняшнее утренее благословение KyDECHuK'ом. Можно сказать, что вдохновленный ним я и решил свою проблему :)

SV )))))
 Вот и чудненько - поздравляю!

Я для таких целей использую Radmin/. Очень удобная штука. :P