Нужна консультация. Возможно ли ограничение на прохождения теста по внутреннему сетевому адресу? При тестировании в компьютерном классе у нас все компьютеры видны не под локальными IP адресами, а под одним (настоящим IP адресом сервера Moodle), студенты с телефонами видны с адресами, полученными от провайдеров. Возможно ли настроить сеть или сервер Moodle, чтобы регистрировались локальные адреса компьютеров? Если да, то как это сделать?
В настройках теста есть раздел «Дополнительные ограничения на попытки» с параметром «Необходим сетевой адрес», в справке к которому написано:
«Вы можете разрешить доступ к тесту только из определенных подсетей локальной сети или Интернета, задав разделенный запятыми список частичных или полных IP-адресов. Это может быть особенно полезно, если вы хотите, чтобы тест можно было пройти только из определенной аудитории.»
Примеры:
192.168.10.1
192.168.
231.3.56.10-20
192.168.10.1,192.168.,231.3.56.10-20
Вот и узнайте IP всех компов в аудитории и забейте в эту строку, потом попробуйте пройти тест с другого IP
Вадим, спасибо за оперативный ответ. Вы ответили на первую часть вопроса - Moodle понимает локальные адреса. Осталось понять где настроить нашу сеть, чтобы MOODLE понимал и локальные и настоящие IP адреса. Например, студент проходит тест в классе с компьютера с IPадресом 192.93.111.3. Если я в MOODLE смотрю информацию о нём, то показывается, что он тестировался с адреса 188.93.111.3. Дополнительно проверил, если я в тесте ставлю разрешение только с этого адреса, то у студента пропадает разрешение. Из общих представлений, мне кажется, что за адресацию к серверу Мудл отвечает DNS сервер, но наш сетевой администратор предположил, что в самой МУДЛ может быть какая-то сетевая настройка.
В нашем ВУЗе только вводятся электронные курсы, у многих из вас этот процесс запущен уже давно. Теперь я не сомневаюсь, что к MOODLE, можно обращаться и из внешней и из внутренней сети. Коллеги помогите мне настроить нашу систему. MOODLE версия 3.3, стоит по юниксом на виртуальной машине.
PS 188.93.111.3 - это адрес нашей Мудлы. Как получается, что в отчёте этот адрес присваивается всем компьютерам локальной сети?
Как получается, что в отчёте этот адрес присваивается всем компьютерам локальной сети?
Не знаю, спрашивайте у админа вашей локальной сети. Может сервер с Мудл ещё и шлюзом каким-то для всех ПК в локалке выступает?
У меня Мудл показывает нормальные адреса из всех подсетей в локалке. Сервер Мудл - 10.0.0.8
В отчетах вижу:
10.0.0.1
10.90.0.231
10.10.20.114
10.10.20.143
10.10.20.127
10.90.0.228
10.50.210.191
И т. д. У нас вся локальная сеть на 10.*.*.*
Ну и, естественно, вижу внешние IP адреса
Здравствуйте!
Подскажите, пожалуйста, как ставить маску фильтра сети ?
эта не сработала
10.*.*.*
10.*.*.* это 10.0.0.0/8 или 10.0.0.0/255.0.0.0 или 10.0.0.0-10.255.255.255 или 10.
Как получается, что в отчёте этот адрес присваивается всем компьютерам локальной сети?Это значит, что запросы проходят через proxy-сервер.
Проблема решается достаточно просто, но нужно знать технические подробности конфигурации вашего moodle
Я не знаю где эти настройки смотреть. Распечатку конфигурации загрузил ниже...
Извините за нескромный вопрос. А сервер Moodle где находится? В локальной сети или нет?
Вроде бы в локальной, на виртуальной машине. Но, он как то перекидывает локальные обращения через внешнюю сеть. Системщики нашей сети говорят, что это в настройках МУдл. У меня нет опыта разобраться, настройки по умолчанию стоят следующие...(приложенный файл).
Нет, дело не в moodle. Moodle получает тот адрес, который ему отдаёт веб-сервер, на котором он запущен. Если веб-сервер находится за реверсивным прокси, и прокси передаёт правильные заголовки с адресом подключающегося, то moodle сможет забрать их и оттуда.
В остальном, должна быть правильно настроена маршрутизация, чтобы пакеты от студенческих машин попадали на сервер или реверсивный прокси без преобразований адресов (NAT). Если пакеты проходят NAT или Маскарадинг, то информация об исходном адресе запроса теряется.
Искать ошибки в такой ситуации должны все совместно. Без представления о структуре вашей сети дистанционно подсказать что-то невозможно.
Настройки DNS-сервера вообще никак не связаны с тем, какие адреса стоят в пакетах, приходящих на веб-сервер.
Коллеги, спасибо! После того, как я показал нашу переписку, сетевой администратор проблему решил. При обращении из локальной сети и из внешней IP адреса студентов показываются верно.
Заработало!
Здравствуйте, у меня такая же проблема можете подсказать как решили данную проблему? Показывает только один IP адрес внешний из-за этого я не могу распределять компьютерные аудитории то есть группа А в аудитории №219, а группа Б в аудитории №220
За ранее спасибо
К сожалению, я не знаю, как наш администратор решал задачу. Помню только, что при решении был потерян какой то более нужный функционал и пришлось отказаться. У нас студенты тестируются не в компьютерных классах, а в обычных, используя свои смартфоны. Таким образом фильтрация по IP адресам стала ненужной.
Решить проблему с ip адресами может только администратор сети, без представления о структуре вашей сети подсказать ничего нельзя.
Если рассматриваете альтернативные решения, то вот вариант.
Можно использовать плагин quizaccess_onesession и пароль на тест. Студенты откроют тест, вы вводите им сами пароль. Если даже кто-то подсмотрел пароль, из другого места подключить не удастся, так как с onesession возможно тестирование только на том же устройстве, на котором оно начато.
Если рассматриваете альтернативные решения, то вот вариант.
Можно использовать плагин quizaccess_onesession и пароль на тест. Студенты откроют тест, вы вводите им сами пароль. Если даже кто-то подсмотрел пароль, из другого места подключить не удастся, так как с onesession возможно тестирование только на том же устройстве, на котором оно начато.
Есть такая опция в config.php $CFG->getremoteaddrconf - она определяет какой заголовок в запросе будте использоваться для определения IP адреса клиента. По умолчания она 0 и это значит, что сначала для определения адреса используется заголовок HTTP_CLIENT_IP, потом HTTP_X_FORWARDED_FOR и уже потом REMOTE_ADDR.
Если $CFG->getremoteaddrconf = GETREMOTEADDR_SKIP_HTTP_CLIENT_IP, то moodleбудет игнорировать HTTP_CLIENT_IP и будет пытаться использовать заголовок HTTP_X_FORWARDED_FOR ( который обычно устанавливают для запросов от прокси-сервера )
Если $CFG->getremoteaddrconf = GETREMOTEADDR_SKIP_HTTP_X_FORWARDED_FOR, то будет игнорироваться заголовок HTTP_X_FORWARDED_FOR, а адреса клиента будет определяться через заголовок REMOTE_ADDR.
Вообще, по хорошому, $CFG->getremoteaddrconf должен быть равен "3" (это игнорирование всего кроме заголовока REMOTE_ADDR)
потому, что разработчики moodle до сих пор не потрудились добавить еще одну настройку, которая бы говорила для каких ip-адресов (REMOTE_ADDR) можно использовать заголовок HTTP_X_FORWARDED_FOR или HTTP_CLIENT_IP, т.к. подпихнуть такой заголовок с "правильным" адресом не представляет труда.
В вашем случае, когда moodle доступен через прокси, нужно убедиться, что этот прокси-сервер устанавливает заголовок HTTP_X_FORWARDED_FOR.
Тогда вы в логах будете видеть адреса клиентов и ограничения доступа тоже будут по настоящему адресу клиента.
Если moodle доступен в локальной сети без прокси, то в запросах не будет заголовка HTTP_X_FORWARDED_FOR и будет виден адрес в локальной сети.
Если $CFG->getremoteaddrconf = GETREMOTEADDR_SKIP_HTTP_CLIENT_IP, то moodleбудет игнорировать HTTP_CLIENT_IP и будет пытаться использовать заголовок HTTP_X_FORWARDED_FOR ( который обычно устанавливают для запросов от прокси-сервера )
Если $CFG->getremoteaddrconf = GETREMOTEADDR_SKIP_HTTP_X_FORWARDED_FOR, то будет игнорироваться заголовок HTTP_X_FORWARDED_FOR, а адреса клиента будет определяться через заголовок REMOTE_ADDR.
Вообще, по хорошому, $CFG->getremoteaddrconf должен быть равен "3" (это игнорирование всего кроме заголовока REMOTE_ADDR)
потому, что разработчики moodle до сих пор не потрудились добавить еще одну настройку, которая бы говорила для каких ip-адресов (REMOTE_ADDR) можно использовать заголовок HTTP_X_FORWARDED_FOR или HTTP_CLIENT_IP, т.к. подпихнуть такой заголовок с "правильным" адресом не представляет труда.
В вашем случае, когда moodle доступен через прокси, нужно убедиться, что этот прокси-сервер устанавливает заголовок HTTP_X_FORWARDED_FOR.
Тогда вы в логах будете видеть адреса клиентов и ограничения доступа тоже будут по настоящему адресу клиента.
Если moodle доступен в локальной сети без прокси, то в запросах не будет заголовка HTTP_X_FORWARDED_FOR и будет виден адрес в локальной сети.
Проблемма рещена. Может кому понадобиться на Проксе нужно создать 2 моста один из которых должен отвечать за внешную айпи, а вторая за внутренную и + настроить ДНС вот и все дела а мы ломали 2 дня голову над этим но есть результать)))))))
Разработчики moodle не сделали такой настройки, так как эту проблему можно (и нужно решать) на уровне веб-сервера.
В апаче есть параметр RemoteIPInternalProxy, в который можно прописать ip адреса прокси-серверов, которым можно доверять. Для них в remote_addr будет адрес, который передал прокси в заголовке. Для остальных будет использоваться адрес клиента, даже если есть заголовки.
Таким образом я настраивал правильное получение адреса из отдаленного корпуса не соединенного локальной сетью. В далеком корпусе настроено transparent proxy, прокси возвращал в заголовке реальный адрес из локальной сети, в RemoteIPInternalProxy был указан адрес прокси. В результате при тестировании можно было ограничивать по ip адреса аудитории из другой локальной сети. Но не уверен, что сейчас такой подход работает до сих пор, так как повсеместный переход на https сильно усложняет создание transparent proxy.
В nginx для того же можно использовать модуль Geo, или простую регулярку по $remote_addr, чтобы решать, где резать заголовки, а где нет.
В общем, если вебсервер находится за прокси, то прямой доступ к такому серверу должен быть невозможен даже из локальной сети. Прокси должна резать все заголовки с адресами и заменять их своими, тогда пропихнуть неправильный адрес будет невозможно.