LINUX.ORG.RU
ФорумAdmin

Как разобраться с современным сетевым стеком линукса?

 , , , ,


4

9

Классическая схема сетевого стека линукса ( https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg ) и даже расширенная документация ( http://linux-ip.net/pages/diagrams.html http://www.oreilly.com/openbook/linag2/book/ch09.html http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:networking:traffic... https://www.slideshare.net/hugolu/the-linux-networking-architecture https://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html https://www.ietf.org/rfc/rfc2373.txt http://lartc.org/lartc.htm ) не даёт ответов на большинство вопросов (как и документация в ядре) из-за огромного количества подсистем, которые разрослись внутри себя до такого уровня, что могут выполнять (в ограниченном объёме) часть функций других подсистем. Также не понятно, в каком месте цепочек происходят те или события (точки входа) этих подсистем, т.е. реальная диаграмма будет больше раз в 10, чем та, что представлена в вики, если мы задействуем весь функционал.

Банально:
1. В каких местах происходят LSM-хуки и какие модули netfilter (а может и других подсистем) умеют понимать их метки на пакетах?
2. Полная документация о работе ICMPv4, ICMPv6, RARP, ARP как минимум. Не стандарт, а как это работает в линуксе. И в каких местах цепочек.
3. Что с ipv6? Его вкосячили почти во все подсистемы, при этом толком нет никакой вменяемой документации. Даже к части модулей нетфильтра нет, не говоря уже об остальном стеке.
4. Все точки «разрыва» для NF_QUEUE в цепочках?
5. Что отрабатывает, а что нет при работе с RAW-сокетами (причём как IP RAW, так и Ethernet RAW)?
6. Куда в цепочки встраивается BPF?
7. Что за хрень с qdisc (tc)? Кроме шейпинга трафика, он может инспектировать трафик, маршрутизировать, зеркалировать его, менять любые куски по правилам, чего только он не может. Причём в обход netfilter вообще (и, возможно, других подсистем).
8. В каких именно местах цепочки происходят хуки IPSec, какое взаимодействие с другими подсистемами? И при локальной передаче и при форвардинге. Например, может ли быть такое, что из-за определенных настроек qdisc через IPSec трафик не пойдёт?
9. NAT64 делается аж 5-ю методами (1 в ядре, 4 юзерспейс-метода)
10. Аналогично, например, iproute2, ebtables, netfilter, qdisc умеют делать NAT (хотя только netfilter полноценный).
12. Минимум 3 реализации мостов. И как они интегрируются с ebtables, iproute2, netfiler, qdisk и прочими? Linux bridges, OVS, реализация через жопу на ebtables. Ну и софтварные стеки, а также bpf.
13. iproute2 умеет как минимум nat, работа с arp (neigh), маршрутизацию по источнику, по политикам, создавать хренову тучу туннелей (VLAN, GVRP+MVRP, VLAN Q-in-Q, VXLAN, GRE, IPv6GRE, IPv6-IPv6 (с возможость капсуляции в UDP), IPv4-IPv4 (с возможость капсуляции в UDP), туннелирование ipv6 через ipv4 и наоборот, интеграция с ipsec, l2tp, l2tpv3), токены на интерфейсах, MPLS, мирроринг, мосты L2, бондинг (включая LACP), DCCP, SCTP, TIPC, HSR. Что дублирует функционал многих модулей ядра, а также, ebtables, netfilter и ряда userspace приложений. И не совсем понятно, как будет работать стек, скажем, с MPLS в плане прохождения через все цепочки.
14. cgroup namespaces. Как оно вообще работает со всем вышеперечисленным?
15. Linux Server (балансер)?
16. Работа TCP/UDP поверх RDS (Infiniband)? Там же свой стек.

В бздах та же фигня?



Последнее исправление: katulu (всего исправлений: 1)

Ответ на: комментарий от katulu

Если честно, то я не могу понять, что ты имеешь ввиду.

itn ★★★
()
Ответ на: комментарий от aureliano15

Имхо, проще всего разобраться, поставив на разных узлах wireshark или tcpdump и изучив трафик.

Тогда уж проще читать исходники. Вы понимаете, сколько надо провести экспериментов, чтобы восстановить всю логику работы всех кусков стека? Мало того, предсказать и отработать редкие ситуации, скорее всего, не выйдет.

katulu
() автор топика
Ответ на: комментарий от katulu

Имхо, проще всего разобраться, поставив на разных узлах wireshark или tcpdump и изучив трафик.

Тогда уж проще читать исходники.

И исходники тоже. Но одними исходниками, без сниффера, - не обойтись. Это как читать исходники без отладчика.

Вы понимаете, сколько надо провести экспериментов, чтобы восстановить всю логику работы всех кусков стека? Мало того, предсказать и отработать редкие ситуации, скорее всего, не выйдет.

Безусловно. Но, боюсь, подробной документации по всем возможным программам и их разнообразным реализациям просто нет. Придётся выискивать доку на сайтах разработчиков каждой программы и в багепортах. Но и там отдельные моменты могут остаться не отражёнными, если интересует подробнейшая детализация.

aureliano15 ★★
()
Ответ на: комментарий от katulu

А тебе все это нужно разом в одной системе ?

ipv4 & ipv6 стоят рядом и особо не пересекаются.

Собственно, а что ты хотел от системы которая развивается уже больше 20 лет ? Чистый, прозрачный код с единственно правильной реализацией каждой функции ?

ipchains сменил iptables, потом появился ebtables & ip6tables.

Светлые головы говорят - переходите на nft и сможете забыть про ebtables, iptables и ip6tables, а по факту имеем все вместе.

Про icmpv4/v6 доку я быстро нашел, когда делал пинговалку для мониторинга.

А еще есть такая проблема - если есть устоявшийся стандарт, то документацию пишут минимальную, т.к. считают, что все знают основы. А без знания этих основ такая документация кажется лютым #$%^&*(.

Это хорошо, что tc отдельно от netfilter. Можно отделить мух от котлет. tc умеет пользовать iptables, т. ч. связку тоже можно делать.

ebtables - это не реализация моста, это лишь возможность фильтрации в нем. А еще трафик моста можно обрабатывать в netfilter.

С BPF только одна проблема - нужно знать на каком типе линка он будет использоваться. Сделать фильтр для raw-IP штатными средствами не так просто.

iproute2/ip nat - имеет очень узкое применение. Если ты понимешь, что оно тебе нужно - используй его.

Собственно iproute2/ip - это попытка сделать всю базовую настройку сети одной утилью. Теоретически ip + nft + tc должны решать все задачи настройки сети.

cgroups - очень полезная вещь!

ipvs - достаточно специфичная вещь.

ip еще можно через scsi передавать.

А если посмотреть на ATM, то сначала начинает тошнить, как от всего что придумали телефонисты, а потом хочется напиться, т.к. там без пол-литра не разобраться с самими базовыми технологиями :)

