Пользователь
16,8
рейтинг
nkusnetsov
0
С asterisk, вроде упростили. Для прохода через nat сделали pjsip. Но я его еще не пробовал применять пока. Небыло необходимости.
nkusnetsov
0
«Ну нельзя же делать такой простой и наглядный интерфейс к iptables! Его же любой тупица освоит и мы без работы останемся!»
То есть да, надо просто представлять себе, как работает линуксовый iptables и стек IP (маршрутизация, NAT и всё такое)

Я Вам больше скажу. Шапочно знаком с несколькими админами в небольших предприятиях, которые начинали с роутеров на винде [+керио | +иса] и переходили на линукс через микротик, ибо там логика уже линуксовая, а интерфейс наглядно-виндовый. У тех из них, с кем общался главная претензия оказывалась как раз к линуксовой консоли, за «отсутствие наглядности как в винбоксе». Бывает и такое, да…
nkusnetsov
0
Увы, в отличие от Вас, есть граждане которые считают, что «вот сиско надо изучать, а всё остальное я и сам знаю». Потом напоровшись на грабли собственного незнания граждане кричат, что «микротик не работает, надо было брать сиско».
Касательно QuickSet — он предназначен исключительно для стартового, базового конфигурирования. Если в микротике уже прописана какая-то работающая сложная конфигурация, QuickSet для дополнения параметров использовать нельзя, т.к. он может тупо накатить свои параметры без учета уже имеющихся.
nkusnetsov
+1
Оборудование 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.

Если хочется оценивать доступность канала по-другому — никто не мешает написать скрипт.
nkusnetsov
0
«Подкрашивание» пакетов фаерволом, во-первых кушает ресурсы и может требовать отдельной таблицы роутинга. Во-вторых это еще одна область настройки, что в случае смены правил может привести к неочевидным сбоям, а так всё в одном разделе "/ip route" настроено и никуда более лазать не нужно. В третьих, модификация от базовой, описанной в статье минимальна — +1 строка конфига (1 доп.маршрут).
nkusnetsov
0
Ха. У нас в операторах связи такие «спецы» работают, что аж страшно за отрасль реально.
Чел на НАГе с 13(!) летним стажем со статусом «VIP» морозит:
несмешной текст вообще
В копилку сисадмина. Мокротик настроить нормально можно только после 5 сбросов в заводские настройки. Инет в настройке мокротика не помогает даже в типовых случаях, ибо из пяти инструкций — ни одна на другую не похожа. Если вы сумели настроить мокротик с 4-го раза — вы клон Сааба, а если с первого, то вы прадедушка Сааба :)

Просто на неделе притащили микротик для настройки в типовом режиме бытового роутера. Я сразу послал клиента в пешее эротическое, а техдир — закусился. Гимнастика его мозга продолжалась 3 дня, из них — два выходных дома :) Но он — победил адское поделие :)

Пруф на текст
nkusnetsov
0
Можно. К сожалению, далеко не все владеют навыком написания скриптов к микротику. Постоянно встречаю деятелей, которым настройка оборудования сложнее домашнего TP-Linka создает проблемы. От микротика эти люди вообще впадают в шок или истерику. Куда уж им в скрипте результаты анализировать и обрабатывать.
nkusnetsov
0
У дефолтных маршрутов как раз указана опция check-gateway.
/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 check-gateway=ping

Это помогает активировать/деактивировать сам маршрут.
Netwatch этого не понимает. Он пользутестя результатом — перестроенным на запасной маршрутом.
Насколько знаю, в feature request к MikroTik'у давно висит запрос явно указывать интерфейс, с которого будет пинговать NetWattch. Вот, только когда они это реализуют — неизвестно.
nkusnetsov
0
Прямо заинтриговали. В системе несколько областей. В том числе не тупиковых. ASBR взаимодействует с quagga. Всё живет нормально. Возможно дело в правильной настройке ABR, инстансов и Area Ranges?
За исключением глюка, когда сразу после интенсивной настройки/переконфигурации, требуется рестартовать инстанс, других не попадалось.
Поделитесь примерами топологии и конфигов при закольцовывании. Можно в личку, поскольку чуть оффтоп.
nkusnetsov
0
Немного странный выбор pseudo-wire технологии туннелирования, когда для этого есть IPIP/GRE/L2TP и прочие протоколы точка-точка? Были какие-то проблемы с реализацией OSPF/BGP на линках? Изначально EoIP совсем не для этого предназначен.
Так любят строить туннели наши «азиатские партнеры» из Индонезии и близлежащих к ней стран. Там некоторые вообще как дети — набриджуют EoIP туннелей в огромный broadcast-домен и чего-то с ним шаманят, извращаются…
nkusnetsov
0
Таким образом нас перестали пугать технические работы у провайдера, а также периодические проблемы с проходимостью GRE пакетов по определенным направлениям

