Russian Users MikroTik | Форум пользователей MikroTik

Sertik писал(а): ↑19 июл 2018, 19:28 1. Так у вас маршруты еще и рекурсивные !

В последнем примере да, там статика, всё просто и естественно,
как же без рекурсии, тем более что провайдеры приходят по вилану,
надо же аналитику как-то делать и узнавать есть канал(ы) живые (в работе).

Sertik писал(а): ↑19 июл 2018, 19:28 2. Цитата: Я выше ответил, нельзя использовать сразу в одном правиле два шлюза, у Вас может и будет возникать
такая ситуация, что зайдя на SSL страницу или скажем работая в онлайн-банке, первая часть
запросов уйдёт через первого провайдера, а вторая через второго = банк сразу не будет работать.
Почему нельзя ? А как же в большинстве инструкций так и делают - не правильно ?
Вот, например, .... http://unixteam.ru/content/mikrotik-i-dva-provaydera

На торрентах это круто, а вот в некоторых моментах не очень. Поэтому я пока
придерживаюсь правила - в один момент времени 1-н клиент сидит на одном канале.
Хотя друг у меня сделал так, как Вы приводите - сделал отдельную маркировку,
создал маршрут, куда прицепил сразу 3-х провайдеров, засунул в эту маркировку отдельный комп,
торрент хорошо пошёл. Сайты с его слов почти не работали, тупили, особенно SSL (почему так было,
внизу ещё раз об этом написал чуть подробнее).

Sertik писал(а): ↑19 июл 2018, 19:28 3. Если дефолтный маршрут немаркированный делается только на одного провайдера - это совсем не интерестно.
Если два дефолтных немаркированных с разными дистанциями - это еще куда ни шло.

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

Также забыл добавить, что у меня кроме 3х провайдеров, у меня ещё местные сети
описаны почти все, и у нас есть такое, что некоторые ресурсы не работают если зайти с
одного провайдера, но работают с другого, опять же, всё это маршрутами сделано и
также всё работает как задумано.

Sertik писал(а): ↑19 июл 2018, 19:28 Но почему в одном то маршруте нельзя указать оба шлюза ? Наверняка как то можно так делать ...

Ну яж написал, представьте, Вы работаете по такому маршруту и Вы работаете, бегаете по сайту,
в рамках каких то уже установленных сессий, Вы будете так же продолжать работать
по одному провайдеру, но как только ссылка, сессия создаст новый поток, Вы уже будете
идти с другого адреса, теперь вспомните, что у микротика есть таблица коннекшинов,
такая таблица (в какой то степени) есть и у других роутеров, и как они должны понимать,
что открыв очередную вкладку на ленте-ру, это всё ещё Вы, но уже зашли со двора?
Тот узел захочет Вам ответить на Ваш адрес (с первого провайдера).

Тема очень обширная, как я сам и признаюсь, я в ней плаваю и не скрываю,
попробуйте сами на практике поиграться, практика - хороший учитель,
порой не понимаешь, но чувствуешь.

Vlad-2, вопрос не по теме немного.

Скажите, будет ли какая-нибудь разница если я настрою роутер скажем не совсем традиционным способом - как свич.
То есть обычно делается так: один порт скажем Eth1 оставляется под Wan, остальные объединяются в switch или чаще в бридж.
У меня же все пять портов роутера R2 объединены в свич, Eth1 является master-oм. Он же получает статический адрес от другого (главного) роутера - R1. Таким образом, втыкая в любой порт этого роутера-свича R2 клиентов мы получаем адреса для них из подсети главного роутера R1 по DHCP.
Все так и было и вроде нормально работало, пока у свича не появился второй канал в Интернет - в виде USB-модема с СИМкой с прямым белым IP. И соответственно захотелось получать Интернет и от R1 и от модема. Тем более, что через модемный канал настроил VPN-сервер для захода на R2 снаружи.

Вот тут то и начались странности поведения - естественно есть два маршрута в Интернет вида:
0.0.0.0.0/24 gateway ether1 и 0.0.0.0/0 gateway ppp-out (модем) с разными дистанциями. Когда модемный путь имеет меньшую дистанцию вообще пропадает связь по ethernet1 с роутером R1 - это вполне логично (его то путь становится неактивным).
Как нормальные люди достигают того, что можно одновременно ходить с R2 в интернет через оба шлюза и можно было бы достичь R2 снаружи со стороны R1 и через модем.
Чувствую, что именно тут и нужны манглы. Ваша схема подойдет ?
Не будет ли глюков из-за того, что весь R2 по сути настроен как управляемый свич ? (Я имею ввиду, что Eth1 не выделен из общей связки, а Eth2-Eth5 не засунуты как обычно в общий бридж ? - не хотелось мне городить для бриджа еще одну сеть со своей адресацией) ?

Sertik писал(а): ↑20 июл 2018, 15:34 Чувствую, что именно тут и нужны манглы. Ваша схема подойдет ?

Думаю что да.

Sertik писал(а): ↑20 июл 2018, 15:34 Не будет ли глюков из-за того, что весь R2 по сути настроен как управляемый свич ? (Я имею ввиду, что Eth1 не выделен из общей связки, а Eth2-Eth5 не засунуты как обычно в общий бридж ? - не хотелось мне городить для бриджа еще одну сеть со своей адресацией) ?

Сложно сказать, не должны если делать грамотно и правильно.
Приведу пример, думаю на 60-75% примерно где-то и Ваша ситуация (во всяком случаи я так её виуж).
(Сначала картинка, потом пояснение):


1) обычный роутер у человека, помогаю ему и настраивать и слежу, как это он делает.
2) у него обычное подключение, рррое, всё как у всех
3) для удобства и так как уже основные настройки сделаны, я поднял туннель между его роутером и своим,
описал статическую маршрутизацию наших локальных сетей, то есть подружил наши сети,
и я могу и он может заходить по серым нашим адресациям. Этот статическая запись на картинке выделена зелёным!
4) и дабы тоже человеку показать возможность управлением трафиками на микротиках, я решил сделать
(условно для его) ему отдельный канал (через себя) и сделав мангл-правила, сделав маркировку,
всё это описал через свой же маршрут, но уже с маркировкой, и выделил красным.

Итого что мы имеем:
а) ходим локально в сетях через маршрут (через туннель)
б) он может через промаркированный маршрут выходить в глобал через меня (через туннель).
То есть и доступ в ЛАН(ы) и доступ в Интернет - всё в рамках одного туннеля (а у Вас в рамках одного порта).

Прошу, прощения, последние вопросы снимаются ! Сам пробуя настройки выдернул один из кабелей из порта роутера, потом долго чесал репу и удивлялся почему при установленных и живых маршрутах нет элементарной связи между роутерами соединенных кабелем - а он не в порту ... Все нормально, в том числе при настройке роутера в качестве "свича", все работает.
Осталась главная засада - с двумя маршрутами. Если у них разные дистации, то VPN-север доступен снаружи, только когда маршрут через его канал имеет меньшую дистацию. Это плохо. Нужно сделать так, чтобы маршруты работали в балансировке ...
Кстати, Влад, за Вашу схему большое спасибо, пока не попробовал еще - обдумываю. Но мне почему то заранее кажется, хоть я в этом и полный чайник, что у Вас там избыточное количество правил - 10 правил из которых два инпут, два оутпут и шесть прероутинг и форвард. Вездь стоят "passroot=no". Даже вспоминая инструкции, которые читал, помню, что часть вещей метить ненужно - какие-то соединения обрабатывает механизм connection tracking ...
Не могли бы Вы, если у Вас будет время, прокомментировать каждое правило в Вашей схеме (хотя бы для одного из пары Wan) - что конктерно они делают.
Почему некоторые товарищи метят только новые коннекты в своих схемах (new connection) а Вы так не делаете ?
Кто-то использует какие то loop back bridge интерфейсы без адресные и прочее ...
Понятно, что тема очень обширна, но на первое время, хотелось бы понять как работает хотя бы одна нормальная схема с балансировкой двух каналов и чтобы она была такая, чтобы каналы работали одновременно и полноценно и пропускали меченные соединения все куда кому надо.

Настроил все по Вашим манглам. Маршрут сделал один обший с двумя шлюзами. Интересно, что при таком варианте маркировки работают в получается при любом раскладе входить на VPN-сервер снаружи (когда активны оба ВАН или когда активен один, тот который имеет белый IP для этого сервера).
Если в порты роутера подключить комп то пинг на 8.8.8.8 идет, а выхода в Интернет нет. Если роут с двумя шлюзами выключить и выключить маркированные роуты, а сделать дефолтный 0.0.0.0/0 с указанием одного из шлюзов - тогда у компа появляется выход в Интернет.

