none
клиенты vpn не видят компы внутри сети к которой подключаются RRS feed

  • Вопрос

  • добрый день.

    подскажите пожалуйста: имеется небольшая сеть на базе win 2003. внешний ip выглядит как 194.240.хх.хх, внутренний 192.168.0.1. у рабочих машин в этой сети адреса 192.168.0.2 -192.168.0.100. я на win 2003 поднял NAT и сервер vpn. надо из ноутбуков подключаться в данному серверу и видеть все сетевые ресурсы (папки на сервере). при подключении к серверу через VPN - получаю сообщение о том, что удачно подключился, выданы ip адреса 192.168.0.121 - ноутбуку и серверу 192.168.0.122. Если я правильно понимая теперь я должен с ноутбука увидеть подключенную сеть - но ничего не происходит - что я делаю не так? сервер не пингуется....

    заранее спасибо за ответ.

    16 декабря 2010 г. 10:16

Ответы

  • Для PPTP-клиента необходимо, чтобы до VPN-шлюза "доходили" GRE (IP 47) и TCP 1723.
    Для L2TP-клиента необходимо, чтобы до VPN-шлюза "доходили" IKE (UDP 500), IP 50 (ESP, там будет UDP 1701). Если VPN-шлюз находится за NAT, то необходимо, чтобы VPN-шлюз "поддерживал" NAT-T b "пробрасывал" NAT-T (UDP 4500), IKE (UDP 500), UDP 1701.

    Лучше использовать L2TP или "SSL-VPN".

    17 декабря 2010 г. 7:27
    Отвечающий
  • Разрешение имен широковещанием с помощью NetBT работать будет лишь для клиентов VPN, а вот разрешение их имен клиентами в сети за VPN-шлюзом работать не будет. Ну, по крайней мере, я не знаю, как это возможно реализовать с помощью RRAS. Некоторые маршрутизаторы позволяют транслировать широковещательные дейтаграммы на своих VPN-клиентов...

    Задействуйте WINS/DNS.

    17 декабря 2010 г. 14:12
    Отвечающий
  • Я уже давал ответ на похожий вопрос в соседней ветке: впн-клиент, отправляя пакет на 192.168.0.1 предполагает, что это та же сеть(192.168.0.0 255.255.255.0), что и его интерфейс, поэтому пакет не пойдет на шлюз, а уйдет в локальную сеть(если отыщется MAC-адрес нужного узла с помощью протокола ARP). Т.е. удаленной сети он не достигнет.

    Вы две удаленные сети с одинаковыми адресами соединили через впн. Либо разделите на разные айпи подсети, либо используйте другие технологии(уровня L2), например, мост вместо впн.

    • Предложено в качестве ответа Den V. G_ 16 декабря 2010 г. 15:14
    • Помечено в качестве ответа Vinokurov YuriyModerator 20 декабря 2010 г. 9:44
    16 декабря 2010 г. 13:41

Все ответы

  • Можно поподробнее о настройках vpn-сервера, как раздаются адреса, DHCP или пул, желательно ipconfig /all с сервера и клиента! Является ли сервер впн одновременно и шлюзом для сети? Настроени маршрутизация ip?
    16 декабря 2010 г. 11:01
  • на серваке ipconfig /all :

     

       Имя компьютера  . . . . . . . . . : server

       Основной DNS-суффикс  . . . . . . :

       Тип узла. . . . . . . . . . . . . : неизвестный

       IP-маршрутизация включена . . . . : да

       WINS-прокси включен . . . . . . . : да

    LAN - Ethernet адаптер:

       DNS-суффикс этого подключения . . :

       Описание  . . . . . . . . . . . . : Intel(R) PRO/1000 MT Desktop Adapter

       Физический адрес. . . . . . . . . : 00-0E-0C-06-08-EE

       DHCP включен. . . . . . . . . . . : нет

       IP-адрес  . . . . . . . . . . . . : 192.168.0.1

       Маска подсети . . . . . . . . . . : 255.255.255.0

       Основной шлюз . . . . . . . . . . :

    I-net - Ethernet адаптер:

       DNS-суффикс этого подключения . . :

       Описание  . . . . . . . . . . . . : Intel(R) 82566DC Gigabit Network Connection

       Физический адрес. . . . . . . . . : 00-16-76-C9-0E-B0

       DHCP включен. . . . . . . . . . . : нет

       IP-адрес  . . . . . . . . . . . . : 194.24.240.166

       Маска подсети . . . . . . . . . . : 255.255.255.240

       Основной шлюз . . . . . . . . . . : 194.24.240.161

       DNS-серверы . . . . . . . . . . . : 84.52.107.107

                                           195.177.123.1

    Интерфейс RAS-сервера - PPP адаптер:

       DNS-суффикс этого подключения . . :

       Описание  . . . . . . . . . . . . : WAN (PPP/SLIP) Interface

       Физический адрес. . . . . . . . . : 00-53-45-00-00-00

       DHCP включен. . . . . . . . . . . : нет

       IP-адрес  . . . . . . . . . . . . : 192.168.1.120

       Маска подсети . . . . . . . . . . : 255.255.255.255

       Основной шлюз . . . . . . . . . . :

     

    на машинке, которая должна подключаться :

     

            Имя компьютера  . . . . . . . . . : engineer

            Основной DNS-суффикс  . . . . . . :

            Тип узла. . . . . . . . . . . . . : смешанный

            IP-маршрутизация включена . . . . : нет

            WINS-прокси включен . . . . . . . : нет

    Подключение по локальной сети - Ethernet адаптер:

            DNS-суффикс этого подключения . . :

            Описание  . . . . . . . . . . . . : Atheros L1 Gigabit Ethernet 10/100/1000Base-T Controller

            Физический адрес. . . . . . . . . : 00-1B-FC-FF-4E-7E

            Dhcp включен. . . . . . . . . . . : нет

            IP-адрес  . . . . . . . . . . . . : 192.168.0.3

            Маска подсети . . . . . . . . . . : 255.255.255.0

            Основной шлюз . . . . . . . . . . : 192.168.0.1

            DNS-серверы . . . . . . . . . . . : 192.168.0.1

    европак Питер - PPP адаптер:

            DNS-суффикс этого подключения . . :

            Описание  . . . . . . . . . . . . : WAN (PPP/SLIP) Interface

            Физический адрес. . . . . . . . . : 00-53-45-00-00-00

            Dhcp включен. . . . . . . . . . . : нет

            IP-адрес  . . . . . . . . . . . . : 192.168.1.125

            Маска подсети . . . . . . . . . . : 255.255.255.255

            Основной шлюз . . . . . . . . . . : 192.168.1.125

    сервер является одновременно и шлюзом и впн. адреса раздаются из статического пула. по поводу маршрутизации - я не силен в этом, где посмотреть?

    16 декабря 2010 г. 12:43
  • Я уже давал ответ на похожий вопрос в соседней ветке: впн-клиент, отправляя пакет на 192.168.0.1 предполагает, что это та же сеть(192.168.0.0 255.255.255.0), что и его интерфейс, поэтому пакет не пойдет на шлюз, а уйдет в локальную сеть(если отыщется MAC-адрес нужного узла с помощью протокола ARP). Т.е. удаленной сети он не достигнет.

    Вы две удаленные сети с одинаковыми адресами соединили через впн. Либо разделите на разные айпи подсети, либо используйте другие технологии(уровня L2), например, мост вместо впн.

    • Предложено в качестве ответа Den V. G_ 16 декабря 2010 г. 15:14
    • Помечено в качестве ответа Vinokurov YuriyModerator 20 декабря 2010 г. 9:44
    16 декабря 2010 г. 13:41
  • то есть если мой ноутбук будет пытаться подключиться через впн к указанной выше сети из другого места - другого провайдера, где присваивается динамический ip адрес, то все заработает?
    16 декабря 2010 г. 13:51
  • спасибо за разъяснение. как только поменял на подключаемом компе ip на 192.168.1.23 то сразу попал куда нужно. еще раз спасибо
    16 декабря 2010 г. 14:53
  • оказывается есть продолжение вопроса: сервер как \\server\files - определяться не хочет. а вот как \\192.168.0.1\files - работает. в чем затык? и в плане совета - я так понимаю, внутри сеток адресация типа 192.168.0.1 - 192.168.0.254 - одна из самых распространенных и я рискую при подключении к интернету из такой сети получить по dhcp один из адресов типа 192.168.0.23 - и из-за этого не увидеть то, что мне надо, хотя будет сообщение, что я подключился ОК. как поступают знающие люди? и еще для данного типа связи на файрволе какие надо открыть порты?
    16 декабря 2010 г. 15:17
  • оказывается есть продолжение вопроса: сервер как \\server\files - определяться не хочет. а вот как \\192.168.0.1\files - работает. в чем затык?

    В разрешении имен: т.к. широковещательные пакеты по умолчанию не маршрутизируются, то разрешение узлов netbios не работает через впн.

    Поднимите DNS-сервер на 192.168.0.1 и пропишите имена, узлов, к которым необходим доступ. И настройте впн-сервер, чтоб отдавал адрес самого себя, как DNS-сервера. Возможно, это можно будет сделать и через WINS вместо DNS.

    По поводу адресации - сложно дать совет, вообще, для частных сетей предусмотрено 3 диапазона 172.16.0.0-172.31.0.0/24,    10.0.0.0/8 и 192.168.0.0/16. Имхо, 172я сеть используется наиболее редко.

    16 декабря 2010 г. 15:45
  • По поводу общей сети с клиентами VPN.
    Ден, в "соседней теме", да и здесь, Вы упускаете из виду, что сервер RRAS выступает в роли ARP-проски (т.е. отвечает на ARP-запрос "по поводу" IP-адреса VPN-клиента своим MAC-адресом), так что проблема IP-связности между клиентами VPN и сетями за VPN-шлюзом вызвана не тем, что "впн-клиент, отправляя пакет на 192.168.0.1 предполагает, что это та же сеть". Иначе, как по Вашему, хост в сети за VPN-шлюзом "отвечает" VPN-клиенту с адресом из той же стеи? Как правило, проблемы с взаимодействием VPN-клиентов с хостами за VPN-шлюзом в общей подсети вызваны коммутатором.

    В любом случае, Вы правы в том, что клиентов VPN крайне желательно определять в отдельную сеть и настраивать маршрутизацию с этой сетью.

    16 декабря 2010 г. 19:22
    Отвечающий
  • Добрый день.

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

    17 декабря 2010 г. 6:12
  • Для PPTP-клиента необходимо, чтобы до VPN-шлюза "доходили" GRE (IP 47) и TCP 1723.
    Для L2TP-клиента необходимо, чтобы до VPN-шлюза "доходили" IKE (UDP 500), IP 50 (ESP, там будет UDP 1701). Если VPN-шлюз находится за NAT, то необходимо, чтобы VPN-шлюз "поддерживал" NAT-T b "пробрасывал" NAT-T (UDP 4500), IKE (UDP 500), UDP 1701.

    Лучше использовать L2TP или "SSL-VPN".

    17 декабря 2010 г. 7:27
    Отвечающий
  • Добрый день.

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


    Да, еще нужно пробросить протокол GRE(если не ошибаюсь, №47).
    17 декабря 2010 г. 7:34
  • По поводу общей сети с клиентами VPN.
    Ден, в "соседней теме", да и здесь, Вы упускаете из виду, что сервер RRAS выступает в роли ARP-проски (т.е. отвечает на ARP-запрос "по поводу" IP-адреса VPN-клиента своим MAC-адресом), так что проблема IP-связности между клиентами VPN и сетями за VPN-шлюзом вызвана не тем, что "впн-клиент, отправляя пакет на 192.168.0.1 предполагает, что это та же сеть". Иначе, как по Вашему, хост в сети за VPN-шлюзом "отвечает" VPN-клиенту с адресом из той же стеи? Как правило, проблемы с взаимодействием VPN-клиентов с хостами за VPN-шлюзом в общей подсети вызваны коммутатором.

    В любом случае, Вы правы в том, что клиентов VPN крайне желательно определять в отдельную сеть и настраивать маршрутизацию с этой сетью.

    Большое спасибо, Дмитрий, я упустил это из виду! Сам не использовал арп-прокси, предпочитая разделять сети и использовать маршрутизацию-легче диагностика и администрирование.

    В подтверждение Ваших слов с ангоязычного форума:

    http://social.technet.microsoft.com/Forums/en/winserverNIS/thread/2e81cacb-df7a-4eb5-a83c-1ee908c4f51a

    The answer is pretty simple. If your RRAS clients are using addresses from DHCP so that they get IP addresses in the same IP as the LAN machines, you do not need any routing. The RRAS server does proxy ARP on the LAN for the remotes do that they appear to be connected to the LAN.

       If you have a reasonable number of remote connections you should not be using that technique. It was designed for occasional use by admins who don't know how routing works. The remotes should be in their own IP subnet. That subnet should be routed through the RRAS server.
     

    17 декабря 2010 г. 9:55
  • Дмитрий, пользуясь случаем, можно ли в данной конфигурации настроить Broadcast Name Resolution, чтоб не использовать лишние сущности в виде ДНС? В документации http://technet.microsoft.com/en-us/library/cc738660(WS.10).aspx указана такая возможность. Достаточно ли будет на сервере установить тип H-node (M-node) на сервере и включить NetBIOS over TCP/IP?

    17 декабря 2010 г. 10:43
  • Разрешение имен широковещанием с помощью NetBT работать будет лишь для клиентов VPN, а вот разрешение их имен клиентами в сети за VPN-шлюзом работать не будет. Ну, по крайней мере, я не знаю, как это возможно реализовать с помощью RRAS. Некоторые маршрутизаторы позволяют транслировать широковещательные дейтаграммы на своих VPN-клиентов...

    Задействуйте WINS/DNS.

    17 декабря 2010 г. 14:12
    Отвечающий
  • Разрешение имен широковещанием с помощью NetBT работать будет лишь для клиентов VPN, а вот разрешение их имен клиентами в сети за VPN-шлюзом работать не будет.

    Понятно, автору, как я понял,как раз это и нужно.
    17 декабря 2010 г. 15:21
  • Добрый день.

    подскажите пожалуйста следующее: при подключении через vpn основной шлюз на подключенной машинке меняется на другое значение, и человек "ходит" в интернет через vpn сервер. я так понимаю, что если подключится один-два человека - то может и не страшно, а вот если 20 человек, то канала может и не хватить... как и где прописать так, чтобы вне зависимости от подключенного или не подключенного vpn шлюз всегда оставался 192.168.1.1 - можно ли так сделать и будет ли так работать?

    заранее благодарен 

    • Предложено в качестве ответа Den V. G_ 21 декабря 2010 г. 12:07
    21 декабря 2010 г. 11:45
  •  как и где прописать так, чтобы вне зависимости от подключенного или не подключенного vpn шлюз всегда оставался 192.168.1.1 - можно ли так сделать и будет ли так работать?

    На клиенте в нстройках впн-соединения: св-ва TCP/IP->кнопка доп. пар-ры->общие, снять флаг "использовать основной шлюз в удаленной сети". Тогда при поднятии впн-соединения шлюз не будет подменяться. Доступ к удаленной сети останется, а пакеты, предназначенные неизвестным сетям будут уходить на шлюз, прописанный в на физическом интерфейсе.  

    21 декабря 2010 г. 12:18
  • СПАСИБО !!! все получилось.
    21 декабря 2010 г. 12:28