Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • 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
    IP Брандмауэр Nat

    IP Брандмауэр Nat

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    IP Брандмауэр Nat, RouterOS
     
    tiran
    Guest
    #1
    0
    27.12.2018 07:27:00
    Мне нужно фильтровать dst-nat по MAC-адресу устройства. Мой NAT выглядит так: chain=dstnat action=dst-nat to-addresses=192.168.x.x to-ports=4000 protocol=tcp in-interface-list=WAN dst-port=8055 log=no log-prefix=“”.

    Мне нужно настроить доступ или перенаправление хоста на этот dst-nat только по разрешённым MAC-адресам. Все остальные хосты должны быть заблокированы, даже если у них правильный URL. Кто-нибудь может помочь?
     
     
     
    tiran
    Guest
    #2
    0
    01.12.2020 11:31:00
    Есть ли другие способы ограничить доступ к NAT для разрешённых пользователей? MAC-адрес источника не совпадает с MAC-адресом клиентского устройства, если устройство подключается через интернет. Мне кажется, было бы лучше, если бы был способ доступа к NAT через сертификат или ключ.
     
     
     
    sindy
    Guest
    #3
    0
    01.12.2020 12:14:00
    Как вы сами поняли, MAC-адреса используются только в локальной сети, поэтому роутер не видит их в заголовке пакета, который приходит из удалённой сети. NAT работает на уровне L3 (IP) и L4 (например, TCP), а сертификаты и ключи применяются на более высоких уровнях.

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

    На данный момент IKEv2 — лучший вариант для Windows, но для старых версий Android нужно устанавливать VPN-приложение (например, Strongswan). С устройствами Apple правильно заполнить поля сертификатов может быть сложно.

    L2TP/IPsec, как кажется, работает на всех популярных системах, но использует только общий ключ для аутентификации, а не сертификаты.
     
     
     
    tiran
    Guest
    #4
    0
    27.01.2021 06:57:00
    Есть у кого-нибудь другой вариант, чтобы решить мою задачу? На самом деле мне нужно управлять внешними устройствами, которые подключаются к моему серверу. Срочно…
     
     
     
    16again
    Guest
    #5
    0
    27.01.2021 10:27:00
    Так как исходный MAC-адрес использовать нельзя, берите альтернативы, которые работают. Например, исходный IP-адрес. Если он динамический — используйте порт-стук или подключайтесь через VPN.
     
     
     
    tiran
    Guest
    #6
    0
    29.01.2021 08:56:00
    Я думаю о чем-то вроде сертификата устройства, у тебя есть какие-нибудь идеи?
     
     
     
    anav
    Guest
    #7
    0
    29.01.2021 13:10:00
    В чём заключается задача, которая точнее всего описывает требование вместо навязанного способа решения? Какова ситуация и что вы хотите, чтобы пользователи могли или не могли делать, описывая это словами и не упоминая конфигурацию вовсе?
     
     
     
    tiran
    Guest
    #8
    0
    21.05.2021 06:44:00
    Например, у меня роутер с публичным IP = 124.10.20.201, LAN IP = 192.168.10.1, сервер с IP = 192.168.10.100:4000. Мое правило NAT: “action=dst-nat chain=dstnat comment=“WAN login” dst-port=8585 in-interface-list=WAN protocol=tcp src-address-type="" to-addresses=192.168.10.100 to-ports=4000”.

    Так что локальный адрес веб-интерфейса сервера — http://192.168.10.100:4000/, а удалённый — http://124.10.20.201:8585/.

    Проблема в том, что любой, кто знает удалённый адрес моего веб-интерфейса, может к нему подключиться. Мне нужно ограничить доступ из WAN, например, чтобы только менеджеры и бухгалтеры могли заходить на веб-интерфейс по удалённому адресу (менеджеры используют Android-устройства), остальные — нет.
     
     
     
    rextended
    Guest
    #9
    0
    21.05.2021 07:58:00
    Проще говоря: НЕЛЬЗЯ. ТОЧКА. Поменять идею. В WAN вы видите только MAC-адрес устройства, к которому подключено ваше устройство, то есть вашего провайдера.
     
     
     
    anav
    Guest
    #10
    0
    21.05.2021 10:56:00
    tiran. Никогда не стоит делать сервер, доступный из интернета, без ввода имени пользователя и пароля, при этом используя SFTP, HTTPS или другое зашифрованное соединение. Ни одна нормальная программа для такой задачи не работает в «открытом виде». Возможно, придется настроить аутентификацию через Radius-сервер или использовать другой способ проверки пользователей.

    Шаг 2. При ограничении доступа лучше всего использовать список адресов в брандмауэре и указывать этот список как источник в правиле DST NAT. Это не панацея, но заметно снижает риски. Чтобы это работало, нужно знать публичные IP тех пользователей. Если у них динамические адреса, посоветуйте им получить бесплатное имя через dyndns, а в брандмауэре использовать их доменные имена — тогда роутер сам будет сопоставлять их с актуальными IP.

    Почему все, кроме тех, кто действительно должен иметь доступ, знают ваш веб-адрес? Неужели вы имели в виду доменное имя, вроде dyndns? Поменяйте его и не раздавайте посторонним. Если это доступ для одного-двух человек, подумайте о VPN-туннеле — так они смогут безопасно заходить в вашу локальную сеть (без DST NAT) и работать с сервером внутри LAN.
     
     
     
    rextended
    Guest
    #11
    0
    21.05.2021 11:58:00
    Эм… чтобы было ясно :)))  
    Никогда не должен быть публичный сервер без входа с именем пользователя и паролем, и чтобы это было через SFTP или HTTPS и прочее с шифрованием <<< +100
     
     
     
    tiran
    Guest
    #12
    0
    29.05.2021 03:35:00
    На самом деле я уже использую домен для доступа по URL и настроил, разрешив нескольким пользователям заходить в систему через домен. Но эти пользователи не хранят данные в тайне. Наш менеджер подозревает, что они будут делиться секретной информацией, поэтому я пытаюсь что-то предпринять. По сути, мне нужно решение, которое будет блокировать устройства, не авторизованные для доступа к системе, даже если кто-то знает URL и данные для входа.

    Судя по обсуждениям и другим документам, единственный способ сделать это — создать VPN-соединение. Но у меня есть ещё одна проблема: если клиентское устройство использует интернет, то весь трафик пойдёт через VPN. Хотя, возможно, мы сможем с этим справиться. Есть какие-то идеи?
     
     
     
    anav
    Guest
    #13
    0
    29.05.2021 10:44:00
    Вам нужен дополнительный шаг для авторизации пользователей, прежде чем им разрешат доступ к серверу, например, проверка через radius-сервер. Можно сначала использовать портал гостевой сети. Если кто-то будет пользоваться сервером без разрешения, его заблокируют и не позволят использовать дальше (то есть, он слил учетные данные).
     
     
     
    sindy
    Guest
    #14
    0
    29.05.2021 12:21:00
    Невозможно заранее предотвратить вход третьих лиц с использованием учётных данных, полученных от уполномоченного пользователя, как с его согласия, так и без него. Вы можете заблокировать аккаунт после обнаружения факта, но обычно к тому моменту уже поздно. В некоторой степени двухфакторная аутентификация помогает, ведь люди обычно не дают свой мобильный телефон друзьям, но это всё равно не даёт 100% гарантии — уполномоченный пользователь может сознательно разрешить доступ другим. Клиентские сертификаты могут предотвратить намеренную передачу аккаунта, но только если они созданы правильно и не могут быть экспортированы на стороне клиента. Поэтому аппаратные токены («смарт-карты») с неэкспортируемыми сертификатами — единственный надёжный вариант (на одних ОС сертификаты можно легко экспортировать, на других — это требует серьёзных усилий, но наперёд вы не знаете, какими ОС пользуются ваши клиенты). Однако даже аппаратный токен можно украсть и использовать для входа третьим лицам, если при этом не применяется двухфакторная аутентификация или вторая ступень не была украдена. Аппаратные токены, для использования которых нужно вводить пароль, кажутся более надёжными и против намеренной передачи, и против кражи, но не защищают от пыток или шантажа уполномоченного пользователя.

    При попытке определить, является ли конкретный доступ «законным» или нет, полагаться ни на что нельзя — несколько уполномоченных пользователей могут заходить с одного публичного IP-адреса из-за CarrierGradeNAT, поэтому проверить IP не получится; люди могут заходить с мобильного телефона, и одно устройство способно одновременно устанавливать две сессии — через Wi-Fi и мобильную сеть. Нельзя привязать аккаунт к фиксированному IP, чтобы выявить совместное использование данных или кражу. Можно ограничить число одновременных подключений с одними учётными данными, но точно не одним, по указанным причинам. И всё равно можно ждать проблем при сбоях, когда клиент создаст новую сессию, а сервер ещё признает активными предыдущие.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры