Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » В помощь системному администратору » MikroTik RouterOS (часть 3)

Модерирует : lynx, Crash_Master, dg, emx, ShriEkeR

ShriEkeR (05-01-2012 00:59):  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147

   

ShriEkeR



Moderator
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
 
 
MikroTik RouterOS (часть 1), MikroTik RouterOS (часть 2)
Официальный сайт: http://www.mikrotik.com
 
Данная тема создана для обмена информацией по вопросам и проблемам настройки MikroTik RouterOS
Тема в варезнике
 
 
последняя устаревшая версия: 4.17
последняя стабильная версия: 5.11

 
 
 
Официальная документация:
  • http://wiki.mikrotik.com/wiki/Category:Manual
  • для версии 3 http://www.mikrotik.com/testdocs/ros/3.0/
  • для версии 2.9 http://www.mikrotik.com/docs/ros/2.9/
  • RouterOS Packet Flow: http://wiki.mikrotik.com/wiki/Packet_Flow (важно знать для понимания сути происходящего в файрволе и шейпере)
     
    Обмен опытом пользователей MikroTik RouterOS: http://wiki.mikrotik.com/wiki/Main_Page
     
    Настройка подключения L2TP IPSec VPN между Windows 7 и Микротиком
    Дополнение к настройке L2TP IPsec
     
    Обсуждение ROS:
    Раздел форума PCRouter, посвященный MikroTik RouterOS
    Раздел форума DriverMania. Много полезного.
     
    Статьи:
    Перевод официального документа о QoS, очередях и шейпере.
    Краткий FAQ по настройке (первоисточник).
    Объединяем офисы с помощью Mikrotik
    Делим Интернет или QoS на Mikrotik (первоисточник).
    Установка и настройка ABillS + Mikrotik на Gentoo Linux.  
    Mikrotik-Qos Приоритезация по типу трафика и деление скорости

  • Всего записей: 6382 | Зарегистр. 27-09-2004 | Отправлено: 21:25 23-08-2010 | Исправлено: Chupaka, 14:25 19-12-2011
    rosalin



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

    Цитата:
    rosalin, с 0:9 до 0:9:25 (т.е. на 25 секунд в 9 минут первого) во все дни недели доступ к 80 порту микротика (т.е. http://адрес_микротика):  
       
      /ip firewall filter>  
     chain=input action=accept protocol=tcp dst-port=80 time=9m-9m25s,sun,mon,tue,wed,thu,fri,sat

     
     
    Это не то

    Всего записей: 2594 | Зарегистр. 15-04-2003 | Отправлено: 21:45 07-11-2011
    BigElectricCat

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    rosalin
    оо… точно, протупил. замаяли сегодня(((

    Всего записей: 1401 | Зарегистр. 20-12-2006 | Отправлено: 22:26 07-11-2011
    sumyst



    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    BigElectricCat
    Все дело в том, что я так и делал, начал со сложной схемы с ОСПФ, ВПН итд, думая что все просто.
     
    Оказался затык в правиле мангл.
    Теперь я схему упросил до минимума.
    В качестве прокси сейчас стоит freebsd со включенным роутингом между интерфейсами.
    Сниффером я вижу что пакеты с клиента тестБ до 8.8.8.8 приходят на ЛАН интерфейс и уходят через ВАН интерфейс. Тоесть все правильно.
     
    Все лишние правила фаервола на роутерА я отключал последовательно проверяя где проблема.
    Как оказалось проблема в самом первом правиле.
    /ip firewall mangle add chain=prerouting src-address-list=local dst-address-list=!local action=mark-routing new-routing-mark=route_to_proxy in-interface=!ether9  
     
    Написал в суппорт микротика, наши прибалтийские товарищи попросили таблицу маршрутизации с роутерА и замолчали.
     
    Складывается ощущение что директива in-interface= отрабатывает не верно.
    Мне кажется что она маркирует пакет двумя метками route_to_proxy и main
     

    Всего записей: 287 | Зарегистр. 24-08-2010 | Отправлено: 03:57 08-11-2011
    Chupaka



    Silver Member
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

    Цитата:
    Мне кажется что она маркирует пакет двумя метками route_to_proxy и main

    такое, к сожалению или к счастью, невозможно - у пакета может быть одна и только одна мерка маршрута

    Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 10:11 08-11-2011
    sumyst



    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Chupaka
    Знаю, не правильно выразился.
    "помещает сразу в 2 таблицы" так наверное правильнее будет.
     
    А вообще есть версии почему такое происходит?

    Всего записей: 287 | Зарегистр. 24-08-2010 | Отправлено: 10:18 08-11-2011
    Chupaka



    Silver Member
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
    я тут попробовал поднять ваши посты, картинки выдают ХТТП/403, и всё плохо %)
     
    пробовали совсем ручками проследить "тестовый" пакет по всему маршруту? навскидку - любой возвращающийся к пользователю пакет не заворачивается ли обратно на прокси, вне зависимости от того, откуда пришёл?..
     
    з.ы. для src-NAT использовать предварительную маркировку маршрута - шикуете? сделайте out-interface=WAN action=masquerade - и будет вам счастье...

    Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 10:28 08-11-2011
    sumyst



    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Chupaka
    Последний урл работает, вот прямой линк:
    http://imglink.ru/pictures/07-11-11/a2245b16b22527498d865540d185dede.jpg
     
    "пробовали совсем ручками проследить "тестовый" пакет по всему маршруту? навскидку - любой возвращающийся к пользователю пакет не заворачивается ли обратно на прокси, вне зависимости от того, откуда пришёл?.. "
     
    Нет не заворачивается, я вместо прокси временно воткнул машинку с фрей и роутингом меж интерфейсами и смотрел тцпдампом.
     
    Да и судя по логу форвардинга самого микротика все проходит как надо.
     
    "з.ы. для src-NAT использовать предварительную маркировку маршрута - шикуете?  сделайте out-interface=WAN action=masquerade - и будет вам счастье..."
     
    В таком случае при падении прокси пользователи пойдут через нат и будет не учтенный трафик, а этого не хотелось бы.

    Всего записей: 287 | Зарегистр. 24-08-2010 | Отправлено: 10:45 08-11-2011
    rosalin



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

    Цитата:
    оо… точно, протупил. замаяли сегодня(((

    разобрался  
     
    помогло  
    скрипт
    /ip proxy access disable [/ip proxy access find comment="scheduled based on time"]
    /ip proxy access enable [/ip proxy access find comment="scheduled based on time"]

     
    и в шедулер на влючение

    Всего записей: 2594 | Зарегистр. 15-04-2003 | Отправлено: 11:20 08-11-2011
    Chupaka



    Silver Member
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
    sumyst

    Цитата:
    Нет не заворачивается, я вместо прокси временно воткнул машинку с фрей и роутингом меж интерфейсами и смотрел тцпдампом.  
     
    Да и судя по логу форвардинга самого микротика все проходит как надо.

    но ведь куда-то же пакет не туда уходит, где-то же теряется...

    Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 13:12 08-11-2011
    sumyst



    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Chupaka
    Пакет уходит куда нужно. Смотрел сниффером на интерфейсах прокси.
     
    Вот откуда берется этот хоп я так и не понял
    3 192.168.168.1                           1ms   1ms   1ms  
     
    (сдается мне происходит следующее: пакет форвардится в соответствии с правилом на прокси, форвардится проксей, попадает на 9й интерфейс и там почему-то попадает сразу в 2 таблицы маршрутизации)
    Других объяснения я все равно не придумал.      
     
    Кстати, как только включаешь НАТ на проксе, все начинает работать так, как надо.
    Но двойной нат не самое красивое решение.

    Всего записей: 287 | Зарегистр. 24-08-2010 | Отправлено: 13:50 08-11-2011 | Исправлено: sumyst, 13:53 08-11-2011
    Chupaka



    Silver Member
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
    sumyst

    Цитата:
    Вот откуда берется этот хоп я так и не понял  

    это адрес роутера - ведь пакет два раза проходит через роутер, до и после прокси
     

    Цитата:
    Кстати, как только включаешь НАТ на проксе, все начинает работать так, как надо.

    видимо, у вас обратный пакет всё же не маркируется для перебрасывания на ван прокси (чтобы через проксю вернуться), поэтому при натировании пакеты имеют адрес прокси, маршрут на который прописан в таблице main (как connected); а при отключенном на прокси натировании пакеты возвращаются напрямую к пользователю, минуя проксю. дальше - по обстоятельствам (правила фильтра, етц)...

    Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 15:02 08-11-2011
    sumyst



    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Это адрес транзитной сети до роутерБ каким образом пакет с назначением 8.8.8.8 может 2 раза пройти этот интерфейс?
     
    При трассировке адрес хопа это адрес интерфейс на который пришел пакет и через который он был смаршрутизирован.
    Тоесть следующим хопом после ЛАН прокси, должен быть IP микротика в транзитной сети ВАН прокси.
    Тоесть 172.24.2.1.
     
    Вот на всякий случай таблица маршрутизации с роутера А
     
     
    >>  0 A S  dst-address=0.0.0.0/0 gateway=10.1.1.2  
    >>         gateway-status=10.1.1.2 reachable ether8 distance=1
    >> scope=30  
    >>         target-scope=10 routing-mark=route_to_proxy  
    >>  
    >>  1 X S  dst-address=0.0.0.0/0 gateway=172.24.2.2  
    >>         gateway-status=172.24.2.2 inactive distance=1 scope=30  
    >>         target-scope=10 routing-mark=From_NAT  
    >>  
    >>  2 ADS  dst-address=0.0.0.0/0 gateway=10.0.3.1  
    >>         gateway-status=10.0.3.1 reachable ether10 distance=0
    >> scope=30  
    >>         target-scope=10 vrf-interface=ether10  
    >>  
    >>  3 ADC  dst-address=10.0.3.0/24 pref-src=10.0.3.107
    >> gateway=ether10  (Это линк до Провайдера.)
    >>         gateway-status=ether10 reachable distance=0 scope=10  
    >>  
    >>  4 ADC  dst-address=10.1.1.0/24 pref-src=10.1.1.1 gateway=ether8  
    >>         gateway-status=ether8 reachable distance=0 scope=10  
    >>  
    >> 5 A S  dst-address=10.100.103.0/24 gateway=192.168.168
    >>         gateway-status=192.168.168.2 reachable ether6 d
    >>         target-scope=10  
    >>  
    >>  6 ADC  dst-address=172.24.2.0/24 pref-src=172.24.2.1 g
    >>         gateway-status=ether9 reachable distance=0 scop
    >>  
    >>  7 ADC  dst-address=192.168.168.0/24 pref-src=192.168.1
    >>         gateway-status=ether6 reachable distance=0 scop
     
    Обратите внимание, никаким образом таблица маршрутизации не ведет пакет 8.8.8.8 обратно к роутеруБ
     
    "видимо, у вас обратный пакет всё же не маркируется для перебрасывания на ван прокси (чтобы через проксю вернуться), поэтому при натировании пакеты имеют адрес прокси, маршрут на который прописан в таблице main (как connected); а при отключенном на прокси натировании пакеты возвращаются напрямую к пользователю, минуя проксю. дальше - по обстоятельствам (правила фильтра, етц)..."
     
    А вот это уже более похоже на правду, НО и в таком случае трассировка должна проходить.
    Логика такая:
    1) клиент с src 10.100.103.254 отправил пакет на dst 8.8.8.8
    2) пакет отправляется на гейт клиента 10.100.103.1 (роутерБ)
    3) гейт клиента в соответствии с дефолтным маршрутом отправляет пакет на 192.168.168.1 (роутерА)
    4) роутерА в промаркировав пакет форвардит его на IP прокси 172.24.1.2
    5) прокси роутит пакет меж интерфейсами и отправляет на свой дефолт 172.24.2.1
    6) Пакет на ether9 маркируется, отправляется на НАТ и затем во вне.
    7) Обратный пакет пройдя нат с src 8.8.8.8 и dst 10.100.103.254 раутится обратно.
     
    Даже в таком случае все должно работать если обратный пакет ушел минуя прокси.
    И опять же совершенно непонятно откуда взялся второй хоп 192.168.168.1

    Всего записей: 287 | Зарегистр. 24-08-2010 | Отправлено: 15:17 08-11-2011 | Исправлено: sumyst, 15:19 08-11-2011
    Chupaka



    Silver Member
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

    Цитата:
    Это адрес транзитной сети до роутерБ каким образом пакет с назначением 8.8.8.8 может 2 раза пройти этот интерфейс?

    в этом плане всё предельно просто: маршрутизатор получает пакет с TTL=1, уменьшает, получает ноль, отбрасывает. дальше посылает ICMP-сообщение об этом. в качестве src-address выбирается pref-src конечного маршрута для dst-address
     

    Цитата:
    Логика такая:

    вот я про седьмой пункт и говорю... первые шесть - да, всё вроде правильно

    Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 16:33 08-11-2011
    sumyst



    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Chupaka
    Дык про то и речь, дважды на пути пакета до 8.8.8.8 адрес 192.168.168.1 ну никак не может встретится.
    С учетом того что при трассировке каждый раз ттл увеличивается на 1.
     
    "вот я про седьмой пункт и говорю...  первые шесть - да, всё вроде правильно"
     
    Я собственно хотел сказать о том, что обратный пакет даже не проходя через прокси как это задумывалось, все равно будет доставлен адресату тоесть клиенту тестБ.
    В таком случае все равно должны быть пинги и работать интернеты.

    Всего записей: 287 | Зарегистр. 24-08-2010 | Отправлено: 16:44 08-11-2011 | Исправлено: sumyst, 16:46 08-11-2011
    Chupaka



    Silver Member
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
    sumyst

    Цитата:
    Я собственно хотел сказать о том, что обратный пакет даже не проходя через прокси как это задумывалось, все равно будет доставлен адресату тоесть клиенту тестБ.  
    В таком случае все равно должны быть пинги и работать интернеты.

    ну, правил фильтра файрвола я не видел, а об их отсутствии никто не упоминал
     

    Цитата:
    Дык про то и речь, дважды на пути пакета до 8.8.8.8 адрес 192.168.168.1 ну никак не может встретится.

    что вы называете словом "встретиться"? роутер два раза отправляет клиенту пакет "TTL Exceeded", два раза на один и тот же адрес - адрес клиента. почему он первый раз должен выбрать один адрес, второй - другой?.. ведь в маршруте на клиента pref-src не меняется

    Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 17:15 08-11-2011
    sumyst



    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Chupaka
    правил кроме ната и мангла нет
     
    "что вы называете словом "встретиться"? роутер два раза отправляет клиенту пакет "TTL Exceeded", два раза на один и тот же адрес - адрес клиента. почему он первый раз должен выбрать один адрес, второй - другой?.. ведь в маршруте на клиента pref-src не меняется"
     
    Коллега, может мы друг друга недопонимаем?
     
    Рисую схему:
     
    Клиент 10.100.103.254 отправляет трассировку до 8.8.8.8
    1) первый пакет с ттл = 1 прилетает на  10.100.103.1 (роутерБ) который отвечает ICMP Time Exceeded  
    2) второй пакет с ттл = 2 прилетает на 192.168.168.1 (роутерА) который отвечает ICMP Time Exceeded
    3) пакет с ттл = 3 форвардится на 172.24.1.2 (лан прокси) который отвечает ICMP Time Exceeded  
    4) пакет с ттл = 4.... и куда (и как) он должен прилететь чтоб ICMP Time Exceeded ответил 192.168.168.1
    ? ( и это с учетом того, что этот пакет я вижу сниффером исходящим с ВАН интерфейса прокси сервера)
     
    Вот у меня в голове не сростается никак. Может я заработался, но механизм данного действа я понять не могу.
     
    Спасибо за ответы кстати.
     
    И кстати, TTL Exceeded всетаки отправляется не с pref-src, а с интерфейса на который пришел пакет. Так во всяком случае должно быть.

    Всего записей: 287 | Зарегистр. 24-08-2010 | Отправлено: 17:47 08-11-2011 | Исправлено: sumyst, 17:55 08-11-2011
    Chupaka



    Silver Member
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору

    Цитата:
    4) пакет с ттл = 4.... и куда (и как) он должен прилететь чтоб ICMP Time Exceeded ответил 192.168.168.1

    он должен прилететь на роутер, через ether9, если не ошибаюсь. у роутера в сторону юзера смотрит всё ещё 192.168.168.1 - поэтому он с этого адреса и отвечает
     

    Цитата:
    TTL Exceeded всетаки отправляется не с pref-src, а с интерфейса на который пришел пакет. Так во всяком случае должно быть

    когда говорите "должно" - подкрепляйте слова ссылками на RFC =) здесь мы видим так, как оно есть. и именно так оно работает

    Всего записей: 3719 | Зарегистр. 05-05-2006 | Отправлено: 18:20 08-11-2011
    sumyst



    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    "когда говорите "должно" - подкрепляйте слова ссылками на RFC =) здесь мы видим так, как оно есть. и именно так оно работает"
     
    Ну так это Вы начали утверждать что роутер для ответа выберет preferred source.
     
    На деле современные маршрутизаторы сейчас далеко не всегда соблюдают rfc 1812 (и микротик кстати тоже), и это правильно я считаю. Позволяет строить более точную карту маршрута.
     
    А вообще мы уклонились от темы. Почему тогда сам прокси, IP ВАН интерфейса которого тоже находится в листе local вполне нормально натится, а транзитные пакеты - нет?

    Всего записей: 287 | Зарегистр. 24-08-2010 | Отправлено: 02:12 09-11-2011 | Исправлено: sumyst, 23:53 09-11-2011
    sumyst



    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Уточнил проблему.
    Удалось поставить в разрыв между провайдером и роутеромА сниффер.
     
    Оказывается что пакеты из локальных сетей уходят "неотначенные"
     
    Правила такие:
     
    chain=prerouting action=mark-routing new-routing-mark=To_NAT src-address-list=local dst-address-list=!local passthrough=yes in-interface=ether9  
     
     chain=srcnat action=masquerade routing-mark=To_NAT src-address-list=local dst-address-list=!local out-interface=ether10
     
    Вроде все просто и правильно. Ан нет.
    Что может быть не так?
     
    PS пожалуйста обратите внимание на маленький ньюанс.
    В такой конфигурации пакеты инициированные самим прокси сервером натятся без проблем.
    Не натятся ТОЛЬКО транзитные пакеты.
     
    Спасибо.

    Всего записей: 287 | Зарегистр. 24-08-2010 | Отправлено: 06:35 10-11-2011
    Sergey Sosnovsky



    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Объясните может быть, чтобы из кэша прокси качалось медленнее чем из интернета.
     
    Поднят прокси указан    cache-on-disk: yes.
    Качал файл Оперой - 50 мегабайт. Скорость что-то около 500к (наверное 4 мегабита канал).
    Второй раз этот же файл (специально посмотрел лежит в кэше, канал не использует) -- скорость около 400к.
    Винт 80Gb старенький.
     
    Вообще такое возможно, или что-то в шейпере?

    Всего записей: 86 | Зарегистр. 07-07-2004 | Отправлено: 10:42 10-11-2011
       

    Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147

    Компьютерный форум Ru.Board » Компьютеры » В помощь системному администратору » MikroTik RouterOS (часть 3)
    ShriEkeR (05-01-2012 00:59):


    Реклама на форуме Ru.Board.

    Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
    Modified by Ru.B0ard
    © Ru.B0ard 2000-2024

    BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

    Рейтинг.ru