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

    ROS Hairpin NAT - сохранение исходного IP для целей логирования

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    ROS Hairpin NAT - сохранение исходного IP для целей логирования, RouterOS
     
    wolfram
    Guest
    #1
    0
    19.03.2019 21:05:00
    Просто скажи, что это невозможно из-за дизайна, но, возможно, здесь есть какое-то решение… 1. У меня есть hairpin NAT для LAN-подключений на локальном мосту - всё функционирует, без проблем. 2. Если кто-то из LAN подключается к другому LAN-устройству (серверу) с публичным IP - всё работает, но в логах сервера отображается IP локального моста (да, это нормальное поведение). 3. Вопрос в следующем: Можно ли как-то ЗАСТАВИТЬ сервер сохранять оригинальный IP источника? Пожалуйста, мне просто нужно зафиксировать реальный IP источника на сервере, есть ли какие-то волшебные настройки mangle, post или pre routing?
     
     
     
    DRSDavidSoft
    Guest
    #2
    0
    09.07.2020 00:00:00
    Мне жаль поднимать эту старую тему – просто хотел сказать, как я ценю это решение! Я искал способ решить эту конкретную проблему, но не смог, и мне не приходило в голову, что netmap можно использовать таким образом. На стороне сервера мне просто нужно будет быстро заменить строку, и теперь я смогу получить исходящий IP. Это действительно волшебное решение!
     
     
     
    robsgax
    Guest
    #3
    0
    09.07.2020 06:06:00
    Я пытался это сделать, но не получается. Мое текущее правило hairpin такое же, как первое здесь, и я изменил его, чтобы оно выглядело как второе. Из-за этого я не могу получить доступ к своему локальному веб-серверу из локальной сети (используя свой публичный IP или URL). Что еще я могу проверить?
     
     
     
    Sob
    Guest
    #4
    0
    09.07.2020 20:58:00
    Маршрут к виртуальным адресам (10.168.88.0/24 или какой бы вы ни использовали) на сервере должен указывать на роутер, на котором вы это и делаете. Вам не нужно ничего добавлять, это охватывается маршрутом по умолчанию, если он указывает на этот роутер. В общем, проблема возникнет только в том случае, если сервер имеет маршрут к этой подсети, направленный куда-то еще. Если это не так, то, вероятно, это просто небольшая ошибка, опечатка... Как всегда, полезно наблюдать за происходящим, шаг за шагом выяснять, где возникает сбой. Dstnat в порядке, вы это не изменяли. Srcnat для hairpin, если вы не делали других модификаций, по сути остается тем же. Но вы можете проверить (с помощью Tools->Torch или логирования правил в postrouting), что вы видите пакеты от 10.168.88.x, идущие на сервер, если сервер их видит, принимает соединения, отправляет что-либо обратно и так далее.
     
     
     
    robsgax
    Guest
    #5
    0
    10.07.2020 00:31:00
    Я не понимаю, нужно ли что-то устанавливать на мой веб-сервер или только на правило hairpin? Как всегда, полезно наблюдать, что происходит, шаг за шагом выяснять, где происходит сбой. Dstnat в порядке, ты это не изменял. Srcnat для hairpin, если ты не делал других изменений, почти такой же. Но ты можешь проверить (используя Инструменты->Torch или журналы правил в postrouting), что пакеты от 10.168.88.x идут к серверу, если сервер их видит, принимает соединения, отправляет что-то обратно и так далее. Я проверял с логом, и оба лога для меня одинаковы, вот один с действием masquerade (работающий) masq: srcnat: in:(unknown 0) out:bridgeLAN, src-mac 04:d4:c4:53:46:52, proto TCP (SYN), 192.168.0.30:25310->192.168.0.15:80, NAT 192.168.0.30:25310->(201.171.144.99:80->192.168.0.15:80), len 52 и вот один с действием netmap netmap: srcnat: in:(unknown 0) out:bridgeLAN, src-mac 04:d4:c4:53:46:52, proto TCP (SYN), 192.168.0.30:25308->192.168.0.15:80, NAT 192.168.0.30:25308->(201.171.144.99:80->192.168.0.15:80), len 52 вот мои правила NAT, я отключил одно правило hairpin и включил другое для теста, может я забыл сказать, что у меня два WAN, один кабельный и один DSL, кабельный WAN находится за NAT, поэтому порты закрыты, я использую DSL как шлюз для своих серверов, снаружи все работает нормально, и с первым правилом hairpin, изнутри мой сервер доступен по публичному IP-адресу DSL. /ip firewall nat add action=masquerade chain=srcnat comment="Hairpin NAT Masq" dst-address=192.168.0.0/24 log=yes log-prefix="masq: " src-address=192.168.0.0/24 add action=netmap chain=srcnat comment="Hairpin NAT Masq" disabled=yes dst-address=192.168.0.0/24 log=yes log-prefix="netmap: " src-address=192.168.0.0/24 to-addresses=10.168.0.0/24 add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=ether1-WAN1 add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=pppoe-Telnor add action=dst-nat chain=dstnat dst-address-list=WAN2-ADDR dst-address-type="" dst-port=80 protocol=tcp to-addresses=192.168.0.15 to-ports=80
     
     
     
    Sob
    Guest
    #6
    0
    10.07.2020 00:53:00
    Скорее всего, вам ничего не нужно делать с сервером. Проблема, о которой я упоминал, возникла бы только если, например, у вас уже был бы назначен 10.168.0.0/24 на другой интерфейс сервера, или если он использовался где-то еще, и сервер имел бы маршрут к нему через другой маршрутизатор, а не этот. Одно из вещей, которое могло бы повлиять на это на сервере, — его фаервол, если он блокировал пакеты из 10.168.0.0/24. Но маловероятно, что у вас есть сервис, доступный из интернета, и по какой-то причине блокирующий доступ из некоторых частных подсетей. Так как вы упомянули два WAN, есть ли что-то интересное в “/ip firewall mangle”, например, маркировка маршрутизации для некоторых пакетов? Или какие-то правила в “/ip route rule”? Если да, то вам нужно исключить пакеты от сервера к 10.168.0.0/24 из этого.
     
     
     
    robsgax
    Guest
    #7
    0
    10.07.2020 01:11:00
    Я использую некоторые правила для управления трафиком на мой второй WAN, нужно всего лишь внести IP-адрес в список, и они будут перенаправлены на второй WAN. Вот мои правила маршрутизации и манипуляции с трафиком:

    /ip route  
    add check-gateway=ping distance=1 gateway=pppoe-Telnor routing-mark=TelnorWAN  
    add check-gateway=ping distance=2 gateway=8.8.4.4  

    /ip firewall mangle  
    add action=accept chain=prerouting comment="Telnor метод 2" dst-address-list=WAN2-ADDR in-interface=bridgeLAN  
    add action=mark-connection chain=prerouting connection-mark=no-mark in-interface=pppoe-Telnor new-connection-mark=Telnor_Conn passthrough=yes  
    add action=mark-connection chain=prerouting connection-mark=no-mark dst-address-type=!local in-interface=bridgeLAN new-connection-mark=Telnor_Conn passthrough=yes src-address-list=TelnorList  
    add action=mark-routing chain=prerouting connection-mark=Telnor_Conn dst-address-type="" in-interface=bridgeLAN new-routing-mark=TelnorWAN passthrough=yes src-address-list=TelnorList  
    add action=mark-routing chain=output connection-mark=Telnor_Conn new-routing-mark=TelnorWAN passthrough=yes src-address-list=TelnorList
     
     
     
    Sob
    Guest
    #8
    0
    10.07.2020 01:33:00
    Я не уверен, какой WAN какой, и является ли сервер частью списка, но это должно сработать (до других правил): /ip firewall mangle add action=accept chain=prerouting dst-address=10.168.0.0/24 in-interface=bridgeLAN
     
     
     
    robsgax
    Guest
    #9
    0
    10.07.2020 02:01:00
    Спасибо, это сработало!!
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры