[Win Server 2003] Проблема с маршрутом через VPN
Добрый день.
Есть Win Server 2003. На нем ничего кроме VPN-а и MS SQL. И есть программа (сервер/клиент). Серверная часть естественно на данном сервера, к клиентская должна быть по другую сторону VPN-а. Здесь то и есть вся проблема.
Серверная часть слушает порт (ждет запрос на подключение). Клиентская часть через VPN обращается к серверу на тот-же порт, но, по какой-то причине, запрос даже не доходит (потр закрыт или не существует). однако если проделать все тоже без VPN-а, то все получается. В чем может быть проблема? Я так полагаю, что необходимо как-то прописать маршрут, но как?
Есть Win Server 2003. На нем ничего кроме VPN-а и MS SQL. И есть программа (сервер/клиент). Серверная часть естественно на данном сервера, к клиентская должна быть по другую сторону VPN-а. Здесь то и есть вся проблема.
Серверная часть слушает порт (ждет запрос на подключение). Клиентская часть через VPN обращается к серверу на тот-же порт, но, по какой-то причине, запрос даже не доходит (потр закрыт или не существует). однако если проделать все тоже без VPN-а, то все получается. В чем может быть проблема? Я так полагаю, что необходимо как-то прописать маршрут, но как?
Как настроен VPN?
Как реализована привязка серверной части к TCP-порту (binding)? Какой адрес слушаете?
Покажите netstat -l -p при установленном VPN-соединении.
Как реализована привязка серверной части к TCP-порту (binding)? Какой адрес слушаете?
Покажите netstat -l -p при установленном VPN-соединении.
VPN настраивал так.
Я понял в чем была проблема. Программа-сервер ждала подключения по локальному ip-адресу. По какой-то причине она не видела ip-шник VPN-а. Я его прописал вручную и все заработало.
Но правда есть другая проблема. Не работает удаленный рабочий стол. Я сначала думал, что это из-за того, что пользователь VPN-а не имеет такого права. Выставил права, проверил по локальному адресу (работает), а через VPN не хочет.
По поводу команды "netstat"- ключа "l" там нет.
Я понял в чем была проблема. Программа-сервер ждала подключения по локальному ip-адресу. По какой-то причине она не видела ip-шник VPN-а. Я его прописал вручную и все заработало.
Но правда есть другая проблема. Не работает удаленный рабочий стол. Я сначала думал, что это из-за того, что пользователь VPN-а не имеет такого права. Выставил права, проверил по локальному адресу (работает), а через VPN не хочет.
По поводу команды "netstat"- ключа "l" там нет.
Скорее всего таже проблема. Удаленный рабочий стол работает через TCP-порт 3389. Скорее всего этот порт не слушается через VPN интерфейс. Также надо проверить настройку NAT для VPN. Сильно не вчитывался, но в указанной вами статье есть слова про NAT.
Про netstat прошу прощения. На память не помню, а под рукой не было машины.
Посмотрите справку, я хотел командой вывести все порты, которые прослушиваются на данный момент, плюс с указанием идентификатора процесса.
Посмотрите справку, я хотел командой вывести все порты, которые прослушиваются на данный момент, плюс с указанием идентификатора процесса.
Я с помощью проги выяснил, что на данном порту система не ожидает подключения к RDT.
Где и как необходимо в системе прописать (перенаправить) потр с 192.168.240.1:3389 на 192.168.0.1:3389?
Я пробовал в NAT настройках разрешить удаленное управление рабочим столом. То-же не помогло.
Где и как необходимо в системе прописать (перенаправить) потр с 192.168.240.1:3389 на 192.168.0.1:3389?
Я пробовал в NAT настройках разрешить удаленное управление рабочим столом. То-же не помогло.
Вот беглый поиск в гугль выдал.
http://www.it2web.ru/index.php/rras/87-probros-portov-cherez-rras-ispolzuem-statichnyj-nat?showall=1
Только убедитесь, что у вас правильно интерфейсы настроены в RRAS
http://www.it2web.ru/index.php/rras/87-probros-portov-cherez-rras-ispolzuem-statichnyj-nat?showall=1
Только убедитесь, что у вас правильно интерфейсы настроены в RRAS
В общем ситуация следующая:
у сервера одна сетевая карта с IP-адресом 192.168.0.103. VPN создает под сеть 192.168.240.X. У сервера соответственно адрес 192.168.240.1 в данной под сети. Я попробовал, согласно данной инструкции, в настройках NAT-а прописать IP-адрес 192.168.0.103 (Удаленный рабочий стол) и у меня перестал работать RDT и с под сети 192.168.0.x и с 192.168.240.x. Так-же пробовал прописать 192.168.240.1 - та-же ерунда.
В чем может быть проблема? Может мне скриншоты скинуть?
у сервера одна сетевая карта с IP-адресом 192.168.0.103. VPN создает под сеть 192.168.240.X. У сервера соответственно адрес 192.168.240.1 в данной под сети. Я попробовал, согласно данной инструкции, в настройках NAT-а прописать IP-адрес 192.168.0.103 (Удаленный рабочий стол) и у меня перестал работать RDT и с под сети 192.168.0.x и с 192.168.240.x. Так-же пробовал прописать 192.168.240.1 - та-же ерунда.
В чем может быть проблема? Может мне скриншоты скинуть?
Можешь приконнектится через телнет на порт rdp?
telnet 192.168.240.1 3389
telnet 192.168.0.103 3389
telnet 192.168.240.1 3389
telnet 192.168.0.103 3389
Не может быть, чтобы перенаправление не работало?
Можете совсем файрвол отключить (Windows Firewall, Kaspersky, NOD, .... ??). Какой вы используете кстати?
Давайте еще раз пройдемся. Я тут картинку набросал, вроде нигде не накосячил, думаю меня гуру поправят еже ли что. Итак у Вас один Ethernet интерфейс. Через него устанавливается PPTP-туннель. Драйвер туннеля создает новый интерфей, виртуальный, и назначает ему адрес 192.168.240.1. Клиент получает, например, 192.168.240.13. Авторизацию оставляем в стороне, короче туннель появился. Траффик туннеля (GRE) приходит на локальный интерфейс, потом драйвером из него извлекается инкапсулированный IP-трафик сети 192.168.240.0/24
На этом этапе все хорошо, но прежде чем сказать, что RDP-сервис не отвечает на 192.168.240.1:3389 - отключите файрволл. Хоть вы и говорите, что нет соединения, но я бы покапал в этом направлении. Сейчас я нарисовал жирный крест - так трафик не идет.
Далее предположим, что на серверный конец туннеля приходит такой пакет IP<from:192.168.240.13:* to:192.168.240.1:3389>, то есть обращение к RDP-сервису. Я обозначил этот пакет кружком с цифрой (1). Ясно, что через VPN интерфейс данный пакет никто не обработает. Порт 3389 никто не открывал.
Тогда здесь нужен NAT и далее ПЕРЕНАПРАВЛЕНИЕ пакетов. У меня нет под рукой машины с Виндоуз для того, чтобы сгенерить скриншоты, поэтом продолжаю по картинкам (ресурс вами приведенный что-то помер на данный момент), которые уже приводили. Выбрать IPv4 -> Преобразование сетевых адресов. Там ДОЛЖЕН УЖЕ БЫТЬ интерфейс, который VPN-сервера. Если нет, покажите что у Вас в "Интерфейсы сети". На __интерфейсе VPN-сервера__ происходит NAT (преобразование адреса). Заменять будем поле пакета КУДА (to или dst). Заменяем разумеется на 192.168.0.103. Если все правильно настроили, то получится пакет
в состоянии (2) --- IP<from:192.168.240.13:* to:192.168.0.103:3389>.
Все бы ничего, но теперь интерфейс VPN-сервера не знает, что делать с этим пакетам. Это уже ни его пакет. Данный пакет отдается в службу маршрутизации, которая посмотрит на адрес доставки (192.168.0.103) и признает в нем известное для нее место - локальный интерфейс. Куда он и будет передан. Пакет долетел, нарисовал состояние (3).
Во всем этом процессе, все бы ничего, но нужно смотреть за настройками файрволла.
Он пронизывает все направления передачи трафика, в том числе между сетевыми интерфейсами. Пробуйте его отключить. Если не помагает, значит где-то ошиблись в конфигурировании. Конечно, я тоже могу ошибаться, поскольку пишу с листа и попробовать негде. Но других идей больше нет :)
[ATTACH=CONFIG]5590[/ATTACH]
Можете совсем файрвол отключить (Windows Firewall, Kaspersky, NOD, .... ??). Какой вы используете кстати?
Давайте еще раз пройдемся. Я тут картинку набросал, вроде нигде не накосячил, думаю меня гуру поправят еже ли что. Итак у Вас один Ethernet интерфейс. Через него устанавливается PPTP-туннель. Драйвер туннеля создает новый интерфей, виртуальный, и назначает ему адрес 192.168.240.1. Клиент получает, например, 192.168.240.13. Авторизацию оставляем в стороне, короче туннель появился. Траффик туннеля (GRE) приходит на локальный интерфейс, потом драйвером из него извлекается инкапсулированный IP-трафик сети 192.168.240.0/24
На этом этапе все хорошо, но прежде чем сказать, что RDP-сервис не отвечает на 192.168.240.1:3389 - отключите файрволл. Хоть вы и говорите, что нет соединения, но я бы покапал в этом направлении. Сейчас я нарисовал жирный крест - так трафик не идет.
Далее предположим, что на серверный конец туннеля приходит такой пакет IP<from:192.168.240.13:* to:192.168.240.1:3389>, то есть обращение к RDP-сервису. Я обозначил этот пакет кружком с цифрой (1). Ясно, что через VPN интерфейс данный пакет никто не обработает. Порт 3389 никто не открывал.
Тогда здесь нужен NAT и далее ПЕРЕНАПРАВЛЕНИЕ пакетов. У меня нет под рукой машины с Виндоуз для того, чтобы сгенерить скриншоты, поэтом продолжаю по картинкам (ресурс вами приведенный что-то помер на данный момент), которые уже приводили. Выбрать IPv4 -> Преобразование сетевых адресов. Там ДОЛЖЕН УЖЕ БЫТЬ интерфейс, который VPN-сервера. Если нет, покажите что у Вас в "Интерфейсы сети". На __интерфейсе VPN-сервера__ происходит NAT (преобразование адреса). Заменять будем поле пакета КУДА (to или dst). Заменяем разумеется на 192.168.0.103. Если все правильно настроили, то получится пакет
в состоянии (2) --- IP<from:192.168.240.13:* to:192.168.0.103:3389>.
Все бы ничего, но теперь интерфейс VPN-сервера не знает, что делать с этим пакетам. Это уже ни его пакет. Данный пакет отдается в службу маршрутизации, которая посмотрит на адрес доставки (192.168.0.103) и признает в нем известное для нее место - локальный интерфейс. Куда он и будет передан. Пакет долетел, нарисовал состояние (3).
Во всем этом процессе, все бы ничего, но нужно смотреть за настройками файрволла.
Он пронизывает все направления передачи трафика, в том числе между сетевыми интерфейсами. Пробуйте его отключить. Если не помагает, значит где-то ошиблись в конфигурировании. Конечно, я тоже могу ошибаться, поскольку пишу с листа и попробовать негде. Но других идей больше нет :)
[ATTACH=CONFIG]5590[/ATTACH]