Удаленный рабочий стол
naxellar:
San Diego, XP глушится так у нас в школе :good:
San Diego:
могет быть....
Archangel:
Все работает, надо было настроить локальную политику безопасности. И слэши не в ту сторону.
SV:
Уважаемые коллеги! Верните во мне веру к сети! :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!
San Diego:
я чет не буя не понял:
////По идее пакет адресованный с интересного мне компьютера где стоит VPN-клиент (адрес источника 192.168.1.N) /////
откуда взялся адресс из сети 192.168.1.0, это раз, не существенно каешно, но из какой сети айпишник на внешнем интерфейсе циски головного офиса, это два.
Навигация