• Mikrotik: Ограничение скорости скачивания для определенных IP-адресов
    +1
    add action=mark-connection chain=prerouting dst-address-list=mega.nz \
    new-connection-mark=upload-conn passthrough=yes

    В критерии недурно бы добавить «connection-state=new», чтобы соединение маркировалось единожды в момент его установки.
  • Mikrotik: Ограничение скорости скачивания для определенных IP-адресов
    0
    Вот и выйдет что у тебя выйдет не 1 Simple Queue, а 6 как минимум для каждого диапазона с выбранной маской.

    Ничего подобного. Диапазон IP-адресов заносится единожды в address-list и по нему проводятся дальнейшие действия с маркировкой пакетов.
    Метод описанный Louie с предварительным использованием «action=mark-connection» и последующей маркировкой по критерию «connection-mark=upload» более эффективен и, вот почему: все транзитные пакеты проверяются на принадлежность ранее помеченному соединению (1 критерий), а не списку IP-адресов. Хотя address-list, это аналог линуксового ipset, но проверка принадлежности к connection должна быть быстрее, чем проверка по хэшу IP-адреса и сверка со списком. Особенно, когда этих проверок две (два правила), одно для SRC-IP, другое для DST-IP.
    Далее, simple queue позволяет в одном правиле ограничить сразу и upload и download (если нужно), а не расползаться по двум веткам дерева — правила в дереве не учитывают направление трафика.
  • Mikrotik: Ограничение скорости скачивания для определенных IP-адресов
    0
    Как писал выше в комментариях, во-первых, simple queue не позволяет ограничивать трафик по имени маркированных пакетов. Во-вторых, он не позволяет ограничивать трафик по диапазону из нескольких IP-адресов

    Во-первых, simple queue вполне позволяет ограничивать трафик по имени маркированых пакетов. Смотрите параметр «packet-marks=». В winbox вкладка «advanced». Если у Вас не сработало, вероятно или Вы что-то сделали не так или набрели на некий баг.
    Во-вторых, прямо по диапазону ограничить не даёт и tree. Для диапазонов используется маркировка пакета в firewall-mangle.
    В simple queue можно легко ввести ограничение по IP или подсети. Их нужно указать в «target=» сколько угодно, через запятую в консоли. Либо в winbox кликнув справа от поля ввода на символ «стрелка вниз».
    И, да, для simple queue нужно обязательно указывать target. Относительно target считается направление upload/download.
  • MikroTik — несколько адресов и несколько разных MAC на одном интерфейсе
    0
    Наблюдал одного провайдера, у которого долгое время было жесткое правило «Один IP = один MAC». Потом узнал, что ограничение было связано как-то с их биллингом. То ли самописный он был, то ли просто специалистов по настройке этого биллинга небыло в штате.
  • MikroTik — несколько адресов и несколько разных MAC на одном интерфейсе
    0
    Интересный способ. Главное, относительно простой.
    Но к сожалению, для vrrp-интерфейса невозможно задать произвольный MAC-адрес, т.к. он определен стандартом «0000:5E00:01xx, где xx — номер группы VRRP».
    Из других моментов: vrrp пытается искать соседа по мультикасту и трафик может быть перехвачен с последующим захватом роли master. Версия VRRP v3 включаемая по-умолчанию не поддерживает аутентификацию, что настораживает.
    Если делать это на том же роутере, где на основном интерфейсе поднят DHCP-сервер то, dhcp-client не получает IP.
  • MikroTik — несколько адресов и несколько разных MAC на одном интерфейсе
    0
    1) Когда провайдер даёт два IP с привязкой к разным макам на одном физическом порту.
    2) Имитировать физическое присутствие некоего оборудования на площадке, фактически висящего в другой отдаленной сети — не зависит от удаленного маршрутизатора, т.к. не требует L2 туннелирования через EoIP или VPLS.
  • MikroTik — несколько адресов и несколько разных MAC на одном интерфейсе
    0
    В данном случае с dhcp не всё получится, т.к. в arp-reply идет работа с заранее известным IP-адресом. Нормально dhcp-client отработает только на основном интерфейсе «bridge-local»
  • MikroTik — несколько адресов и несколько разных MAC на одном интерфейсе
    +1
    Мне кажется Вы недооцениваете мощность процессора. На неоптимизированной системе «из коробки», при наличии простого фаервола прирост нагрузки CPU составил в среднем +2%, в редких пиках подскакивал до +10%. См. результат теста в конце статьи.
  • MikroTik — несколько адресов и несколько разных MAC на одном интерфейсе
    +1
    Конечно, процессор всегда нагружается при дополнительной обработке пакетов. Но иногда приходится с этим смириться, если нет другого варианта.
    Кстати, вот пример вопроса на соседнем ресурсе: toster.ru/q/276217
    Альтернатива — в разрыв линка установить отдельный свитч и два патч-корда в два разных порта МТ, или в один порт на два VLAN опять же, через внешний «умный» свитч.
  • MikroTik — несколько адресов и несколько разных MAC на одном интерфейсе
    0
    Спасибо, вкралась опечатка. Исправил.
  • Рекомендации, рекомендательные письма, скрипты для проверки рекомендаций — опыт HR-практика
    0
    Бывают единичные случаи, когда бывшие работодатели ссылаются на факты, которые явно негативно характеризуют соискателей

    К сожалению, видимо Вы судите по данным одного (или нескольких близких к Вам) регионов.
    В России есть несколько «суровых промышленных» и добывающих регионов, где в порядке вещей считается вслед ушедшему сотруднику давать самые гадкие характеристики. Просто потому, что он «посмел уйти от нас таких крутых и красивых». Полубарские-полубандитские замашки руководства исходящего из принципа «из нашего казино просто так не уходят». Они особенно ярко выражаются в небольших городах, с одним-двумя градообразующими предприятиями, руководство которых (небезосновательно, кстати) мнит себя «хозяевами городов». В плохом смысле этого словосочетания. У соседей в добывающем регионе часто такая беда. Справедливости ради сказать — не сплошная. И информацию порой удавалось добывать неофициально, у бывших коллег «по горизонтали», т.к. запрос к руководству и HR почти гарантированно приносил поток грязи.
  • Рекомендации, рекомендательные письма, скрипты для проверки рекомендаций — опыт HR-практика
    0
    может быть чревато — ежегодный отпуск+полный учебный отпуск каждую сессию=отсутствие на работе 2 месяца в году

    Главная проблема работодателей и HR, это отношение к людям как к материальному ресурсу. Как к деньгам или к автоматам по обслуживанию бизнеса. Порочное стремление использовать рабочее время каждого нанятого человека на 99,9% закладывает серьезную бомбу как под отдельные бизнес-процессы, так и под бизнес в целом.
    Приличные компании, при управлении материальными ресурсами предусматривают, резервы по оборудованию. Простой пример — в ИТ для отказоустойчивости, принято иметь дублирующее оборудование. Cold standby-сервера, это норма. Компании помельче, вместо резервных серверов, бывает держат критический ЗИП для оборудования. При этом менеджмент не воет, что «вон у вас лежат четыре SAS-HDD купленные за наши $$$ и ничего не делают». В своих автомобилях директора и HR-менеджеры тоже возят запасное колесо, и никто не пищит, про лишний вес и неоправдвнный расход бензина.

    Но как только дело касается людей, понимание необходимого резервирования моментально исчезает. Имея отдел, где HR расчитал штат с загрузкой сотрудников хотя бы 95%, имеем над бизнесом серьезную угрозу в случае выхода одного из сотрудников из строя (по любой причине). Кто виноват? Жадность. Жадность и непредусмотрительность. Привычка «отжимать» из человека по-максимуму. Абсолютное непонимание, что выйти из строя может не только техника, но и человек.
    Отсюда и все негативные проявления. Начиная с проблемами выхода в очередной отпуск( «а кто работать будет?»), продолжая выходами на больничные, выездами сотрудников на конференции и обучение, и заканчивая «проблемным увольнением» сотрудника.
  • Скрипт, который пишет другой скрипт и настраивает роутеры
    0
    При наличии соединения с Интернетом, проще использовать сервис www.random.org
    У него есть API, можно запросами получать данные нужного формата в plaintext, чтобы использовать в скриптах.
  • Настройка VLAN на операционной системе routerOS
    0
    К сожалению, иногда в функционале бриджей проскакивал «неуловимый баг». По непонятной причине иногда трафик разных Vlan'ов висящих в одном бридже начинал смешиваться. Т.е. трафик Vlan11 мог «протекать» в Vlan22 и наоборот. В новых версиях вроде, пофиксили, но лично я на всякий случай стараюсь избегать «замыкания» нескольких vlan в общий бридж.
  • Настройка VLAN на операционной системе routerOS
    0
    Немного уточню:
    В старых CCR1009 (из «CCR» только в них) был свитч-чип. После модернизации, в новых версиях CCR1009 свитч-чип убрали. Теперь его нет ни в одном из устройств линейки CCR
  • Настройка VLAN на операционной системе routerOS
    +1
    switch сhip в маршрутизаторах серии CCR отсутствует. Всё делается ресурсами CPU.
  • Настройка VLAN на операционной системе routerOS
    0
    Смешались в кучу вланы, бриджи. Автор малость перемудрил со схемой и недораскрыл тему.
    Возникает вопрос: зачем создавать «br3-trunk», когда vlan-интерфейсы отлично навешиваются прямо на порт «Ether8» («ether8-trunk»)?
  • Dual Wan и особенности реализации NetWatch в MikroTik
    0
    С asterisk, вроде упростили. Для прохода через nat сделали pjsip. Но я его еще не пробовал применять пока. Небыло необходимости.
  • Dual Wan и особенности реализации NetWatch в MikroTik
    0
    «Ну нельзя же делать такой простой и наглядный интерфейс к iptables! Его же любой тупица освоит и мы без работы останемся!»
    То есть да, надо просто представлять себе, как работает линуксовый iptables и стек IP (маршрутизация, NAT и всё такое)

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

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

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

    Пруф на текст
  • Dual Wan и особенности реализации NetWatch в MikroTik
    0
    Можно. К сожалению, далеко не все владеют навыком написания скриптов к микротику. Постоянно встречаю деятелей, которым настройка оборудования сложнее домашнего TP-Linka создает проблемы. От микротика эти люди вообще впадают в шок или истерику. Куда уж им в скрипте результаты анализировать и обрабатывать.
  • Dual Wan и особенности реализации NetWatch в MikroTik
    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. Вот, только когда они это реализуют — неизвестно.
  • Настройка FullMesh сети на Mikrotik через EoIP туннели
    0
    Прямо заинтриговали. В системе несколько областей. В том числе не тупиковых. ASBR взаимодействует с quagga. Всё живет нормально. Возможно дело в правильной настройке ABR, инстансов и Area Ranges?
    За исключением глюка, когда сразу после интенсивной настройки/переконфигурации, требуется рестартовать инстанс, других не попадалось.
    Поделитесь примерами топологии и конфигов при закольцовывании. Можно в личку, поскольку чуть оффтоп.
  • Настройка FullMesh сети на Mikrotik через EoIP туннели
    0
    Немного странный выбор pseudo-wire технологии туннелирования, когда для этого есть IPIP/GRE/L2TP и прочие протоколы точка-точка? Были какие-то проблемы с реализацией OSPF/BGP на линках? Изначально EoIP совсем не для этого предназначен.
    Так любят строить туннели наши «азиатские партнеры» из Индонезии и близлежащих к ней стран. Там некоторые вообще как дети — набриджуют EoIP туннелей в огромный broadcast-домен и чего-то с ним шаманят, извращаются…
  • Настройка FullMesh сети на Mikrotik через EoIP туннели
    0
    Таким образом нас перестали пугать технические работы у провайдера, а также периодические проблемы с проходимостью GRE пакетов по определенным направлениям

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

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