All streams
Search
Write a publication
Pull to refresh
47
0

Сисадмин Linux (RHCE), Windows (MCSE), Mikrotik

Send message

По сути, там нечего писать. Порты объединяются мостом. Если чип поддерживает аппаратную разгрузку, то интерфейсы получать статус H. Если делать несколько мостов, а группа коммутации только одна, то тот, что с большим числом интерфейсов становится "мастером" с аппаратной разгрузкой, остальные софтовые.

А чем вам так нравятся simple queue? Там и управляемость ниже, разве что настроить проще…
С вашего позволения, могу ли я добавить это в статью?
Ну да, решение само по себе красивое, но в определенных ситуациях не покрывает все случаи.
А откуда у вас взялся маршрут до 10.2.2.0/24? Вы его должны прописать сами, тогда все заработает. Иначе, весь трафик до 10.2.2.0/24 будет завернут и BH.
Встречал такую ситуацию (BeeLine+L2TP):
10.1.1.0/24 — сеть в которой вам выдали адрес в сети провайдера (соответственно и шлюз по умолчанию).
10.2.2.0/24 — сеть L2TP серверов.
В варианте без «вырубки» диапазона, L2TP сервера станут недоступны. Или придется давать до них маршруты руками.
Как не крути, решение в такой ситуации будет не самым изящным при любом раскладе.
Элегантно. При таком решении не очень то и нужно делать правила в Firewall, хотя от проблемы «серых» адресов не поможет. Все равно придется «вырубать» диапазон для провайдера.
knock-knock — хорошая методика и её стоит использовать, не забывая и про другие.
Да, вариант дропать неугодных в RAW лучше по производительности, но целиком перенести правила не выйдет, в RAW нет отслеживания connection-state=new.
Вариант с блокировкой в RAW:
/ip firewall filter
add action=jump chain=forward connection-state=new in-interface-list=ISP jump-target=anti-DDoS
add action=jump chain=input connection-state=new in-interface-list=ISP jump-target=anti-DDoS
add action=return chain=anti-DDoS dst-limit=15,15,src-address/10s
add action=add-src-to-address-list address-list=BAN-DDoS address-list-timeout=1d chain=anti-DDoS
/ip firewall raw
add action=drop chain=prerouting in-interface-list=ISP src-address-list=BAN-DDoS
/ip firewall filter
add action=jump chain=input connection-state=new dst-port=22,8291 in-interface-list=ISP jump-target=anti-BruteForce-3 protocol=tcp
add action=return chain=anti-BruteForce-3 dst-limit=4/1m,1,src-address/1m40s
add action=add-src-to-address-list address-list=BAN-BruteForce-3 address-list-timeout=1d chain=anti-BruteForce-3
/ip firewall raw
add action=drop chain=prerouting in-interface-list=ISP src-address-list=BAN-BruteForce-3
Тут главная цель атаки — исчерпание лимита соединений самого роутера (SYN flood атака). От такой атаки может спасти, но проверить мне пока нечем ;)

Она есть ;) Не разбирался детально с ней, потому пока не знаю как применить.
Работает она довольно просто, с каждого интерфейса (на которые настроили) пытается связаться с облаком Mikrotik. Если удалось, значит на интерфейсе есть интернет.

Да, вот за это мне они и нравятся. При своей цене, конкурентов практически нет. Ближайшие конкуренты значительно дороже.
Пока такой проблемы не встречал, у самого CCR еще нет. А баг репорт делали? Может дело то исправимое?
А если не секрет, чего не хватает RoS и RouterBoard для перехода в категорию «старшего» железа. В «моих» сетях пока почти не возникало потребностей свыше тех, что дает продукция Mikrotik. И модели весьма с неслабым железом тоже есть…
Сегментирование сети (VLAN) и внутренний DNS не относится к задачам роутера

Возможно, что я вас не понял и надо определится с использованием терминов.
Коммутатор (свитч) — работает на L2 уровне, незамысловато гоняя Ethernet фреймы по портам (может иметь простенькие правила, в основном для QoS на основ меток во фреймах). Маршрутизатор (роутер) — Работает на L3 уровне, и уже занимается передачей пакетов из не связанных между собой L2 доменов на основе протоколов L3 (всякие IP и им подобные).
При этом, маршрутизатор чаще всего имеет меньше портов (не надо ему много) и мощные процессор, не исключает работу с VLAN. Коммутатор, напротив, слаб процом, но имеет много портов.
У Mikrotik есть линейка коммутаторов со встроенным, маломощным роутером — CRS125.
В вашей цитате, что вы понимали под сегментацией? Наличие VLAN на маршрутизаторе или коммутаторе? По мне, так это одна задача, но её решение может быть разнесено на разные устройства или решаться на одном.
Все зависит от архитектуры сети.
Если трафик имеет «восходящую» к серверам структуру, а коммутаторы организованы в «дерево», то у вас один мощный маршрутизатор L3, который маршрутизирует между VLAN на самом верху. А на местах у вас относительно дешевые L2, которые организуют сеть. При этом, такая структура плохо работает с P2P обменом между VLAN «одного уровня», трафик будет идти «наверх» по дереву коммутаторов (если у вас такая сеть), там маршрутизироваться и спускаться вниз.
Если строить из L3 коммутаторов, то сильный на «вершине» не нужен, но тот-же CSR125 маршрутизирует на скорости около 1Gb/s только с fastpath. Такая сеть требует VLAN маршрутизации, через который все маршрутизаторы могут найти маршрут к друг другу, и построить маршруты между всеми (OSPF это сделает легко).
Conntrack никак не поможет с SIPs, если ему не расшифровывать сессию. Не комеоческих решений подобного плана мне не известно.
Хороший принцип: дроби сети на меньшие сегменты в рамках разумного. Тут надо находить баланс между расходами на маршрутизацию между сегментами, броадкастовыми штормами в больших сегментах и безопасности в плане ограничения видимости.
Главная проблема, которая может напрягать тот асус в том, что wifi часть забриджена с кабельной. Тут никакие приемущества свитчей не помогут, нужно в явном виде гнать броадкаст от arp, dhcp и других подобных дел в wifi часть, которая такому счастью точно не рада. Изолирование wifi от кабеля (вынеся wifi в отдельный vlan), поможет снизить проблемность сети.
Это и есть костыль. Нет DNS failover. Проблема с IPv6.
Зачем такие огромные сети? Напилить по кабинетам /28 или /27

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity