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

    Простая задача маршрутизации.

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Простая задача маршрутизации., RouterOS
     
    ipdruide
    Guest
    #1
    0
    21.09.2006 13:03:00
    Всем привет!

    Занимаюсь этой проблемой уже пару недель, хотя задача кажется довольно простой. Опять всё связано с несколькими шлюзами. У меня Routerboard 2.9.30 с 2 DSL-линиями и фиксированными IP-адресами. Есть маршрутизация с метками для ответа на входящий трафик через нужный шлюз, и всё это работает отлично. Кроме того, есть шлюз по умолчанию для всей остальной, не помеченной, и трафика самого роутера. Моя проблема в том, что сервисы роутера (telnet, ftp, ssh…) доступны только с WAN-линии, которая является шлюзом по умолчанию. Конечно, я не могу добавить ещё один шлюз по умолчанию для второй линии, и RouterOS, похоже, на запросы SSH с обеих внешних линий отвечает через один и тот же шлюз. В общем: как заставить роутер отвечать на эти запросы через ту линию, с которой они пришли?

    Вот мои настройки: я использую masquerade для локальных пользователей и dst-nat для локального сервера, чтобы он был доступен из интернета.

    add dst-address=0.0.0.0/0 gateway=111.111.111.111 distance=0 scope=255 target-scope=10 routing-mark=even comment=“” disabled=no
    add dst-address=0.0.0.0/0 gateway=222.222.222.222 distance=0 scope=255 target-scope=10 routing-mark=odd comment=“” disabled=no
    add dst-address=0.0.0.0/0 gateway=111.111.111.111 distance=0 scope=255 target-scope=10 routing-mark=fragile comment=“No load balancing for fragile web sites” disabled=no
    add dst-address=0.0.0.0/0 gateway=111.111.111.111 check-gateway=ping distance=0 scope=255 target-scope=10 routing-mark=rout_B comment=“Inbound trafic response via B” disabled=no
    add dst-address=0.0.0.0/0 gateway=111.111.111.111 distance=0 scope=255 target-scope=10 comment=“router own path” disabled=no
    add dst-address=0.0.0.0/0 gateway=222.222.222.222 check-gateway=ping distance=0 scope=255 target-scope=10 routing-mark=rout_A comment=“Inbound trafic response via A” disabled=no

    Может быть, там какая-то очень глупая настройка, которую я не замечаю, или это просто невозможно сделать. Спасибо за любые предложения!
     
     
     
    ipdruide
    Guest
    #2
    0
    25.09.2006 14:13:00
    Вот они:
    /ip route print detail
    Flags: X - отключен, A - активен, D - динамический, C - подключен, S - статический, r - rip, b - bgp, o - ospf, B - черная дыра, U - недостижим, P - запрещен
    0 A S
    dst-address=0.0.0.0/0 gateway=193.253.160.3 interface=pppoe-isp2 gateway-state=reachable distance=0 scope=255 target-scope=10 routing-mark=even
    1 A S
    dst-address=0.0.0.0/0 gateway=212.129.9.84 interface=pppoe-isp1 gateway-state=reachable distance=0 scope=255 target-scope=10 routing-mark=odd
    2 A S
    ;;; Нет балансировки нагрузки для хрупких веб-сайтов
    dst-address=0.0.0.0/0 gateway=193.253.160.3 interface=pppoe-isp2 gateway-state=reachable distance=0 scope=255 target-scope=10 routing-mark=fragile
    3 A S
    ;;; Входящий трафик ответа через isp2
    dst-address=0.0.0.0/0 gateway=193.253.160.3 check-gateway=ping interface=pppoe-isp2 gateway-state=reachable distance=0 scope=255 target-scope=10 routing-mark=rout_isp2
    4 A S
    ;;; основной маршрут
    dst-address=0.0.0.0/0 gateway=193.253.160.3 interface=pppoe-isp2 gateway-state=reachable distance=0 scope=255 target-scope=10
    5 A S
    ;;; Входящий трафик ответа через isp1
    dst-address=0.0.0.0/0 gateway=212.129.9.84 check-gateway=ping interface=pppoe-isp1 gateway-state=reachable distance=0 scope=255 target-scope=10 routing-mark=rout_isp1
    6 ADC
    dst-address=172.16.0.0/24 pref-src=172.16.0.101 interface=ether1 distance=0 scope=10 target-scope=0
    7 ADC
    dst-address=172.16.1.0/24 pref-src=172.16.1.101 interface=wlan1 distance=0 scope=200 target-scope=0
    8 ADC
    dst-address=193.253.160.3/32 pref-src=193.252.209.222 interface=pppoe-isp2 distance=0 scope=10 target-scope=0
    9 ADC
    dst-address=212.129.9.84/32 pref-src=62.210.110.170 interface=pppoe-isp1 distance=0 scope=10 target-scope=0

    /ip firewall mangle>
    /ip firewall mangle> pr
    Flags: X - отключен, I - недействителен, D - динамический
    0
    chain=forward protocol=tcp tcp-flags=syn action=change-mss new-mss=1360
    1
    chain=forward protocol=tcp tcp-flags=syn action=passthrough
    2
    ;;; Mangle хрупкий веб-сайт НЕТ балансировки нагрузки
    chain=prerouting in-interface=ether1 connection-state=new dst-address-list=fragile action=mark-connection new-connection-mark=fragile passthrough=yes
    3
    chain=prerouting in-interface=ether1 connection-mark=fragile action=mark-routing new-routing-mark=fragile passthrough=no
    4
    ;;; Mangle для балансировки нагрузки четное нечетное
    chain=prerouting in-interface=ether1 connection-state=new nth=1,1,0 action=mark-connection new-connection-mark=odd passthrough=yes
    5
    chain=prerouting in-interface=ether1 connection-mark=odd action=mark-routing new-routing-mark=odd passthrough=no
    6
    chain=prerouting in-interface=ether1 connection-state=new nth=1,1,1 action=mark-connection new-connection-mark=even passthrough=yes
    7
    chain=prerouting in-interface=ether1 connection-mark=even action=mark-routing new-routing-mark=even passthrough=no
    8
    ;;; Mangle для входящего трафика isp1
    chain=prerouting in-interface=pppoe-isp1 connection-state=new action=mark-connection new-connection-mark=con_isp1 passthrough=yes
    9
    chain=prerouting in-interface=ether1 connection-mark=con_isp1 action=mark-routing new-routing-mark=rout_isp1 passthrough=no
    10
    ;;; Mangle для входящего трафика isp2
    chain=prerouting in-interface=pppoe-isp2 connection-state=new action=mark-connection new-connection-mark=con_isp2 passthrough=yes
    11
    chain=prerouting in-interface=ether1 connection-mark=con_isp2 action=mark-routing new-routing-mark=rout_isp2 passthrough=no
     
     
     
    ipdruide
    Guest
    #3
    0
    26.09.2006 07:36:00
    Если позволите добавить моё мнение: я не понимаю, почему роутер должен отвечать на запросы, адресованные одному из его WAN-линков, с другого линка. Другими словами, маршруты, предназначенные для прокладки путей из LAN во внешний мир, не должны применяться к сервисам, которые прослушивают на стороне WAN. Разве это не очевидная ошибка? С уважением.
     
     
     
    ipdruide
    Guest
    #4
    0
    26.09.2006 08:28:00
    Также IPSEC-туннели (я не пробовал с L2TP или PPTP) перестают работать, если шлюз по умолчанию — это не тот, что связан с IP-адресом партнера. Вся эта проблема в одном: как только появляется больше одной интернет-связи, внутренние службы роутера начинают отвечать через шлюз по умолчанию. Спасибо за любые комментарии.
     
     
     
    Eugene
    Guest
    #5
    0
    26.09.2006 09:13:00
    Роутер не имеет "предпочтений". Если у него нет конкретного маршрута до нужного места, он ответит через шлюз по умолчанию.
     
     
     
    ipdruide
    Guest
    #6
    0
    26.09.2006 10:04:00
    Юджин, ты имеешь в виду, что нет способа получить доступ к сервисам роутера с разных публичных IP? Еще IPSEC (и, возможно, другие L2TP, PPTP) туннели не будут работать, если есть больше одного пира, ИЛИ если для туннелей используются 2 или больше разных WAN-соединений? Пожалуйста, подтверди. Спасибо.
     
     
     
    ipdruide
    Guest
    #7
    0
    26.09.2006 12:54:00
    Юджин написал: Роутер не имеет "предпочтений". Если у него нет конкретного маршрута до пункта назначения, он ответит через шлюз по умолчанию. Я не вижу реальной причины. Я считаю, что во многих ситуациях было бы лучше, если бы локальные сервисы отвечали по соответствующему пути вместо использования "соседнего". Может ли кто-нибудь подтвердить, прав я или нет, и, возможно, подсказать, что по этому поводу говорят RFC? Если я не прав, может быть, есть обходной путь? Спасибо за любые комментарии.
     
     
     
    Eugene
    Guest
    #8
    0
    26.09.2006 13:42:00
    Начнём заново. Допустим, вы подключаетесь к роутеру (IP 2.0.0.1, 3.0.0.1) с компьютера (IP 1.0.0.1) через Интернет. У роутера есть две линии связи, одна подключена к IP 2.0.0.2, а другая — к 3.0.0.2. Маршрут по умолчанию указывает на 2.0.0.2. Теперь, если у роутера нет конкретного маршрута, который указывает роутеру, куда отправлять трафик, предназначенный для 1.0.0.1, то роутер всегда будет отвечать через маршрут по умолчанию. Вы можете изменить это поведение, добавив маршрут к 1.0.0.0/24, указав 3.0.0.2 в качестве шлюза: /ip route add dst-address=1.0.0.0/24 gateway=3.0.0.2
     
     
     
    ipdruide
    Guest
    #9
    0
    26.09.2006 17:41:00
    Прошу прощения, но это довольно неудобное решение, потому что мне приходится создавать запись в таблице маршрутизации для каждого отдельного адреса назначения. Что серьёзно ограничивает доступность роутера. Цель использования двухканального соединения больше связана с обеспечением доступности, чем с увеличением пропускной способности, как вы можете себе представить. Покупка двух аккаунтов у провайдера становится бесполезной. Не может ли быть так, что роутер неправильно выбирает путь при ответах на внешние запросы по каналам WAN? Если это неправильное поведение, то MT должны это исправить. В своём предыдущем сообщении я искал доказательство соответствия RFC. Кстати, я использую пакет routing-test. Я попробовал протестировать маршрутизацию, но поведение не изменилось. Может, вы можете придумать какой-нибудь другой workaround на время? С уважением.
     
     
     
    Eugene
    Guest
    #10
    0
    26.09.2006 17:46:00
    Это не обходной путь. Это просто то, как работает маршрутизация, независимо от производителя устройства. Таблица маршрутизации содержит инструкции для роутера о том, как отправлять пакет для конкретного адреса назначения, и роутер подчиняется этим правилам. Если ему сказано пройти через один шлюз, он не пойдет через другой. Но вы можете добавить второй маршрут по умолчанию с другим шлюзом, который станет активным, если основной шлюз выйдет из строя. (Для этого нужно настроить параметр "check-gateway") Eugene
     
     
     
    changeip
    Guest
    #11
    0
    26.09.2006 17:51:00
    Маршрутизатор делает то, что ему говорят, строго используя таблицу маршрутизации. Вам нужно использовать packet mark / connection mark, исходя из интерфейса, на котором пакет пришел. Затем, в цепочках prerouting / output, вы должны сможете маршрутизировать с меткой, чтобы ответ приходил через правильную таблицу маршрутизации. Мне кажется, что определенные вещи, например, ICMP, нельзя маршрутизировать с меткой, но те, что попадают в таблицу отслеживания соединений, должны быть доступны для этого. Просто отмечайте их при входящем трафике, а затем заставляйте их использовать нужную метку маршрута на выходе. Возможно, вам также понадобится добавить маршруты в таблицы rout_isp1&2 для их собственных подсетей, иначе они упадут в основную таблицу.
     
     
     
    ipdruide
    Guest
    #12
    0
    27.09.2006 10:25:00
    Спасибо и признательность Eugene и Sam за помощь и подсказки. Получилось! Ранее я пытался настроить соединения/маршруты, основываясь на маршрутных метках, но использовал только "prerouting" цепочку, потому что (честно говоря) не до конца понимал разницу между prerouting и цепочками input/output. Недостаток обучения! Теперь я использую цепочку input для mark-connection mark и цепочку output для mark-routing правил, чтобы разделить трафик самомаршрутизатора и перенаправленный трафик (на другие хосты в локальной сети). Отныне я думаю использовать ssh, ftp, http, winbox для удаленного администрирования MT box, независимо от ISP-соединения или публичного IP, который я буду использовать. Кстати, собираюсь попробовать настроить двойной IPSEC-туннель благодаря этому результату. Кстати, возможны ли IPSEC-резервные туннели? Объединяемые? Спасибо еще раз за достигнутого прогресса.
     
     
     
    Eugene
    Guest
    #13
    0
    27.09.2006 13:24:00
    IPsec туннели не удалось объединить, потому что они уровня 3. Однако можно использовать маршрутизацию для переключения между ними. Eugene
     
     
     
    ipdruide
    Guest
    #14
    0
    27.09.2006 15:29:00
    Я, кажется, что-то упустил. Но прежде чем начинать заниматься ерундой, я считал, что можно строить EoIP поверх IPSEC-туннелей. EoIP — это интерфейс, похожий на Ethernet, таким образом, его можно объединять. Тогда, если у меня есть 2 офиса с 2 провайдерами каждый, я мог бы объединять EoIP-туннели для отказоустойчивости и повышения пропускной способности. Простите, я тут немного смешиваю несвязанные вещи. Я все еще в процессе освоения основ. Еще раз спасибо.
     
     
     
    Eugene
    Guest
    #15
    0
    27.09.2006 17:34:00
    Если тебе нужна связь Layer 2 между двумя офисами, тогда выбранная тобой схема – хороший вариант. Но если Layer 2 не обязательна, я бы выбрал маршрутизацию через 2 IPsec туннеля.
     
     
     
    ipdruide
    Guest
    #16
    0
    22.09.2006 08:38:00
    Прошу прощения, что настаиваю. Возможно, это просто настройка в моей маршрутизации, но мне нужна помощь эксперта. Я знаю, что в этом форуме таких хватает. Большое спасибо.
     
     
     
    Eugene
    Guest
    #17
    0
    22.09.2006 10:36:00
    Выложи полный список маршрутов и IP-адресов на роутере. Укажи, к какому адресу ты пытаешься подключиться.
     
     
     
    ipdruide
    Guest
    #18
    0
    25.09.2006 10:47:00
    Евгений, спасибо за ответ. Я пытаюсь подключиться из интернета к сервисам роутера (ssh, ftp и т.д.) по обоим публичным адресам: isp1 и isp2. До сих пор я мог подключиться только к адресу, связанному с основным маршрутом (**выделено полужирным шрифтом**).

    Публичные адреса:
    *   6 D 195.154.30.132/32
    *   212.129.9.84
    *   0.0.0.0
    *   pppoe-isp1
    *   7 D 193.252.209.222/32
    *   193.253.160.3
    *   0.0.0.0
    *   pppoe-isp2

    Спасибо за помощь еще раз.

    Маршруты:
    Флаги: X - отключен, A - активен, D - динамический, C - подключение, S - статический, r - rip, b - bgp, o - ospf, B - черная дыра, U - недоступен, P - запрещен.

    DST-ADDRESS        PREF-SRC        G GATEWAY         DIS INTERFACE
    0 A S  0.0.0.0/0                          r 193.253.160.3   0   pppoe-isp2
    1 A S  0.0.0.0/0                          r 212.129.9.84    0   pppoe-isp1
    2 A S  ;;; Нет балансировки нагрузки для хрупких веб-сайтов 0.0.0.0/0                          r 193.253.160.3   0   pppoe-isp2
    3 A S  ;;; Входящий трафик ответа через isp2 0.0.0.0/0                          r 193.253.160.3   0   pppoe-isp2
    4 A S  ;;; основной маршрут 0.0.0.0/0                          r 193.253.160.3   0   pppoe-isp2
    5 A S  ;;; Входящий трафик ответа через isp1 0.0.0.0/0                          r 212.129.9.84    0   pppoe-isp1
    6 ADC  172.16.0.0/24      172.16.0.101                      0   ether1
    7 ADC  172.16.1.0/24      172.16.1.101                      0   wlan1
    8 ADC  193.253.160.3/32   193.252.209.222                   0   pppoe-isp2
    9 ADC  212.129.9.84/32    62.210.110.170                    0   pppoe-isp1

    Адреса:
    Флаги: X - отключен, I - недействителен, D - динамический.

    ADDRESS            NETWORK         BROADCAST       INTERFACE
    0   172.16.0.101/24    172.16.0.0      172.16.0.255    ether1
    1   172.16.1.101/24    172.16.1.0      172.16.1.255    wlan1
    2   62.210.110.170/32  212.129.9.84    212.129.9.84    pppoe-isp1
    3   62.210.110.169/32  212.129.9.84    212.129.9.84    pppoe-isp1
    4   ;;; 168 Выделен для tarpit 62.210.110.168/32  212.129.9.84    212.129.9.84    pppoe-isp1
    5   62.210.110.171/32  212.129.9.84    212.129.9.84    pppoe-isp1
    6 D 195.154.30.132/32  212.129.9.84    0.0.0.0         pppoe-isp1
    7 D 193.252.209.222/32 193.253.160.3   0.0.0.0         pppoe-isp2
     
     
     
    Eugene
    Guest
    #19
    0
    25.09.2006 11:15:00
    Пожалуйста, опубликуйте: /ip route print detail /ip firewall manage print
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры