Я пытаюсь настроить VPN с использованием маршрутизации и удаленного доступа.
Я пробовал две конфигурации: одну с одной сетевой картой, а другую с двумя сетевыми картами.
Я могу подключиться через свою VPN и получить IP-адрес от DHCP-сервера, но я ничего не могу «ВИДЕТЬ». Под этим я подразумеваю, что клиент кажется полностью слепым для офисной сети, это означает:
У меня вообще не было проблем с подключением к VPN (я думал, что были, но это было связано с тестовым маршрутизатором, который я дал).
Это не похоже на проблему брандмауэра / маршрутизатора, поскольку я настроил его так, чтобы пропускать трафик VPN и пересылать на правильный сервер.
Я думаю, это подтверждается, поскольку журналы событий сервера VPN показывают успешные проверки (то есть события входа в систему).
Однако он показывает следующее событие сразу после того, как происходит событие успешного входа в систему (и я не знаю, нормально ли это, но не ожидал, что это будет - клиент VPN не отключается).
An account was logged off.
Subject:
Security ID: [DomainName]\[UserName]
Account Name: [UserName]
Account Domain: [DomainName]
Logon ID: 0x[xxxxxx]
Logon Type: 3
Это событие генерируется, когда сеанс входа в систему разрушен. Это может быть положительно коррелировано с событием входа в систему с использованием значения идентификатора входа в систему. Идентификаторы входа в систему уникальны только между перезагрузками на одном компьютере.
Я не уверен, пригодится ли это, но Wireshark показывает, что я успешно подключаюсь, а затем загружаю зашифрованные пакеты, о чем я подозревал:
Однако интересно следующее (что я не могу объяснить):
Я не могу объяснить пункты 1 или 2 - я ожидал увидеть ICMP, но проблема, похоже, заключается в отправке трафика в (D). Чтобы проверить это, я отправил эхо-запрос (D) от (C) и ПОЛУЧИЛ ответ, однако Я НЕ УВИДЕЛ коррелирующий трафик ICMP на (D) (мог ли это быть трафик GRE?). Мне это кажется странным, но (C) определенно проверяет связь с нужной машиной, поскольку она перестает отвечать, когда я отключаюсь (D) от VPN.
Также обратите внимание, что я не вижу трафика на (D) на сетевые адреса VPN, только на маршрутизаторы, для которых настроена переадресация портов. Может быть, это какая-то проблема с маршрутизацией?
У VPN-сервера, похоже, есть проблема с пингом (D) - говорит НЕТ РЕСУРСОВ, PathPing показывает, что он использует интерфейс (A). и эта проблема возникает только при пинге (D), все остальное пингует без проблем.
Я изменил RRAS на настройку с одним сетевым адаптером, и проблема отсутствия ресурсов исчезла - я, похоже, могу пинговать клиента со всех машин, но не могу ничего пинговать от клиента. Я говорю, как будто когда я проверяю связь с клиентом, это занимает менее 1 мс (имейте в виду, что это происходит через Интернет и у разных интернет-провайдеров), и я не вижу никакого ICMP-трафика на VPN-сервере - плюс, когда я отключаю клиента, он все еще можно пинговать!?! (Как будто VPN-сервер отвечает на эхо-запросы от имени клиента.) В то время как это происходит, VPN-сервер получает тайм-ауты, когда пингует отключенного клиента. ОЧЕНЬ СТРАННО!
После того, как вы оставили его на некоторое время (пить чай, есть что-то вроде еды), VPN-сервер вернулся к проблеме Нет ресурсов, а у меня нет пинга в любом направлении. Отключение RRAS и его повторное включение вернули меня туда, где я был только что, теперь я могу пинговать от LAN к клиенту.
Ваша терминология «... увидеть что-нибудь в локальной сети ...» неточна. Что вы имеете в виду под словом «видеть»? Вы имеете в виду, что вы не могли выполнить PING или установить TCP-соединения с хостами в локальной сети? Вы имеете в виду, что какие-то «Сетевые места» или подобные функции не работали?
То, что вы пытаетесь сделать, будет работать нормально. Вероятно, вы не получаете разрешение имен NetBIOS через VPN, потому что вы, вероятно, не используете WINS-сервер в локальной сети. Это было бы моим «экстрасенсорным» предположением относительно того, почему у вас проблемы.
Установка RRAS на контроллер домена делает его многосетевым. Это будет работать, но Microsoft этого не рекомендует. Ты должен подумать о предотвращение регистрации адаптера RRAS в DNS и WINS.
Редактировать:
Не думаю, что в моем ответе есть что-то «надуманное». Я пытаюсь помочь, основываясь на вашем неточном описании ваших проблем (используя термин «видеть», а не на том, что именно не удается, когда вы подключены), и на моем опыте решения подобных проблем. Ваше расплывчатое заявление об использовании RADIUS дало мне некоторое ощущение, что вы не были профессиональным системным администратором (позже подтвержденным вашим комментарием относительно вашей работы) и что вы, вероятно, пытались использовать какой-либо графический инструмент или приложение для доступа к ресурсам в локальной сети, но не не выполнил основные шаги по устранению неполадок, такие как проверка связи уровня 3, разрешение имен и т. д.
Я установил серверы RRAS на контроллерах домена в локальных сетях, подключенных к Интернету за брандмауэрами NAT. Подключаюсь к ним несколько раз в неделю. То, что вы пытаетесь сделать, отлично работает.
Разрешаете ли вы серверу RRAS назначать IP-адреса клиентам из DHCP или вы указали диапазон адресов? Если вы указали диапазон адресов, это диапазон внутри подсети LAN или это другая подсеть? Присваивается ли IP-адрес клиенту при "подключении" того, что вы ожидаете увидеть?
Мне до сих пор неясно, что вы пытались сделать после «подключения», что заставляет вас думать, что вы не можете «видеть» LAN. Можете ли вы выполнить PING IP-адрес сервера RRAS? Можете ли вы установить TCP-соединения со службами, размещенными на сервере RRAS или других серверах в локальной сети, по IP-адресу? Вы получаете разрешение DNS?
Наконец, я не предполагал, что перенос RRAS на другой сервер может заставить что-нибудь работать. Я предположил, что Microosft не рекомендует использовать контроллеры домена с несколькими сетями. RRAS будет нормально работать на контроллере домена, если вы понимаете его последствия.
Изменить 2:
С настройкой сервера RRAS для назначения IP-адресов из DHCP вы видите, что клиенту назначается хороший IP-адрес LAN?
Предполагая, что это так, и вы не можете выполнить эхо-запрос IP-адреса LAN сервера RRAS от клиента, пора начать прослушивание трафика. Я бы нюхал на сервере RRAS и на клиенте, чтобы убедиться, что запрос PING правильно маршрутизирует VPN-соединение (как зашифрованная полезная нагрузка GRE - предположительно, вы используете PPTP). Если прослушивание неудобно, вы можете наблюдать за переданными байтами через диалоговое окно «Состояние» для подключенного клиента в узле «Клиенты удаленного доступа» в оснастке консоли управления «Маршрутизация и удаленный доступ». Хотя я бы понюхал - ничто не заменит просмотр данных по проводам.
Таблица маршрутизации клиента выглядит так, как и следовало ожидать после подключения, я полагаю. По умолчанию клиент Microsoft VPN назначает ваш шлюз по умолчанию для удаленной сети (флажок «Использовать шлюз по умолчанию в удаленной сети» в свойствах TCP / IP «Дополнительно» для VPN-подключения). Если вы отключите его, вместо изменения шлюза по умолчанию вы увидите запись для удаленной сети со шлюзом IP-адреса, назначенного клиентскому адаптеру VPN. Вы не упоминаете, что такое клиентская ОС, но поведение клиента Microsoft VPN немного изменилось в Windows 7 (что позволяет вам явно отключить глупое «классовое» поведение добавления маршрута).
Вероятно, это идет без запроса, но подсеть IP LAN сервера VPN и подсеть LAN, к которой подключен клиент, используют разные диапазоны адресов, не так ли?
Предлагаю изменить вашу IP-подсеть. Если ваш IP-адрес 192.168.x.100 в вашей локальной сети, и вы пытаетесь подключить VPN к удаленному сайту, который также использует подсеть x, ваши проблемы могут иметь смысл.
Измените свою IP-подсеть. Не так-то просто, я знаю ... ха-ха.
Мне кажется, что ваше VPN-соединение настроено неправильно. Чтобы VPN работал, клиент должен изменить некоторые детали своей IP-конфигурации, в частности:
Вы можете проверить это следующим образом: находясь в VPN, откройте оболочку (DOS-приглашение или что угодно) на своем клиенте и запустите (под Windows)
ipconfig /allor (under linux)
cat /etc/resolv.confThis will show you which DNS server you are using. This DNS server either must reside on the target network (the most commonly used solution) or must be able to resolve names of machines in the target network to IP addresses.
Второй тест - проверить вашу маршрутизацию. Под типом Windows
route printUnder Linux, use
sudo route -nvThis will give you output looking like this:
# route -nv Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.180.0.1 10.180.0.169 255.255.255.255 UGH 0 0 0 tun0 10.180.0.169 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.172.0.0 10.180.0.169 255.255.0.0 UG 0 0 0 tun0 10.171.0.0 10.180.0.169 255.255.0.0 UG 0 0 0 tun0 0.0.0.0 192.168.10.254 0.0.0.0 UG 0 0 0 eth0
В приведенном выше примере сети 10.171.0.0/16 и 10.172.0.0/16 маршрутизируются через туннель.
Если какой-либо из этих двух параметров отсутствует на клиенте, проверьте конфигурацию вашего VPN-сервера, действительно ли он настроен для пересылки соответствующих битов клиенту. Очевидно, это зависит от типа используемого вами VPN-сервера.
Похоже, это проблема с трафиком DHCP. Не знаю почему.
Чтобы решить эту проблему, я ВРУЧНУЮ добавил пул статических адресов (он не будет работать, если вы настроите его таким образом при настройке RRAS).
Теперь я могу пинговать. Хотя DNS кажется проблемой, даже если правильные DNS-серверы выбираются клиентом - для решения этой проблемы вам необходимо настроить сетевое соединение VPN на клиенте, чтобы добавить DNS-суффикс.