Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • 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
    Одно публичное обращение на локальной сети

    Одно публичное обращение на локальной сети

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Одно публичное обращение на локальной сети, RouterOS
     
    ik3umt
    Guest
    #1
    0
    18.09.2019 12:39:00
    Недоступен для перевода текст: A /29 public addresses subnet is available to one RB ethernet port. How can each single LAN subnet use a specific WAN IP address ?
     
     
     
    ik3umt
    Guest
    #2
    0
    26.11.2019 20:32:00
    Спасибо за пример. Это касается перенаправленных пакетов для Lan. А что если самому маршрутизатору нужно использовать другой WAN-адрес? Должен ли я использовать ip route для конкретной цели, выбирая WAN-адрес через поле "Pref.Source"?
     
     
     
    sindy
    Guest
    #3
    0
    26.11.2019 20:41:00
    Да, это один из возможных способов. Однако, боюсь (хотя и не уверен!), что pref-src маршрута должен быть одним из собственных адресов роутера (т.е. он должен быть назначен на каком-то из его интерфейсов), что не относится к правилу src-nat. Поэтому вместо /ip route add dst-address=x.x.x.x pref-src=y.y.y.y вам нужно использовать /ip firewall nat add chain=srcnat action=src-nat src-address-type=local dst-address=x.x.x.x to-addresses=y.y.y.y.
     
     
     
    ik3umt
    Guest
    #4
    0
    28.11.2019 07:40:00
    А как насчет существующего правила маскарада?
     
     
     
    sindy
    Guest
    #5
    0
    28.11.2019 08:04:00
    Я не понимаю вопрос. В своем посте #4 @nickshore предоставил вам правила src-nat, которые выбирают определенный публичный IP в зависимости от текущей исходной подсети. Я отвечал только на ваш другой вопрос, как выбрать определенный публичный адрес в качестве источника для соединений, инициированных самим маршрутизатором. У меня есть лишь одна проблема с этим предложением: place-before=1 может быть не самым подходящим способом указать их положение, так как эти правила src-nat могли быть размещены после правила masquerade, что сделает их невидимыми для masquerade и никогда не используемыми. Если у вас все правильно настроено без пробелов (то есть если каждая подсеть LAN покрыта одним правилом src-nat), вам вообще не нужно правило masquerade. Более того, как я уже говорил, если вы разместите его не в том месте (то есть перед всеми теми, что предложены мной и @nickshore), эти правила не увидят ни одного пакета, и волшебство, о котором вы спрашиваете, не сработает. Правило masquerade изначально предназначено для интерфейсов, адреса которых назначаются динамически; тот факт, что оно работает даже на интерфейсах с статически настроенным адресом, делает его хорошим выбором для конфигурации встроенного брандмауэра, основное назначение которого — работать сразу после установки в приложениях SOHO. Но как только вы выходите за эти рамки, вам нужно подумать о роли каждого правила в стандартном брандмауэре.
     
     
     
    ik3umt
    Guest
    #6
    0
    28.11.2019 08:37:00
    Хорошо, так что маскарадное правило можно считать глобальным и разместить в конце, где другие правила src-nat не срабатывают, так как маскарад не может указывать "to-addresses". Насколько я понял, если нужно использовать больше подсетей LAN, то только интересующие подсети могут совпадать с правилами src-nat, в то время как остальные могут проходить через следующее маскарадное правило. Это связано с пересылаемыми пакетами. Мой второй вопрос, на самом деле, другой и касается подключений, инициированных к самому маршрутизатору. Параметр ip route "pref-src" — это публичный IP, назначенный WAN-интерфейсу RB, так что не должно быть проблем с использованием метода /ip route. Как ты думаешь, лучше использовать src-nat с src-address-type=local?
     
     
     
    sindy
    Guest
    #7
    0
    28.11.2019 09:02:00
    Единственная причина - это та, которую я привел. Если бы у вас, например, было 29 публичных адресов, не было бы практично выводить все их на WAN-интерфейсе роутера. Это необходимо для использования этих адресов в качестве pref-src маршрута, но не требуется для использования в качестве to-адресов в правиле src-nat.
     
     
     
    ik3umt
    Guest
    #8
    0
    28.11.2019 21:31:00
    Я пробовал /ip firewall nat add chain=srcnat action=src-nat src-address-type=local dst-address=x.x.x.x to-addresses=y.y.y.y. Это не работает, если y.y.y.y не назначен на WAN роутера...
     
     
     
    sindy
    Guest
    #9
    0
    28.11.2019 21:37:00
    Боюсь, вам придется установить arp=proxy-arp на WAN-интерфейсе, если все публичные адреса принадлежат одной подсети, подключенной к WAN-интерфейсу. ИЗМЕНЕНИЕ: фактическая необходимая настройка — arp=local-proxy-arp — см. пост #15.
     
     
     
    ik3umt
    Guest
    #10
    0
    28.11.2019 22:37:00
    Мне нужно всего два IP-адреса из подсети /29 для моего WAN-интерфейса, поэтому я пойду по этому пути и продолжу использовать ваши правила src-nat без proxy-arp, это кажется более надежным по сравнению с маршрутом IP (который иногда работает, а иногда нет…). Спасибо.
     
     
     
    gotsprings
    Guest
    #11
    0
    30.11.2019 13:50:00
    Я не думаю, что мне когда-либо приходилось это делать.
     
     
     
    sindy
    Guest
    #12
    0
    01.12.2019 10:16:00
    Вы, вероятно, никогда этого не делали, потому что, скорее всего, не использовали адреса из вашего WAN-подсети, которые не были назначены никакому интерфейсу, в качестве адресов в правиле src-nat. Если вы используете адреса из любой другой подсети, которую ваш провайдер маршрутизирует к вам через ваш IP в WAN-подсети, нет необходимости настраивать маршрутизатор на ответ на ARP-запросы по этим адресам. И цитата Марка Твена в вашей автоматической подписи абсолютно права: правильная настройка arp, необходимая для того, чтобы маршрутизатор отвечал на ARP-запросы для адресов, используемых в качестве reply-dst-address отслеживаемых соединений, на самом деле - local-proxy-arp.
     
     
     
    gotsprings
    Guest
    #13
    0
    01.12.2019 12:27:00
    Если у меня есть /29 IP-адрес на WAN… я присваиваю их интерфейсу WAN. Указываю правильный шлюз в маршрутах. Затем использую списки адресов и src-nat, чтобы направлять разный трафик через разные IP. Я уверен, что по умолчанию для интерфейса установлено «включено arp». Я что-то упустил?
     
     
     
    sindy
    Guest
    #14
    0
    01.12.2019 13:23:00
    Выше приведена разница, о которой я говорю. Вы назначаете их для интерфейса WAN, поэтому система отвечает на ARP-запросы относительно этих адресов, так как они принадлежат ей. Я не назначаю их для интерфейса WAN, поэтому мне нужно установить arp в local-proxy-arp, чтобы система начала проверять reply-dst-addresses в соединительном трекере при обработке входящего ARP-запроса.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры