Это как раз базовое поведение\правило stateful firewall: первый пакет нового соединения проходит через ruleset до первого совпадения. После того, как соединение попадает в состояние established или related, дальнейшие пакеты обрабатываются через conntrack и, как правило, матчятся ранним правилом accept/drop.
Я так правильно и не смог смоделировать нагрузку, но идея была такая: при большом ruleset и потоке новых соединений: пакеты ещё не попали в established и вынуждены проходить через линейный перебор правил. В такой ситуации latency обработки может заметно расти по сравнению с моделями, где используются более эффективные структуры (например, sets или хэш-таблицы).
Не совсем корректно считать, что это просто два или три фронтенда к netfilter. Netfilter даёт только хуки, а алгоритм обработки правил — разный. В iptables — линейный проход по цепочке: 10k правил = до 10k сравнений на пакет. Если используется линейный мод. В nftables — правила компилируются в структуры данных (sets/maps)
Ну и для полноты картины, IPVS вообще живёт чуть в стороне от этой истории и изначально опирается на хэш-таблицы и stateful-модель, поэтому там поведение ближе к O(1) без всяких оптимизаций поверх списков.
Так что ядру как раз не всё равно: либо оно делает 10k проверок подряд, либо один хэш-lookup.
Из ОС могу сказать, что использовалась alt linux p10 с ядром 5.15, все никак не обновимся на 6+ — как там будут изменения уже не знаю
Я думаю на этот вопрос знают ответ только мейнтейнеры kubernetes. Либо считают, что часть функционала еще сырая и релизить рано или как обычно тянут долго с выпуском. Вот что еще накопал
IPVS, к слову, тоже обеспечивает сложность O(1) и на практике показывает очень достойную производительность. Поэтому при желании можно так же легко провести сравнение линейного nftables с IPVS и вынести это в громкий заголовок.
При этом API у iptables, nftables и IPVS принципиально отличаются, и с точки зрения удобства работы они тоже ощущаются по-разному. Где-то проще декларативно описывать правила, где-то удобнее оперировать сущностями балансировки — и это напрямую влияет на эксплуатацию.
Домашняя сеть у меня — 192.168.88.0/24, а для остальных нужд используется 192.168.89.0/29. За счёт маски /23 обе подсети автоматически попадают под правило. В результате не нужно прописывать NAT точечно для каждой из них — всё, что выходит из этих диапазонов, автоматически проходит через masquerade.
Это удобно, потому что при добавлении нового интерфейса, VLAN или туннеля легко забыть добавить отдельное правило. Потом начинается классическое «почему ничего не работает»
Если я правильно все понимаю, но поправьте если ошибаюсь
Тут нам нужен только NAT для пакетов, которые уходят от прокси на публичный адрес AWG. В этом случае можно оставить masquerade для src-address=172.18.0.0/30.
Для трафика wg interface → proxy container NAT не требуется.
Также можно упомянуть, что MikroTik умеет довольно удобно автоматизировать работу со списками адресов. Через IP → DNS → Static можно создавать правила, которые по RegExp и CNAME динамически формируют address-list. Далее эти списки легко тегировать в mangle по имени и отправлять соответствующий трафик в туннель.
Иногда это оказывается очень полезно — особенно когда нужно маршрутизировать трафик к CDN, где десятки или сотни CIDR-блоков
Не совсем конечно удачный пример привел, ничего в голову нормального не лезло, а только такое. Но на всякий убрал use_backend и оставил acl, как реализация плохого примера и что так делать не надо
Тут на самом деле не важно сколько админов или devops`ов у вас есть. Этот подход можно использовать и на 3-4 человек в кластере. Главное удобство —доступ выдается централизовано без генерации сертификатов руками/скриптами или созданием токенов от svc. И также быстро отзывается если кому то надо одним глазиком подсмотреть, а чо там у вас происходит
У нас не только devops'ы ходят в кластер, а еще: разрабы, подрядчики, заказчики и тд. Список в общем большой. Мне кажется уже прошли те времена когда девопсы единственные кто туда заглядывают
Кластеров у нас очень много. Но не все конечно же используют этот подход. Пока что самый большой насчитывает около 13 команд и примерно 40 пользователей для которых нужно вести разграничение прав по namespace и глубины видимости ресурсов. Самая большая неудобность - kubectl, без надстройки не умеет работать пока что из коробки с OIDC и это тормозит многих.
Я постарался изложить материал максимально понятно. Если где-то не хватает деталей, любой фрагмент можно дополнительно разобрать с помощью LLM — до того уровня глубины, который вам нужен.
Статья изначально ориентирована не на формат, как установить, а на тех, кто уже всё развернул, но не до конца понимает, зачем столько тумблеров, что именно крутить и к каким последствиям это приведёт.
Я как раз для этого и оставил дисклеймер вначале, что истины быть не может, а только правдоподобность. А в тему LLM — может такой иногда скрипт написать, что там без 100г не разберешься, проще по старинке нагуглить
Я рассказал про CNI в общем виде, но не затрагиваю eBPF-вариации их работы. В статье рассматривается классическая модель сетевого стека Linux и то, как CNI в неё встраиваются на уровне namespaces, veth, routing, iptables/nfstables и т.д. — то есть без изменения логики обработки пакетов в ядре.
CNI на eBPF (Cilium, часть режимов Calico) — это отдельный класс решений, которые вмешиваются в стандартный путь пакета и фактически переопределяют его. Да, там возможны неожиданные эффекты вроде дропа VRRP, и без знания внутренностей CNI иногда не обойтись.
Но это осознанно вынесено за рамки материала, потому что это уже не про «как работает сеть в Linux», а про «как конкретный CNI переписывает её поведение».
Это как раз базовое поведение\правило stateful firewall: первый пакет нового соединения проходит через ruleset до первого совпадения. После того, как соединение попадает в состояние established или related, дальнейшие пакеты обрабатываются через conntrack и, как правило, матчятся ранним правилом accept/drop.
Я так правильно и не смог смоделировать нагрузку, но идея была такая: при большом ruleset и потоке новых соединений: пакеты ещё не попали в established и вынуждены проходить через линейный перебор правил. В такой ситуации latency обработки может заметно расти по сравнению с моделями, где используются более эффективные структуры (например, sets или хэш-таблицы).
Не совсем корректно считать, что это просто два или три фронтенда к netfilter. Netfilter даёт только хуки, а алгоритм обработки правил — разный. В iptables — линейный проход по цепочке: 10k правил = до 10k сравнений на пакет. Если используется линейный мод. В nftables — правила компилируются в структуры данных (sets/maps)
Ну и для полноты картины, IPVS вообще живёт чуть в стороне от этой истории и изначально опирается на хэш-таблицы и stateful-модель, поэтому там поведение ближе к O(1) без всяких оптимизаций поверх списков.
Так что ядру как раз не всё равно: либо оно делает 10k проверок подряд, либо один хэш-lookup.
Из ОС могу сказать, что использовалась alt linux p10 с ядром 5.15, все никак не обновимся на 6+ — как там будут изменения уже не знаю
Я думаю на этот вопрос знают ответ только мейнтейнеры kubernetes. Либо считают, что часть функционала еще сырая и релизить рано или как обычно тянут долго с выпуском. Вот что еще накопал
IPVS, к слову, тоже обеспечивает сложность O(1) и на практике показывает очень достойную производительность. Поэтому при желании можно так же легко провести сравнение линейного nftables с IPVS и вынести это в громкий заголовок.
При этом API у iptables, nftables и IPVS принципиально отличаются, и с точки зрения удобства работы они тоже ощущаются по-разному. Где-то проще декларативно описывать правила, где-то удобнее оперировать сущностями балансировки — и это напрямую влияет на эксплуатацию.
В стандартный data plane linux если можно так обозвать, ведь есть еще eBPF который тоже может управлять сетевым стеком
Спасибо, что остаетесь на связи и не можете дочитать до конца, а только первые пару строк. У nftables преимущество не только в О(1) поиске есть
Я в итоге сделал так:
Домашняя сеть у меня —
192.168.88.0/24, а для остальных нужд используется192.168.89.0/29. За счёт маски/23обе подсети автоматически попадают под правило. В результате не нужно прописывать NAT точечно для каждой из них — всё, что выходит из этих диапазонов, автоматически проходит через masquerade.Это удобно, потому что при добавлении нового интерфейса, VLAN или туннеля легко забыть добавить отдельное правило. Потом начинается классическое «почему ничего не работает»
Если я правильно все понимаю, но поправьте если ошибаюсь
Тут нам нужен только NAT для пакетов, которые уходят от прокси на публичный адрес AWG. В этом случае можно оставить
masqueradeдляsrc-address=172.18.0.0/30.Для трафика
wg interface → proxy containerNAT не требуется.Также можно упомянуть, что MikroTik умеет довольно удобно автоматизировать работу со списками адресов. Через IP → DNS → Static можно создавать правила, которые по
RegExpиCNAMEдинамически формируютaddress-list. Далее эти списки легко тегировать вmangleпо имени и отправлять соответствующий трафик в туннель.Иногда это оказывается очень полезно — особенно когда нужно маршрутизировать трафик к CDN, где десятки или сотни CIDR-блоков
Ну например сменить днс - логично же
Как у нас обычно принято - документацию начинают читать тогда, когда уже все сломали и обвинил всех в своей рукожопости
Не совсем конечно удачный пример привел, ничего в голову нормального не лезло, а только такое. Но на всякий убрал use_backend и оставил acl, как реализация плохого примера и что так делать не надо
Тут на самом деле не важно сколько админов или devops`ов у вас есть. Этот подход можно использовать и на 3-4 человек в кластере. Главное удобство —доступ выдается централизовано без генерации сертификатов руками/скриптами или созданием токенов от svc. И также быстро отзывается если кому то надо одним глазиком подсмотреть, а чо там у вас происходит
У нас не только devops'ы ходят в кластер, а еще: разрабы, подрядчики, заказчики и тд. Список в общем большой. Мне кажется уже прошли те времена когда девопсы единственные кто туда заглядывают
Кластеров у нас очень много. Но не все конечно же используют этот подход. Пока что самый большой насчитывает около 13 команд и примерно 40 пользователей для которых нужно вести разграничение прав по namespace и глубины видимости ресурсов. Самая большая неудобность - kubectl, без надстройки не умеет работать пока что из коробки с OIDC и это тормозит многих.
Спасибо и правда опечатка закралась, поправил
Я постарался изложить материал максимально понятно. Если где-то не хватает деталей, любой фрагмент можно дополнительно разобрать с помощью LLM — до того уровня глубины, который вам нужен.
Статья изначально ориентирована не на формат, как установить, а на тех, кто уже всё развернул, но не до конца понимает, зачем столько тумблеров, что именно крутить и к каким последствиям это приведёт.
Я как раз для этого и оставил дисклеймер вначале, что истины быть не может, а только правдоподобность. А в тему LLM — может такой иногда скрипт написать, что там без 100г не разберешься, проще по старинке нагуглить
Видимо, местами получилось слишком аккуратно — буду разбавлять живыми шероховатостями, чтобы текст меньше походил на синтетический.
Спасибо за комментарий, обновил команды.
Я рассказал про CNI в общем виде, но не затрагиваю eBPF-вариации их работы. В статье рассматривается классическая модель сетевого стека Linux и то, как CNI в неё встраиваются на уровне namespaces, veth, routing, iptables/nfstables и т.д. — то есть без изменения логики обработки пакетов в ядре.
CNI на eBPF (Cilium, часть режимов Calico) — это отдельный класс решений, которые вмешиваются в стандартный путь пакета и фактически переопределяют его. Да, там возможны неожиданные эффекты вроде дропа VRRP, и без знания внутренностей CNI иногда не обойтись.
Но это осознанно вынесено за рамки материала, потому что это уже не про «как работает сеть в Linux», а про «как конкретный CNI переписывает её поведение».