PPTP и разрешение имен на клиентах
-
Да, домен.
Правило приложил к сообщению.
-
DNS клиентам раздаю, но имена компов не разрешаются.
Т.е. вы раздаете адрес внутреннего DNS сервера подключающимся по PPTP удаленным клиентам ? А клиенты DNS-сервер пингуют?
Команда nslookup <имя-машины-в-вашей-внутренней-сети> на удаленном подключившемся клиенте что говорит?P.s. Скрин правил fw на LAN можно ?
-
Т.е. вы раздаете адрес внутреннего DNS сервера подключающимся по PPTP удаленным клиентам ?
Да.
А клиенты DNS-сервер пингуют?
Пинги не идут.
Команда nslookup <имя-машины-в-вашей-внутренней-сети> <ip-адрес-вашего-dns-сервера>на удаленном подключившемся клиенте что говорит?</ip-адрес-вашего-dns-сервера>
C:\Users\user>nslookup s2008 192.168.10.201
╤хЁтхЁ: dcserver.group.local
Address: 192.168.10.201*** dcserver.group.local не удалось найти s2008: Server failed
Скрин правил fw на LAN можно ?
Прикладываю.
-
Пинги не идут.
Они и не будут идти. У вас на PPTP не разрешен ICMP. Разрешите (временно) на PPTP ВСЕ протоколы.
Далее , последнее активное правило на LAN - оно лишнее и бестолковое, т.е. толку от него - нуль. Советую (временно) разрешить на LAN все протоколы, поставив это правило самым верхним.
Вопрос - не пересекаются ли адреса сетей ваших PPTP-клиентов с вашей LAN? Какую адресацию получают ваши клиенты при подключении?
Нарисуйте схему сети с адресами (адрес dns-сервера на ней укажите обязательно). Уверен на 99,9 %, что pfsense - не причем. -
Далее , последнее активное правило на LAN - оно лишнее и бестолковое, т.е. толку от него - нуль. Советую (временно) разрешить на LAN все протоколы, поставив это правило самым верхним.
Это правило заворачивает пользователей локальной сети на прокси!
А правила которые идут перед последним активным - позволяют пропускать часть ПК/оборудования в обход прокси.По остальному попробую, спасибо!
Они и не будут идти. У вас на PPTP не разрешен ICMP. Разрешите (временно) на PPTP ВСЕ протоколы.
Разрешил все протоколы - пинги пошли. Но имена ПК не разрешаются.
Схему сети прилагаю.
-
Далее , последнее активное правило на LAN - оно лишнее и бестолковое, т.е. толку от него - нуль. Советую (временно) разрешить на LAN все протоколы, поставив это правило самым верхним.
Это правило заворачивает пользователей локальной сети на прокси!
А правила которые идут перед последним активным - позволяют пропускать часть ПК/оборудования в обход прокси.По остальному попробую, спасибо!
С какой радости ? Правила по заворачиванию пишутся в NAT (port forward etc.) . И зачем заворачивать (а заворачивается ли вообще?), если есть прозрачный режим работы в сквиде?! Т.е. все обращения на 80-ый порт "заворачиваются" на порт прокси автоматом?
Ну и накручено у вас там :'(
P.s. Попробуйте выдавать РРТР-клиентам адреса из вашей LAN-сети при их подключении, предварительно выделив им незанятый диапазон.
-
Попробуйте выдавать РРТР-клиентам адреса из вашей LAN-сети при их подключении, предварительно выделив им незанятый диапазон.
Так все и происходит.
Схема сети в моём предыдущем сообщении.
-
Сперва действия по правилам fw на LAN и PPTP выполните.
Далее, по выводу команды nslookup :
C:\Users\user>nslookup s2008 192.168.10.201
╤хЁтхЁ: dcserver.group.local
Address: 192.168.10.201*** dcserver.group.local не удалось найти s2008: Server failed
Могу поздравить. Доступ к DNS серверу у ваших внешних клиентов имеется. У вас сам сервер DNS не может "разрешить" имя s2008 в IP-адрес. Разве это не видно?
Причем здесь pfsense ? Этот s2008 вообще домене или в раб. группе? Если в раб. группе - поднимите еще и службу WINS на DC или создайте принудительно A-запись для этого сервера.Что говорит в таком случае команда nslookup s2008.group.local 192.168.10.201 извне и внутри вашей LAN ?
Вобщем разберитесь с DNS. Врядли pfsense здесь виноват.
-
Врядли pfsense здесь виноват.
Я pfSense ни в чем и не обвиняю! Прошу помощи…
Что говорит в таком случае команда nslookup s2008.group.local 192.168.10.201 извне и внутри вашей LAN ?
Извне:
C:\Users\Roman>nslookup s2008.group.local 192.168.10.201
╤хЁтхЁ: dcserver.group.local
Address: 192.168.10.201╚ь : s2008.group.local
Address: 192.168.10.200C:\Users\Roman>ping s2008
При проверке связи не удалось обнаружить узел s2008.
Проверьте имя узла и повторите попытку.Внутри:
C:\Users\Администратор.GROUP>nslookup s2008.group.local 192.168.10.201
╤хЁтхЁ: dcserver.group.local
Address: 192.168.10.201╚ь : s2008.group.local
Address: 192.168.10.200C:\Users\Администратор.GROUP>ping s2008
Обмен пакетами с s2008.group.local [192.168.10.200] с 32 байтами данных:
Ответ от 192.168.10.200: число байт=32 время<1мс TTL=128
Ответ от 192.168.10.200: число байт=32 время<1мс TTL=128
Ответ от 192.168.10.200: число байт=32 время<1мс TTL=128
Ответ от 192.168.10.200: число байт=32 время<1мс TTL=128Статистика Ping для 192.168.10.200:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек -
Ув. Angel_19
Ваши вопросы по настройке DNS на платформе Windows выходят за рамки этого форума. Сходите на ixbt, opennet etc.P.s. Ваши клиенты в ваш домен не входят. Хотите - включайте WINS на DC, указывайте адрес WINS-сервера в настройках PPTP на pfsense и явно указывайте адрес WINS-сервера (192.168.10.201) в настройках сетевых подключений на серверах\раб. станциях в вашей LAN. После того как ваши локальные машины зарег-ся в WINS - вы сможете обращаться к ним по коротким именам.
Вариант 2. Вручную на каждом удаленном клиенте в сетевых настройках указать явно DNS-суффикс - group.local
Не хотите настраивать? Тогда в чем проблема вашим удаленным клиентам обращаться по FQDN к вашим локальным машинам? Т.е. xxx.group.local вместо просто xxx ?
-
werter - спасибо. Помогли! Все ваши советы учту.