vel ★★★★★
()
Ответ на: комментарий от vel

А если посмотреть на ATM, то сначала начинает тошнить, как от всего что придумали телефонисты, а потом хочется напиться, т.к. там без пол-литра не разобраться с самими базовыми технологиями :)

Вы ещё ISDN, ADSL и GPON не видели. Это вообще жопа в чистом виде.

У Вас есть джаббер или телеграм?

katulu
() автор топика
Ответ на: комментарий от katulu

gpon и adsl - это замаскированный atm, со всеми вытекающими последствиями. В трезвом виде туда соваться нельзя :)

vel ★★★★★
()
Ответ на: комментарий от vel

Это ATM с целой кучей надстроек, подложек и контролирующих их сессии, сеансы и прочее звезданутых протоколов. Хуже может быть только беспроводной телеком.

katulu
() автор топика

Как разобраться с современным сетевым стеком линукса?

Нырнуть в сырцы. Иначе никак.

Deleted
()
Ответ на: комментарий от vel

Так что там с прямой возможность связи? Можете в профиле указать контакты или запросить мои (по конкретному мессенджеру).

katulu
() автор топика
Ответ на: комментарий от katulu

Прости, а что ещё остаётся? Человек пишет код, но не документирует его (исключением являются редкие комментарии и документация к некоторым функциям). Остаётся два варианта:

  1. Почитать книгу кого-то по этой теме. К сожалению, книги по сетевому стеку в ядре безнадёжно устарели из-за тонн рефакторинга и разросшегося функционала.
  2. Читать код.

Посмотреть, по Kconfig и Makefile, какие опции собирают что. Разобраться, как всё это связывается и работает вместе. Спрашивать на mailing list'ах интересующие вопросы.

zuzzas
()
Ответ на: комментарий от katulu

джабер есть, только я им не пользуюсь :)

vel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.