Тут автор сам себе противоречит. Протокол EoIP работает на основе инкапсуляции L2-трафика внутрь GRE-пакетов. Достаточно внимательно посмотреть с помощью torch либо сделать tcpdump на транзитном маршрутизаторе.
nkusnetsov
0
Я этого и не предлагаю. Это предложил shadowalone. Вы не тому отвечаете.
nkusnetsov
+1
Автор поста как раз vlan-ы НЕ использует, у него всё здраво. Это shadowalone что-то про интерфейсы с именами «vlan» написал.
nkusnetsov
+2
Вместо того что-бы маркировать (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
Tcp-Запрос клиента:
(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 и обломится.
nkusnetsov
0
Подумайте как следует над строчками
/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. Сравните.
nkusnetsov
0
Вы не знает разницы между соединениями точка-точка и подключением через обычный ethernet при наличии broadcast-домена. Это разные случаи и методики маршрутизации и адресации будут разные.
nkusnetsov
+2
Это не проблема конфига. Это проблема упоротых провайдеров не умеющих нормально обеспечить отказоустойчивость для основных типов клиентских устройств.
Если провайдер настолько упорот, он может завести хоть 65533 gateway, только сообщать о них клиентам он как будет? Выдавать по DHCP каждые 10 секунд? Или упорно слать icmp-redirect?
Интерфейс в качестве gateway на broadcast-интерфейсе? Это тоже надо очень сильно упороться.

nkusnetsov
0
Чтобы блокировать UDP 67 (L3+L4) нужно порт(ы) выводить в софтварный бридж и использовать для фильтрации CPU. Это сильно снизит пропускную способность. Люди сделавшие фильтр на CPU, потом ноют «фиговый свитч, что-то гигабит не прокачивается».
Моё решение сохраняет ресурсы процессора, перекладывая задачу на аппаратный свитч-чип.
nkusnetsov
0
Между появлением DHCP-сервера в сети и срабатыванием алерта действительно есть небольшой временной лаг. По моим сведениям, алертер микротика срабатывает на DHCPOFFER, то есть до завершения процедуры выдачи адреса DHCP — до прохождения DHCPREQUEST, DHCPACK (именно из DHCPOFFER берется IP-адрес DHCP-сервера). По идее чужой DHCP должен быть изолирован на этой стадии, но временные издержки на запуск и исполнение скрипта, действительно могут дать интервал для одного клиента.
Скрипт делался как решение на случай «вообще нет DHCPsnooping'а». У людей вон, вообще грустно — тупые свитчи на выносах стоят.
nkusnetsov
0
Если перед ним тупой свитч, трафик злодея микротик равно отрубит. Точнее не пропустит через себя. Но те, кто подключен к тому же тупому свитчу и общаются со злодеем напрямую будут видеть чужой DHCP.
В любом случае — тупой свитч, это беда, там уже не важно, что стоит выше — cisco, huawei, d-link или mikrotik.
nkusnetsov
+1
Безусловно вручную. Такой вариант предполагает возможность некоей «профилактической работы» с пользователем-вредителем. Это минимальные издержки по сравнению с тем, что вредитель если его вовремя не остановить, может оставить без связи несколько десятков человек.
В общем-то, ничто не мешает написать еще один скрипт, который будет убирать маки из $stubvid при исчезновении их из массива алертера.
nkusnetsov
–1
«только один из двух специалистов этих сфер деятельности указал, что у них бывают конфликты.» *facepalm*
Простите, у Вас с понятием «презентабельность выборки» всё в порядке? Вы ничего не перепутали?
Когда один человек дает от 2% до 50% разброса результатов, такая выборка точно не может быть презентабельной и не может даже примерно отражать реальную ситуацию.