Sertik писал(а): ↑20 июл 2018, 22:16 Настроил все по Вашим манглам. Маршрут сделал один обший с двумя шлюзами. Интересно, что при таком варианте маркировки работают в получается при любом раскладе входить на VPN-сервер снаружи (когда активны оба ВАН или когда активен один, тот который имеет белый IP для этого сервера).
Если в порты роутера подключить комп то пинг на 8.8.8.8 идет, а выхода в Интернет нет. Если роут с двумя шлюзами выключить и выключить маркированные роуты, а сделать дефолтный 0.0.0.0/0 с указанием одного из шлюзов - тогда у компа появляется выход в Интернет.

Может НАТ не сделали для второго канала?

Я описывал какие могут быть проблемы если использовать два шлюза одновременно в маршруте. Поэтому это не использую такую комбинацию.
А так - пакеты маркируются, приходят и уходят как надо, ну и для внешнего доступа тоже всё работает отрабатывается.
Также, имея основной канал, как я писал выше, не надо явно описывать кто будет работать через него, так как он
основной, то все туда будут и попадать (по-умолчанию), и достаточно только тех, кого надо, тех явно и направляем в другой(ие) каналы и всё.

Нат есть для обоих каналов. Пакеты все маркируются, спору нет. Вроде все гуд. Но, вот в чем прелесть иметь два канала, а пользоваться одним - как резервирование получается а не балансировка. Никак не пойму, почему нельзя настроить так, чтобы оба канала работали нормально одновременно ... раз все маркируется и ходит по своим провайдерам, так, какого же ... Интересно что у меня не правильно. Можете глянуть мои настройки, если Вам доступ сделать к роутеру ?

Sertik писал(а): ↑23 июл 2018, 16:31 Нат есть для обоих каналов. Пакеты все маркируются, спору нет. Вроде все гуд. Но, вот в чем прелесть иметь два канала, а пользоваться одним - как резервирование получается а не балансировка. Никак не пойму, почему нельзя настроить так, чтобы оба канала работали нормально одновременно ... раз все маркируется и ходит по своим провайдерам, так, какого же ... Интересно что у меня не правильно. Можете глянуть мои настройки, если Вам доступ сделать к роутеру ?

Давайте слегка определимся с положением дел:

1. У меня свой скромный наработанный конфиг (типа рецепта), я не обещал золотых гор.
1.1. Он прост, прозрачен и понятен. При пропадания вторичных каналов, все работают по основному, при пропадании
основного канала и при настройки рекурсии - переключается на действующий/доступный.
2. Я предупреждал, что у меня НИ балансировка, не суммирование каналов -НЕТу, у меня между этими сущностями.
3. Я всё же использую каналы одновременно (за счёт указания какие сети/подсети/отдельный IP-адреса работают в том и/или ином канале).
3.1. Так как компьютеров много, я один компьютер (или виртуальную машину) подключаю в один канал, она качает,
при этом, я сам могу/сижу в другом канале. И мне торренты/закачки не мешают, и я спокойно смотрю/читаю,
и закачка(и) идут на максимальных скоростях при благоприятных условиях у провайдера.
3.2 Как следствие - каналы я использую и два и три и четыре (сколько есть и сколько маркировок) и балансирую
между разумностью, скоростью и удобством.


Теперь давайте порассуждаем по части одновременного использования двух каналов,
я уже писал, но Вы меня почему в этом контексте не слышите и никак не дополнили,
но вопросы всё же задаёте:

Берём тот же торрент(там мелкие UDP пакеты, каждый пакет, это новое соединение,
и в рамках одного соединение всегда оно будет идти через одного провайдера.
Соединение не разделяемо, это если приводить пример: если мы входим в автобус через переднюю
дверь, и уже начали входить, наши ноги не могут отдельно войти через заднюю дверь для ускорения.
Поэтому в рамках сессии/соединения - всегда оно идёт через одного провайдера. У торрента их куча,
мелких,быстрых и поэтому каждая сессия UDP будет идти то через одного,то через другого провайдера.
И в таком примере будет оба канала использоваться и качаться.
Тут я выше рассмотрел как сессии ведут себя, и это только при закачке, Вы хотите на обоих
каналах работать в Интернете, открыли поисковик, загрузили начальную страничку и это
всё было через первого провайдера, начали искать - отдельная сессия ушла через второго
провайдера, кликнули по ссылке - ушло снова на первого провайдера, и вот тут,при таких
туда-сюда смене, обратные ответы (ответы от клиента...от браузера будут тоже меняться,
то туда...то сюда). И вот тут и возникают проблемы, что на той стороне (особенно с банками)
проверяется адресация, порт и ряд других параметров, если каждая сессия будет
менять эти данные (приходить то с одного,то с другого провайдера), то как та сторона
будет знать кому отвечать? И потом, то это уже будет как нездоровая обращение
на ресурсы и скорее всего система не будет работать правильно и должным образом.

Поэтому качать (принимать) пакеты одновременно можно (и чем они меньше и проще используется
протокол, тем лучше и проще), при полном взаимодействии (интерактивно) с сайтами/
SSL-сайтами/банками - такой фокус не прокатывает.

Вот такие у меня мысли, понятие системы и ощущения.....

Что вы мусолите эту агригацию то. Ну просто же все
Есть несколько способов
1. PCC - https://wiki.mikrotik.com/wiki/Manual:PCC
Лично я его больше предпочитаю т.к. можно изменять алгоритмы и тем самым обойти подводные камни со всякими сбербанк онлайн и им подобных. Ну и настроить можно хоть агригацию нужных соеденений, а не тупо всего трафика. Вобщем весьма гибкий метод

2. ECMP - https://wiki.mikrotik.com/wiki/ECMP_loa ... masquerade
Лично мне этот метод жудко ненравится из за его топорности ну и еще по рду причин о которых ниже

3. NTH - https://wiki.mikrotik.com/wiki/NTH_load ... masquerade
как то не доводилось его испробовать

Все эти методы объеденяет одно, это распределение пакетов по каналам но есть огромный подводный камень. В случае если у вас отваливается один из каналов то вы начинаете терять часть пакетов и начинаются проблемы. Что бы это решить нужен скрипт. Скрипт банально опрашивает каналы и в случае если видит что один сдох то отключает агригацию (если 2 канала) либо меняет схему аригации (если 3 и более). Самое простое это управлять PCC, с ECMP чисто технически сложнее но лично я не вижу смысла в усложнении алгоритма т.к. это добавляет очередной минус в эту схему и PCC как бы выходит на первое место. ECMP на просторах Интернета самый рапространеный способ ибо он настраивается элементарно, но вот полное решение выглядит весьма неудобно + проблемы с ресурсами у которых есть определные требования к безопасности

ИТОГО для организации агригации
1. Размечаете трафик
2. Настраиваете нужный вам метод
3. Пишем скрипт который управляет выбраным вами методом в зависимости от статуса каналов

Причем если вы агригируете модемы и у вас их довольно много (от 3х более) то скрипт нужен который распаралеливает опросы модемов, а не делает это по порядку. Это нужно что бы ускорить реакцию на сдохшй модем, а подыхают они в некоторых условиях довольно часто У меня на данный момент не получлось сделать реакцию менее чем 7с Есть идеи мысли как сократить еще на пару секунд но как правило трудозатраты этого не оправдывают. Для 90% случаев рекция в пределах 30с более чем достаточна

Vlad-2 Вам за все спасибо огромное ! И за Ваш "рецепт" тоже. Я торрентами не пользуюсь вообще и ничего не качаю в таких объемах. Все что мне нужно было - чтобы работали два канала одновременно на вход и выход. Может еще проблема была в тем, что роутер, на котором я это все делал не имел "собственной" LAN сети, а был настроен как свич - получал адрес с другого роутера и все, что подключено в его порты - тоже получали адреса с другого (DHCP-сервер на другом настроен).
Когда выкинул адрес этой внутренней подсети из списка LAN для prerouting и forward "рецепта" vlad-2 - наоборот открылся нормальный доступ в эту сеть ... Видимо она тут считается не внутренней.

Vqd тоже спасибо. PCC у меня работает в одном месте. Но тоже до конца нет понимания правильно все настроено или нет.

Видимо дело в том, что я пока в принципе плохо понимаю, как работают маркировки и меченные маршруты и по большей части пользуюсь чьими-то "готовыми" рецептами такого рода ... Может на курсы Микротик пойти ...