«Ну нельзя же делать такой простой и наглядный интерфейс к iptables! Его же любой тупица освоит и мы без работы останемся!»
То есть да, надо просто представлять себе, как работает линуксовый iptables и стек IP (маршрутизация, NAT и всё такое)
Я Вам больше скажу. Шапочно знаком с несколькими админами в небольших предприятиях, которые начинали с роутеров на винде [+керио | +иса] и переходили на линукс через микротик, ибо там логика уже линуксовая, а интерфейс наглядно-виндовый. У тех из них, с кем общался главная претензия оказывалась как раз к линуксовой консоли, за «отсутствие наглядности как в винбоксе». Бывает и такое, да…
Увы, в отличие от Вас, есть граждане которые считают, что «вот сиско надо изучать, а всё остальное я и сам знаю». Потом напоровшись на грабли собственного незнания граждане кричат, что «микротик не работает, надо было брать сиско».
Касательно QuickSet — он предназначен исключительно для стартового, базового конфигурирования. Если в микротике уже прописана какая-то работающая сложная конфигурация, QuickSet для дополнения параметров использовать нельзя, т.к. он может тупо накатить свои параметры без учета уже имеющихся.
Оборудование MikroTik базируется на Linux. Если есть понимание того, как реализована работа Ethernet + IP в Linux-Based системах, то ничего особенно сложного в настройке MikroTik нет. Официальная вики достаточно бодро обновляется, там же есть «examples».
Также есть community в соцсетях и форумы. На том же forum.nag.ru есть целых два раздела посвященных исключительно mikrotik.
Как я понял в данном варианте конфигурации, если пакеты ISP1 теряет через раз, то канал подключения будет скакать туда-сюда хаотично?
Не слишком хаотично. Есть чёткий критерий, по которому оценивается доступность канала. Этот критерий используется при «легком конфигурировании одним крыжиком»:
If no response from gateway is received for 10 seconds, request times out. After two timeouts gateway is considered unreachable.
Если хочется оценивать доступность канала по-другому — никто не мешает написать скрипт.
«Подкрашивание» пакетов фаерволом, во-первых кушает ресурсы и может требовать отдельной таблицы роутинга. Во-вторых это еще одна область настройки, что в случае смены правил может привести к неочевидным сбоям, а так всё в одном разделе "/ip route" настроено и никуда более лазать не нужно. В третьих, модификация от базовой, описанной в статье минимальна — +1 строка конфига (1 доп.маршрут).
Ха. У нас в операторах связи такие «спецы» работают, что аж страшно за отрасль реально.
Чел на НАГе с 13(!) летним стажем со статусом «VIP» морозит:
несмешной текст вообще
В копилку сисадмина. Мокротик настроить нормально можно только после 5 сбросов в заводские настройки. Инет в настройке мокротика не помогает даже в типовых случаях, ибо из пяти инструкций — ни одна на другую не похожа. Если вы сумели настроить мокротик с 4-го раза — вы клон Сааба, а если с первого, то вы прадедушка Сааба :)
Просто на неделе притащили микротик для настройки в типовом режиме бытового роутера. Я сразу послал клиента в пешее эротическое, а техдир — закусился. Гимнастика его мозга продолжалась 3 дня, из них — два выходных дома :) Но он — победил адское поделие :)
Можно. К сожалению, далеко не все владеют навыком написания скриптов к микротику. Постоянно встречаю деятелей, которым настройка оборудования сложнее домашнего TP-Linka создает проблемы. От микротика эти люди вообще впадают в шок или истерику. Куда уж им в скрипте результаты анализировать и обрабатывать.
Это помогает активировать/деактивировать сам маршрут.
Netwatch этого не понимает. Он пользутестя результатом — перестроенным на запасной маршрутом.
Насколько знаю, в feature request к MikroTik'у давно висит запрос явно указывать интерфейс, с которого будет пинговать NetWattch. Вот, только когда они это реализуют — неизвестно.
Прямо заинтриговали. В системе несколько областей. В том числе не тупиковых. ASBR взаимодействует с quagga. Всё живет нормально. Возможно дело в правильной настройке ABR, инстансов и Area Ranges?
За исключением глюка, когда сразу после интенсивной настройки/переконфигурации, требуется рестартовать инстанс, других не попадалось.
Поделитесь примерами топологии и конфигов при закольцовывании. Можно в личку, поскольку чуть оффтоп.
Немного странный выбор pseudo-wire технологии туннелирования, когда для этого есть IPIP/GRE/L2TP и прочие протоколы точка-точка? Были какие-то проблемы с реализацией OSPF/BGP на линках? Изначально EoIP совсем не для этого предназначен.
Так любят строить туннели наши «азиатские партнеры» из Индонезии и близлежащих к ней стран. Там некоторые вообще как дети — набриджуют EoIP туннелей в огромный broadcast-домен и чего-то с ним шаманят, извращаются…
Таким образом нас перестали пугать технические работы у провайдера, а также периодические проблемы с проходимостью GRE пакетов по определенным направлениям
Тут автор сам себе противоречит. Протокол EoIP работает на основе инкапсуляции L2-трафика внутрь GRE-пакетов. Достаточно внимательно посмотреть с помощью torch либо сделать tcpdump на транзитном маршрутизаторе.
Вместо того что-бы маркировать (routing-mark=) в данном случае запросто можно обойтись:
/ip route rules
раскидав по таблицам маршрутизации.
Давайте представим нормальную ситуацию, когда все внешние шлюзы считаются доступными.
Обратите внимание — сеть маскарадится в три направления, т.е. web-сервер не имеет своего белого IP. Это важно, т.к. в ответе web-сервера src-ip меняется в зависимости от направления.
Поскольку маршрутизация тогда будет идти попакетно, на основе src-ip, все ответы web-сервера пойдут через один и тот же шлюз, первым указанный в таблице, куда его приведет /ip route rule (при src=192.168.0.83 адрес web-сервера). Пусть это будет как у автора «95.11.29.254»
Тогда клиент обратившийся ко второму внешнему IP, через второго провайдера (5.35.59.162/27 interface=ISP2 ) всё равно будет получать ответы WEB-сервера через ISP1 с IP 95.11.29.254 и соединение не установится.
Установка соединения при предложенном /ip route rule
Подумайте как следует над строчками /ip address
add address=95.11.29.240/24 interface=ISP1 network=95.11.29.0
add address=5.35.59.162/27 interface=ISP2 network=5.35.59.160
Посмотрите как строится адресация на вашем PPPoE. Сравните.
Вы не знает разницы между соединениями точка-точка и подключением через обычный ethernet при наличии broadcast-домена. Это разные случаи и методики маршрутизации и адресации будут разные.
Это не проблема конфига. Это проблема упоротых провайдеров не умеющих нормально обеспечить отказоустойчивость для основных типов клиентских устройств.
Если провайдер настолько упорот, он может завести хоть 65533 gateway, только сообщать о них клиентам он как будет? Выдавать по DHCP каждые 10 секунд? Или упорно слать icmp-redirect?
Интерфейс в качестве gateway на broadcast-интерфейсе? Это тоже надо очень сильно упороться.
Чтобы блокировать UDP 67 (L3+L4) нужно порт(ы) выводить в софтварный бридж и использовать для фильтрации CPU. Это сильно снизит пропускную способность. Люди сделавшие фильтр на CPU, потом ноют «фиговый свитч, что-то гигабит не прокачивается».
Моё решение сохраняет ресурсы процессора, перекладывая задачу на аппаратный свитч-чип.
Между появлением DHCP-сервера в сети и срабатыванием алерта действительно есть небольшой временной лаг. По моим сведениям, алертер микротика срабатывает на DHCPOFFER, то есть до завершения процедуры выдачи адреса DHCP — до прохождения DHCPREQUEST, DHCPACK (именно из DHCPOFFER берется IP-адрес DHCP-сервера). По идее чужой DHCP должен быть изолирован на этой стадии, но временные издержки на запуск и исполнение скрипта, действительно могут дать интервал для одного клиента.
Скрипт делался как решение на случай «вообще нет DHCPsnooping'а». У людей вон, вообще грустно — тупые свитчи на выносах стоят.
Если перед ним тупой свитч, трафик злодея микротик равно отрубит. Точнее не пропустит через себя. Но те, кто подключен к тому же тупому свитчу и общаются со злодеем напрямую будут видеть чужой DHCP.
В любом случае — тупой свитч, это беда, там уже не важно, что стоит выше — cisco, huawei, d-link или mikrotik.
Я Вам больше скажу. Шапочно знаком с несколькими админами в небольших предприятиях, которые начинали с роутеров на винде [+керио | +иса] и переходили на линукс через микротик, ибо там логика уже линуксовая, а интерфейс наглядно-виндовый. У тех из них, с кем общался главная претензия оказывалась как раз к линуксовой консоли, за «отсутствие наглядности как в винбоксе». Бывает и такое, да…
Касательно QuickSet — он предназначен исключительно для стартового, базового конфигурирования. Если в микротике уже прописана какая-то работающая сложная конфигурация, QuickSet для дополнения параметров использовать нельзя, т.к. он может тупо накатить свои параметры без учета уже имеющихся.
Также есть community в соцсетях и форумы. На том же forum.nag.ru есть целых два раздела посвященных исключительно mikrotik.
Не слишком хаотично. Есть чёткий критерий, по которому оценивается доступность канала. Этот критерий используется при «легком конфигурировании одним крыжиком»:
Если хочется оценивать доступность канала по-другому — никто не мешает написать скрипт.
Чел на НАГе с 13(!) летним стажем со статусом «VIP» морозит:
Просто на неделе притащили микротик для настройки в типовом режиме бытового роутера. Я сразу послал клиента в пешее эротическое, а техдир — закусился. Гимнастика его мозга продолжалась 3 дня, из них — два выходных дома :) Но он — победил адское поделие :)
Пруф на текст
Это помогает активировать/деактивировать сам маршрут.
Netwatch этого не понимает. Он пользутестя результатом — перестроенным на запасной маршрутом.
Насколько знаю, в feature request к MikroTik'у давно висит запрос явно указывать интерфейс, с которого будет пинговать NetWattch. Вот, только когда они это реализуют — неизвестно.
За исключением глюка, когда сразу после интенсивной настройки/переконфигурации, требуется рестартовать инстанс, других не попадалось.
Поделитесь примерами топологии и конфигов при закольцовывании. Можно в личку, поскольку чуть оффтоп.
Так любят строить туннели наши «азиатские партнеры» из Индонезии и близлежащих к ней стран. Там некоторые вообще как дети — набриджуют EoIP туннелей в огромный broadcast-домен и чего-то с ним шаманят, извращаются…
Тут автор сам себе противоречит. Протокол EoIP работает на основе инкапсуляции L2-трафика внутрь GRE-пакетов. Достаточно внимательно посмотреть с помощью torch либо сделать tcpdump на транзитном маршрутизаторе.
Давайте представим нормальную ситуацию, когда все внешние шлюзы считаются доступными.
Обратите внимание — сеть маскарадится в три направления, т.е. web-сервер не имеет своего белого IP. Это важно, т.к. в ответе web-сервера src-ip меняется в зависимости от направления.
Поскольку маршрутизация тогда будет идти попакетно, на основе src-ip, все ответы web-сервера пойдут через один и тот же шлюз, первым указанный в таблице, куда его приведет /ip route rule (при src=192.168.0.83 адрес web-сервера). Пусть это будет как у автора «95.11.29.254»
Тогда клиент обратившийся ко второму внешнему IP, через второго провайдера (5.35.59.162/27 interface=ISP2 ) всё равно будет получать ответы WEB-сервера через ISP1 с IP 95.11.29.254 и соединение не установится.
(src-ip: 1.1.1.1:52000, dst-ip:5.35.59.162:80) -> dst-nat -> routing -> (src-ip: 1.1.1.1:52000, dst-ip:192.168.0.83:80)
Ответ web-сервера:
(src-ip: 192.168.0.83:80, dst-ip:1.1.1.1:52000) -> routing-> src-nat -> (src-ip: 95.11.29.254:80, dst-ip:1.1.1.1:52000)
Клиент запросивший соединение с 5.35.59.162:80, получит ответ с 95.11.29.254:80 и обломится.
/ip address
add address=95.11.29.240/24 interface=ISP1 network=95.11.29.0
add address=5.35.59.162/27 interface=ISP2 network=5.35.59.160
Посмотрите как строится адресация на вашем PPPoE. Сравните.
Если провайдер настолько упорот, он может завести хоть 65533 gateway, только сообщать о них клиентам он как будет? Выдавать по DHCP каждые 10 секунд? Или упорно слать icmp-redirect?
Интерфейс в качестве gateway на broadcast-интерфейсе? Это тоже надо очень сильно упороться.
Моё решение сохраняет ресурсы процессора, перекладывая задачу на аппаратный свитч-чип.
Скрипт делался как решение на случай «вообще нет DHCPsnooping'а». У людей вон, вообще грустно — тупые свитчи на выносах стоят.
В любом случае — тупой свитч, это беда, там уже не важно, что стоит выше — cisco, huawei, d-link или mikrotik.