Информация
Настройка
Новости
Контакты
Новинка
Распродажа
Оплата
Доставка
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • Changelogs
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    RouterOS
    Управление пользователями и OSPF

    Управление пользователями и OSPF

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Управление пользователями и OSPF, RouterOS
     
    p00h
    Guest
    #1
    0
    14.12.2013 14:04:00
    У меня такая конфигурация для простоты: Core MT RB1100AHx2 RouterOS 6.6 в качестве openvpn сервера с адресом 172.31.1.1/32 и также loopback bridge 10.0.0.1/32. RB 951-2n RouterOS 6.7 в качестве vpn клиента с адресом 172.31.1.2/32 и loopback bridge 10.13.13.1/24. Есть DHCP-сеть для локальных клиентов на loopback bridge. Оба роутера включены в OSPF backbone сеть, и (2) сам и все машины за ним могут успешно достучаться до 10.0.0.1. На (1) стоит User Manager сервер и radius клиент на (2). Хочу, чтобы машины за (2) получали адреса от (1) по протоколу radius. В соответствии с идеологией OSPF, я хочу установить адрес radius сервера на (2) как 10.0.0.1, потому что теоретически маршрут к (1) можно изменить через другие роутеры, и я хочу иметь возможность получать адреса от 10.0.0.1 в конечном итоге, даже если нет прямого point-to-point соединения между (1) и (2).

    Пункт 1. Адрес radius сервера на (2) определён как 172.31.1.1. Все машины за (2) могут получать адреса и другие настройки правильно.

    Пункт 2. Адрес radius сервера на (2) определён как 10.0.0.1. Машины НЕ могут получить адреса, и логи на (2) полны сообщений вроде "radius server is not responding".

    Я отследил все соединения и вот что выяснил на самом деле.

    Шаг 0. (2) получает DHCP-запрос от машины за ним.

    Шаг 1. (2) инициирует соединение с (1), на обоих роутерах я вижу соединения от 10.13.13.1 к 10.0.0.1.

    Шаг 2. (1) продолжает получать соединение от 10.13.13.1 к 10.0.0.1 (только RX байты), НО начинает соединение от 172.31.1.1 к 10.13.13.1 с ответом. В результате, DHCP-запрос всегда завершается неудачей. После каждой неудачной попытки (2) добавляет новую запись в лог: "radius server is not responding".

    Может ли эта конфигурация работать? Мне грустно от того, что мне приходится устанавливать адрес radius сервера только как point-to-point адрес.
     
     
     
    p00h
    Guest
    #2
    0
    02.01.2014 13:32:00
    Интересно, неужели никто так и не решил эту проблему?
     
     
     
    p00h
    Guest
    #3
    0
    12.09.2014 05:36:00
    Поднимаю! Проблема все еще существует! Интересно, у кого-нибудь вообще нет таких проблем???
     
     
     
    gius64
    Guest
    #4
    0
    25.01.2016 03:54:00
    Такая же проблема! Нашел какое-нибудь решение?
     
     
     
    p00h
    Guest
    #5
    0
    29.01.2016 08:38:00
    @gius64 к счастью, у меня получилось! Всегда нужно указывать адрес Radius Server как адрес реального интерфейса, а не адрес loopback. Фактические данные обычно передаются между реальными адресами, а не между адресами loopback. У меня огромная сеть с кучей адресов. У Radius Server есть адрес loopback: 10.0.0.1, этот адрес никогда не ответит на запросы Radius, потому что фактический ответ будет отправлен с адреса реального интерфейса. Представь, у тебя есть 3 входящих интерфейса с адресами 10.10.10.30/30, 10.174.0.1/24 и 172.31.1.16/24. Тебе нужно отслеживать, какой интерфейс фактически обслуживает запросы Radius, и указывать один из этих адресов на каждом Radius клиенте. В зависимости от топологии сети эти адреса, конечно, могут быть разными на разных сегментах. Так что, в двух словах: нужно указывать реальный IP-адрес любого интерфейса Radius Server, а не loopback.
     
     
     
    p00h
    Guest
    #6
    0
    29.01.2016 08:46:00
    Я бы не назвал это решением, но мне подошло, и теперь у меня таких проблем больше нет.
     
     
     
    ZeroByte
    Guest
    #7
    0
    29.01.2016 16:33:00
    Нашел похожую проблему с DHCP relay серверами. Если основной сервер был привязан к loopback-интерфейсу, он не отвечал на запросы, переданные через relay. Решением, которое я придумал, было создание DHCP-сервера для каждого возможного интерфейса, и настройка всех их на использование одного и того же IP-пула для лиз и, если я делал статические лизы, нужно было убедиться, что они могут быть использованы всеми серверами, а не только тем, на котором я нажал "сделать статический". Если у вас несколько DHCP relay, это может быстро выйти из-под контроля. Я бы рекомендовал использовать выделенный UserMan сервер с bridge интерфейсом в качестве IP-адреса сервера - и подключить два порта к двум разным роутерам, и настроить на них VRRP для обеспечения отказоустойчивости первого хопа – оба они могут рекламировать сеть сервера в OSPF, это обеспечит вам резервные каналы, но не потребует никаких изменений при изменении топологии сети. Другой способ — определить все адреса физических интерфейсов 10.0.0.1 как RADIUS серверы на клиентах и позволить им работать как "группа основных/резервных RADIUS серверов" на клиентах.
     
     
     
    p00h
    Guest
    #8
    0
    30.01.2016 09:54:00
    Даже в голову такое не приходило. Честно говоря, никогда не пробовал так делать. Возможно, сработает, спасибо за ценный совет!
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры