Побег из Vlan. Баг? Хак?! Фича… Или о пользе чтения документации
Снова рискую огрести минусов за капитанство, но все же считаю нижеприведенную инфу полезной. В конце-концов капитанство — не самая низшая ступень. Что бы говорить трюизмы, надо их как минимум знать. И если в быту и в рамках банальной эрудиции это может любой за исключением детей сильно-младшего дошкольного возраста (за летом придет осень), то в сфере профессиональной до этого еще надо дорасти. Так что гуру под кат могут не смотреть. Ну если только повеселиться, это можно…
Пришлось однажды вашему покорному наблюдать картину, которая дала ему почувствовать то самое — даже капитанство не светит, ибо ничего непонятно.
Понадобилось на один пользовательский, давно не использовавшийся линк повесить один хитрый девайс. Наследство дел давно минувших дней — отсутствие документации, каких-либо пометок на розетках и все такое, ну, вы понимаете. Не беда. Подключим девайс, глянем fdb в ядре на предмет mac-адреса, найдем свич доступа, на нем посмотрим все ту же fdb, определим порт и все как надо настроим. Mac известен, девайс подключен, трафик для learning девайс точно обеспечит и «дотянуться» до ядра он должен — ищем.
В ядре (catalyst 35xx)
sh mac address-table | i xxxx.xxxx.xxxx
Но странное дело, mac светится сразу в нескольких Vlan плюсом к тому, в котором как бы должен. Да, на девайсе они действительно подняты (tagged), но порт на свиче доступа (AT-85xx) настроен как untagged. И как tagged он ни в один Vlan не входит. Автор интуитивно (и очень зря, мануалы надо читать!) ожидал от такого «чистого» untagged порта поведения, аналогичного в cisco, когда
switchport mode access
switchport access vlan xxx
Но, как я уже заметил — зря. Дальнейшие изыскания с тестовой машинкой показали, что тэгированный трафик на untagged порт спокойно принимается (при наличии соотв. Vlan-а на свиче, ессно) и форвардится (назад ессно нет).
Занеся на тестовой машине в arp-таблицу статическую запись для некоего IP из управляющего Vlan и подняв его на сетевой как tagged спокойно удалось нафлудить туда чем-то бОльшим, чем arp-запросами. Это плохо.
Ситуацию прояснил мануал. Оказывается, это совершенно нормальное поведение свича, которое может быть отключено командой
set switch infiltering=yes
Правда, в мануале было написано (если я не попутал), что по дефолту команда эта есть и наблюдаемое на практике поведение должно быть отключено. Но не суть. Кстати, через веб-гуи команда недоступна (вот она, причина невежества).
И как оказалось, реальная дефолтовая настройка свича более соответсвует стандарту 802.1Q, чем информация о дефолтовом значении параметра из мануала.
8.6.2 Ingress
Each Port may support an Enable Ingress Filtering parameter. A frame received on a Port that is not in the member set (8.8.9) associated with the VID shall be discarded if this parameter is set. The default value for this parameter is reset, i.e., Disable Ingress Filtering, for all Ports. Any Port that supports setting this parameter shall also support resetting it. The parameter may be configured by the management operations defined in Clause 12.
- мелочи жизни
- капитанство
Ingress Filtering
Ingress Filtering — метод предотвращения атак типа IP spoofing, при котором исходящий трафик проверяется на соответствие допустимым IP-адресам. Процесс фильтеринга выполняется на маршрутизаторах или брандмауэрах, которые отбрасывают пакеты с поддельными или неправильными IP-адресами.
IP spoofing — это метод обмана, при котором злоумышленник подделывает свой IP-адрес, чтобы выглядеть как другой компьютер или скрыть свое местоположение. Ingress Filtering помогает защитить сеть от атак, которые используют подделанные IP-адреса для обхода фильтров или скрытия своего источника.
Ingress-контроллер: что это и как выбрать
Эта инструкция — часть курса «Первые шаги в Kubernetes».
Смотреть весь курс
Kubernetes — достаточно сложная для понимания вещь, даже сами авторы это признают. В этой статье мы попытаемся простым языком объяснить, что такое Ingress-контроллер и для чего он нужен.
Начнем с того, что в Kubernetes есть целых два типа сущностей. Первый — сам Ingress, некоторый набор правил, позволяющий трафику извне достичь сервисов внутри кластера. Второй — Ingress-контроллер, представляющий собой ни что иное, как pod с запущенным приложением-контроллером. Здесь стоит оговориться, что отдельно эти два типа сущностей бесполезны.
На ум приходит аналогия с автомобилем. Ingress — это как автомобиль со снятым двигателем, а Ingress-контроллер — тот самый двигатель. Так что если вы создадите Ingress без установленного контроллера, то само собой ничего работать не будет.
Работая вместе, Ingress и Ingress-контроллер позволяют создать единую точку входа для трафика и выполняют одновременно роль прокси и балансировщика нагрузки, работая на 7 уровне сетевой модели OSI.
Итак, основная задача выбора Ingress-контроллера лишь в том, какое именно приложение будет разруливать весь трафик. В идеале различные Ingress-контроллеры должны работать одинаково по спецификации, но на практике все же есть различия. Возвращаясь к автомобильной аналогии, двигатели бывают разного типа: атмосферные, компрессорные, турбированные и даже электрические.
Важно понимать, что Ingress-контроллер не отменяет необходимость во внешнем балансировщике нагрузки, он лишь добавляет дополнительный уровень маршрутизации и большую гибкость в распределении трафика.
Какие существуют Ingress-контроллеры
Условно все Ingress-контроллеры можно поделить на две группы.
Первая группа — специфичные приложения, рассчитанные на работу с трафиком каких-либо экосистем, например, Citrix ingress controller. Эта штука предназначена для работы с Citrix ADC — комплексным решением по доставке приложений для исполнения на bare-metal, а также внутри контейнеров и виртуальных машин.
Точно такое же специфичное решение — AKS Application Gateway Ingress Controller. Его назначение — балансирование рабочих нагрузок, размещенных в Azure, о чем нам намекают в названии AKS (Azure Kubernetes Service). Многие крупные провайдеры облачной инфраструктуры создают свои решения и предлагают их в рамках использования определенной экосистемы. Например, F5 BIG-IP Container Ingress Services for Kubernetes создавался для работы с виртуальными серверами F5 BIG-IP.
Переходим ко второй группе, где у нас находятся универсальные Ingress-контроллеры. Их достаточно много, но можно выделить несколько, базирующихся на одном и том же ПО, например, на Envoy:
- Gloo — Open Source-контроллер, умеющий работать шлюзом API;
- EnRoute — API-шлюз, умеющий работать контроллером трафика;
- Contour — еще один контроллер входящего трафика.
Особняком стоят Ingress-контроллеры, заточенные под использование в паре с определенным ПО:
- HAProxy Ingress и Voyager — контроллеры входящего трафика для HAProxy;
- NGINX Ingress для Kubernetes — работает с веб-сервером NGINX;
- Traefik Kubernetes Ingress — контроллер для Traefik.
Все перечислять не будем. Из вышесказанного можно сделать однозначный вывод о том, что вопрос выбора Ingress-контроллера может быть решен, если какое-либо ПО уже есть и оно готово к рабочим нагрузкам соответствующего контроллера.
Взглянем чуть более детально, какие контроллеры чаще всего используют.
Наиболее используемый Ingress-контроллер
Прежде чем набивать шишки, всегда проще посмотреть на чужой опыт и сделать выводы. На момент написания этой статьи в подавляющем большинстве источников на роль Ingress-контроллера рекомендуют использовать nginx-ingress. Причина проста: разработкой и поддержкой этого контроллера занимаются разработчики Kubernetes. Длительный опыт использования, а также масса документации и учебных материалов играют существенную роль в «боевой» эксплуатации. Так что вряд ли вы столкнетесь с нерешаемыми проблемами.
Дабы исключить всякую путаницу: существует еще и NGINX Ingress для Kubernetes, продукт от NGINX Inc (ныне компания поглощена F5 Networks). В отличие от nginx-ingress у этого продукта есть еще и платная версия, реализованная на NGINX Plus.
Чуть меньшую популярность завоевал HAProxy Ingress. Достаточно производительный и гибкий, с понятной документацией и обширным комьюнити в Slack и на StackOverflow, этот контроллер однозначно заслуживает внимания. Определенную долю рынка занимает Traefik Kubernetes Ingress и Kong для Kubernetes, также основанный на NGINX.
Критерии выбора
Прежде чем сделать выбор, стоит задать несколько важных вопросов:
- Нужна ли сейчас интеграция различных протоколов, таких как TCP / UDP / gRPC? Может ли возникнуть ситуация, когда она потребуется?
- Требуются ли дополнительные фичи, такие как канареечные релизы?
- Будут ли задействованы возможности API-шлюза или достаточно штатных средств?
- Нужна ли коммерческая поддержка?
Эти простые вопросы позволят сходу отсечь варианты, когда наличие дополнительных возможностей потребует больших вложений, но эти возможности не будут востребованы.
Следующий вопрос, который важен для принятия решения, — о производительности. Получить на него ответ можно будет либо эмпирическим путем, либо основываясь на уже существующих научных исследованиях.
В качестве примера приведем научную публикацию «Исследование производительности различных имплементаций Ingress-контроллеров в кластере Kubernetes», основанную на проведенных исследованиях в Белорусском государственном университете информатики и радиоэлектроники (Шуляк А.В., Савенко А.Г.). Получившиеся выводы весьма интересны и показательны. Выяснились следующие факты:
- Ingress-контроллеры, построенные на HAProxy, показывают лучшую производительность (число запросов в секунду) и наименьшую утилизацию CPU.
- Ingress-контроллеры, построенные на базе Traefik, создают наименьшие задержки (latency) при обработке запросов.
- Ingress-контроллеры на базе NGINX работают медленнее всего без дополнительных модификаций, но при наличии таковых могут вполне конкурировать с вышеперечисленными решениями.
Заключение
Процесс выбора Ingress-контроллера в большинстве случаев зависит от решаемых задач и требований к поддержке дополнительных функций. Практически все существующие контроллеры способны решать простые задачи, так что выбор можно сделать в пользу наиболее простого и хорошо задокументированного варианта.
Если же у вас высоконагруженные системы, следует большее внимание уделить производительности решения, а также наличию коммерческой поддержки. Так вы минимизируете возможные простои и не будете тратить время на глубокое погружение в особенности используемой системы.
Готовые кластеры Kubernetes: сравниваем решение с self-hosted
MikroTik.by
For every complex problem, there is a solution that is simple, neat, and wrong.
- Список форумовФорум по операционной системе MikroTik RouterOSМаршрутизация, коммутация
- Поиск
ограничение трафика при условии, что шлюз это роутер перед mikrotik’ом
RIP, OSFP, BGP, MPLS/VPLS
4 сообщения • Страница 1 из 1
Ziko Сообщения: 3 Зарегистрирован: 22 фев 2023, 16:43
ограничение трафика при условии, что шлюз это роутер перед mikrotik’ом
Сообщение Ziko » 23 фев 2023, 08:58
Есть существующая сеть с роутером L3, который получает интернет и занимается маршрутизацией vlan’ов и раздачей DHCP. За роутером стоит коммутатор L3, и уже за ним идут коммутаторы L2. В разрыв между роутером и первым коммутатором ставлю mikrotik, с тем условием, что хочу переложить на него функции DHCP и ограничение скорости доступа в интернет для хостов.
Для теста создал на роутере vlan и на этом интерфейсе забил IP 10.10.118.1 будет выступать шлюзом. Дальше на mikrotik тоже создал такой же vlan, дал ему адрес 10.10.118.250, поднял DHCP которое задает шлюз хостам 10.10.118.1. Создал бридж в который запихнул этот vlan и 2 порта. Первый транковый порт смотрит на роутер, второй транковый на коммутатор. С этим все хорошо, хосты получают ip адреса, видят остальные доступные для них vlan’ы и ходят в интернет. Но проблема в том, что я не могу ограничить скорость доступа в интернет.
Попробовал маркировать для этого трафик но mikrotik его не видит. И тут у меня 2 варианта: 1 я не то делаю, что скорее всего, потому что не хочется верить, что mikrotik на это не способен. 2 mikrotik не маркирует пакеты и не ограничивает скорость хостам, потому что не является для них шлюзом.
Подскажите пожалуйста куда копать. С mikrotik’ом столкнулся второй раз в жизни, в первый была очень простая задача по сравнению с этой.
# RouterOS 6.48.6 # model = CRS317-1G-16S+ /interface bridge add admin-mac=18:FD:74:0F:05:EE auto-mac=no dhcp-snooping=yes frame-types=\ admit-only-vlan-tagged ingress-filtering=no name=B1 vlan-filtering=yes /interface vlan add interface=B1 name=NET vlan-id=22 add interface=B1 name=TT vlan-id=118 /interface lte apn set [ find default=yes ] ip-type=ipv4 use-network-apn=no /interface wireless security-profiles set [ find default=yes ] supplicant-identity=MikroTik /ip pool add name=117 ranges=10.10.117.1-10.10.117.220 add name=118 ranges=10.10.118.2-10.10.118.249 /ip dhcp-server add add-arp=yes address-pool=118 interface=TT lease-time=1d10m name=TT-118 /port set 0 name=serial0 /queue tree add disabled=yes max-limit=20M name=Download parent=global /queue type add kind=pcq name=pcq-download-5M pcq-classifier=dst-address pcq-rate=5M add kind=pcq name=pcq-upload-5M pcq-classifier=src-address pcq-rate=5M add kind=pcq name=download-5Mb pcq-burst-rate=2M pcq-burst-threshold=768k \ pcq-burst-time=32s pcq-classifier=dst-address pcq-rate=1M add kind=pcq name=upload-5M pcq-burst-rate=2M pcq-burst-threshold=768k \ pcq-burst-time=32s pcq-classifier=src-address pcq-rate=1M /queue simple add max-limit=100M/100M name=1 queue=ethernet-default/ethernet-default \ target=TT add dst=B1 max-limit=20M/20M name=2 packet-marks=QS-20M parent=1 queue=\ default/default target=TT /routing bgp template set default disabled=no output.network=bgp-networks /routing ospf instance add disabled=no name=default-v2 /routing ospf area add disabled=yes instance=default-v2 name=backbone-v2 /interface bridge filter # in/out-bridge-port matcher not possible when interface (TT) is not slave add action=mark-packet chain=forward in-interface=TT new-packet-mark=QS-20M-B \ out-bridge=B1 /interface bridge port add bridge=B1 frame-types=admit-only-vlan-tagged ingress-filtering=no \ interface=sfp-sfpplus3 add bridge=B1 frame-types=admit-only-vlan-tagged ingress-filtering=no \ interface=sfp-sfpplus1 /interface bridge settings set use-ip-firewall=yes use-ip-firewall-for-vlan=yes /ip neighbor discovery-settings set discover-interface-list=!dynamic /ip settings set max-neighbor-entries=8192 /ipv6 settings set disable-ipv6=yes max-neighbor-entries=8192 /interface bridge vlan add bridge=B1 tagged=B1,sfp-sfpplus1,sfp-sfpplus3 vlan-ids=118 add bridge=B1 tagged=B1,sfp-sfpplus1,sfp-sfpplus3 vlan-ids=22 /interface ovpn-server server set auth=sha1,md5 /ip address add address=10.10.31.249/23 disabled=yes interface=NET network=10.10.30.0 add address=10.10.118.250/24 interface=TT network=10.10.118.0 /ip dhcp-client add disabled=yes interface=ether1 /ip dhcp-server network add address=10.10.118.0/24 dns-server=8.8.8.8,8.8.4.4 gateway=10.10.118.1 /ip firewall address-list add address=10.10.118.0/24 list=TT-118 /ip firewall filter add action=accept chain=input protocol=icmp add action=accept chain=forward protocol=icmp add action=accept chain=input connection-state=established,related add action=accept chain=forward connection-state=established,related add action=drop chain=input connection-state=invalid add action=drop chain=forward connection-state=invalid add action=drop chain=input disabled=yes in-interface=ether1 add action=accept chain=forward disabled=yes in-interface=!ether1 \ out-interface=ether1 add action=drop chain=forward /ip firewall mangle add action=mark-packet chain=forward in-interface=B1 new-packet-mark=QS-20M \ out-interface=TT passthrough=no src-address-list=TT-118 add action=mark-packet chain=forward dst-address-list=TT-118 in-interface=TT \ new-packet-mark=QS-20M out-interface=B1 passthrough=no /ip service set telnet disabled=yes set ftp disabled=yes set www disabled=yes set ssh disabled=yes set api disabled=yes set api-ssl disabled=yes /system clock set time-zone-name=Europe/Minsk /system identity set name=RouterOS /system package update set channel=long-term /system routerboard settings set boot-os=router-os