Простой монитор сетевых интерфейсов Linux, с помощью netlink

    Однажды, в одном из проектов, мне понадобилось организовать строгий и надежный контроль над всеми сетевыми интерфейсами, таблицами маршрутизации, а так же получать нотификации о каких-либо изменениях. Было принято стратегическое решение — не использовать старые-добрые ioctl netdevice (SIOCGIFMETRIC, SIOCSIFNAME и т.п.) или непосредственные вызовы соответствующих утилит (ifconfig, route и т.д.), а найти более современное и болле удобное решение. Оно было найдено — libnetlink. Это библиотека, предоставляющая большое количество методов для коммуникации с ядром, с помощью механизма netlink. Данная библиотека идеально подходила для моих целей, позволяя решить огромное количество задач. К сожалению, у библиотеки оказался не особо удобный и довольно сложный API, требовавший совершать множество непонятных действий. Особого веселья добавляло практически полное отсутствие документации и вообще любых материалов на эту тему.
    Подумав, я решил как следует разобраться в netlink и написать свою библиотеку. В данный момент реализован весь функционал для работы с нотификацией, сетевыми интерфейсами, таблицами маршрутизации, разумеется поддерживаются IPv4 и IPv6. В достаточно скором времени данный проектик будет представлен на суд общественности :) А пока я бы хотел познакомить всех интересующихся с прекрасным миром netlink, на примере простого монитора сетевых интерфейсов.

    Что такое netlink?

    Итак, netlink представляет удобный собой способ коммуникации между юзерспейсом и ядром Linux. Коммуникация осуществляется с помощью обычного сокета, с использованием особого протокола — AF_NETLINK.
    Netlink позволяет взаимодействовать с большим количеством подсистем ядра — интерфейсы, маршрутизация, фильтр сетевых пакетов. Кроме того, можно общаться со своим модулем ядра. Разумеется в последнем должна быть реализована поддержка такого способа коммуникации.
    Каждое сообщение netlink представляет собой заголовок, представленный структурой nlmsghdr, а так же определенного количества байт — «полезной нагрузки» (playload). Данная «нагрузка» может представлять собой какую либо структуру, либо же просто RAW данные. Сообщение, во время доставки, может быть разбито на несколько частей. В таких случаях каждый следующий пакет помечается флагом NLM_F_MULTI, а последний флагом NLMSG_DONE. Для разбора сообщений имеется целый набор макросов, определенный в заголовочных файлах netlink.h и rtnetlink.h

    Создание сокета netlink.

    Объявление netlink сокета выглядит вполне стандартно:

    socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE)

    Где AF_NETLINK — протокол netlink
    SOCK_RAW — тип сокета
    NETLINK_ROUTE — семейство netlink протокола.

    Последний параметр может быть различным, в зависимости от того, что мы именно хотим получить от netlink.
    Приведу таблицу со наиболее интересными параметрами (полный список параметров можно посмотреть в документации):

    NETLINK_ROUTE — получать уведомления об изменениях таблицы маршрутизации и сетевых интерфейсов.
    так же может использоваться для изменения всех параметров вышеперечисленных объектов.
    NETLINK_USERSOCK — зарезервировано для определения пользовательских протоколов.
    NETLINK_FIREWALL — служит для передачи IPv4 пакетов из сетевого фильтра на пользовательский уровень
    NETLINK_INET_DIAG — мониторинг inet сокетов
    NETLINK_NFLOG — ULOG сетевого/пакетного фильтра
    NETLINK_SELINUX — получать уведомления от системы Selinux
    NETLINK_NETFILTER — работа с подсистемой сетевого фильтра
    NETLINK_KOBJECT_UEVENT — получение сообщений ядра

    Далее созданные сокет можно использовать для отправки сообщений, например, с помощью функции send и приема сообщений с помощью recvmsg.

    Сообщение netlink.

    Заголовок сообщения представлен структурой nlmsghdr
    struct nlmsghdr
    {
    	__u32 nlmsg_len;	// размер сообщения, с учетом заголовка
    	__u16 nlmsg_type; 	// тип содержимого сообщения (об этом ниже)
    	__u16 nlmsg_flags;	// различные флаги сообщения
    	__u32 nlmsg_seq; 	// порядковый номер сообщения
    	__u32 nlmsg_pid; 	// идентификатор процесса (PID), отославшего сообщение
    };
    


    Поле nlmsg_type может указывать на один из стандартных типо сообщения:
    NLMSG_NOOP — сообщения такого типа игнорируются.
    NLMSG_ERROR — сообщение с ошибкой, и в секции полезных данных будет структура nlmsgerr (о ней чуть ниже)
    NLMSG_DONE — сообщение с этим флагом должно завершать сообщение, разбитое на несколько частей

    Структура nlmsgerr
    struct nlmsgerr
    {
    	int error; 				// отрицательное значение кода ошибки
    	struct nlmsghdr msg; 	// заголовок сообщения, связанного с ошибкой
    };
    


    Сообщения могут быть одного или нескольких (различные типы объеденяются с помощью операции логического или ) типов:

    NLM_F_REQUEST — сообщение — запрос чего либо
    NLM_F_MULTI — сообщение, часть сообщения разбитого на части
    NLM_F_ACK — сообщение — запрос подтверждения
    NLM_F_ECHO — эхо запрос. обычное направление — запросы из уровня ядра на пользовательский уровень
    NLM_F_ROOT — данный тип запроса возвращает некую таблицу, внутри некой сущности
    NLM_F_MATCH — запрос возвращает все найденные соответствия
    NLM_F_ATOMIC — возвращает атомарный срез некой таблицы
    NLM_F_DUMP — аналог NLM_F_ROOT|NLM_F_MATCH

    Дополнительные флаги:

    NLM_F_REPLACE — заменить существующий аналогичный объект
    NLM_F_EXCL — не заменять, если такой объект уже существует
    NLM_F_CREATE — создать объект, если он не существует
    NLM_F_APPEND — добавить объект в список к уже существующему

    Для идентификации клиентов (на уровне ядра и на пользовательском уровне) существует специальная адресная структура — nladdr:

    struct sockaddr_nl
    {
    	sa_family_t nl_family; 	// семейство протоколов - всегда AF_NETLINK
    	unsigned short nl_pad; 	// поле всегда заполнено нулями
    	pid_t nl_pid; 			// идентификатор процесса
    	__u32 nl_groups; 		// маска групп получателей/отправителей
    };
    


    nl_pid — это уникальный адрес сокета. Для клиентов в ядре он всегда равен нулю. Для клиентов на пользовательском уровне он равен идентификатору процесса, владеющего сокетом. Каждый идентификатор должен быть уникальным, поэтому тут вы можете натолкнутся на проблему, когда попытаетесь создать несколько netlink сокетов в многопоточном приложении: при создании нового сокета будет возвращаться ошибка «Operation not permitted». Для обхода данного ограничения следуют nl_pid присваивать значение данного выражения:
    pthread_self() << 16 | getpid();
    Присваивать значение идентификатора следует до того, как будет вызван bind() для сокета.
    Так же идентификатору можно присвоить нулевое значение. В этом случае генерацией уникальных идентификаторов будет заниматься ядро, но первому сокету созданному в приложение всегда будет присваиваться значение идентификатора данного приложения.

    nl_groups — это битовая маска, каждый бит которой представляет номер группы netlink. При вызове bind() для сокета netlink следует указывать битовую маску группы, которую желает прослушивать приложение, в данном контексте. Различные группы могут быть объединены с помощью логического или.
    Основные группы определены в заголовочном файле netlink.
    Пример некоторых из них:

    RTMGRP_LINK — эта группа получает уведомления об изменениях в сетевых интерфейсах (интерфейс удалился, добавился, опустился, поднялся)
    RTMGRP_IPV4_IFADDR — эта группа получает уведомления об изменениях в IPv4 адресах интерфейсов (адрес был добавлен или удален)
    RTMGRP_IPV6_IFADDR — эта группа получает уведомления об изменениях в IPv6 адресах интерфейсов (адрес был добавлен или удален)
    RTMGRP_IPV4_ROUTE — эта группа получает уведомления об изменениях в таблице маршрутизации для IPv4 адресов
    RTMGRP_IPV6_ROUTE — эта группа получает уведомления об изменениях в таблице маршрутизации для IPv6 адресов

    После структуры заголовка nlmsghdr всегда расположен указатель на блок данных. Доступ к нему можно получить с помощью макросов, о которых будет рассказано далее.

    Макросы netlink

    Наиболее полезными, в данном случае, макросами являются:
    NLMSG_ALIGN — Округляет размер сообщения netlink до ближайшего большего значения, выровненного по границе.
    NLMSG_LENGTH — Принимает в качестве параметра размер поля данных (payload) и возвращает выровненное по границе значение размера для записи в поле nlmsg_len заголовка nlmsghdr.
    NLMSG_SPACE — Возвращает размер, который займут данные указанной длины в пакете netlink.
    NLMSG_DATA — Возвращает указатель на данные, связанные с переданным заголовком nlmsghdr.
    NLMSG_NEXT — Возвращает следующую часть сообщения, состоящего из множества частей. Макрос принимает следующий заголовок nlmsghdr в сообщении, состоящем из множества частей. Вызывающее приложение должно проверить наличие в текущем заголовке nlmsghdr флага NLMSG_DONE – функция не возвращает значение NULL при завершении обработки сообщения. Второй параметр задает размер оставшейся части буфера сообщения. Макрос уменьшает это значение на размер заголовка сообщения.
    NLMSG_OK — Возвращает значение true если сообщение не было усечено и его разборка прошла успешно.
    NLMSG_PAYLOAD — Возвращает размер данных (payload), связанных с заголовком nlmsghdr.

    От теории к практике.


    Ну что же. Думаю, что я уже успел надоесть со скучной теорией :) Может быть что-то показалось запутанным или не понятным — постараюсь разжевать все в наглядных примерах, там на самом деле нет ничего сложного.
    Ниже приведено обещанное приложение, которое будет получать уведомления об изменениях в сетевых интерфейсах и таблице маршрутизации.
    В примере введен целый ряд новых структур:

    struct iovec
    {
    	void *iov_base;     	// буфер данных
    	__kernel_size_t iov_len;  // размер данных
    };
    

    Эта структура служит хранилищем полезных данных, передаваемых через сокеты netlink. Полю iov_base присваивается указатель на байтовый массив. Именно в этот байтовый массив будут записаны данные сообщения.

    struct msghdr {
        void   *msg_name;   // адрес клиента (имя сокета)
        int     	msg_namelen;    // длина адреса
        struct iovec *msg_iov;    // указатель на блок данных
        __kernel_size_t msg_iovlen; // количество блоков данных
        void    *msg_control;  // магическое число для протокола, не используется в данных случаях
        __kernel_size_t msg_controllen; // длина предидущего поля данных
        unsigned  msg_flags;	// флаги сообщения
    };
    

    Эта структура непосредственно передается через сокет. Она содержит в себе указатель на блок полезных данных, количество данных блоков, а так же ряд дополнительных флагов и полей, пришедших, по большей части, с платформы BSD.

    struct ifinfomsg
    {
        unsigned char  ifi_family;  // семейство (AF_UNSPEC)
        unsigned short ifi_type;    // тип устройства
        int            ifi_index;   // индекс интерфейса
        unsigned int   ifi_flags;   // флаги устройства
        unsigned int   ifi_change;  // маска смены, зарезервировано для использования в будущем и всегда должно быть равно 0xFFFFFFFF
    };
    

    Эта структура используется для представления сетевого устройства, его семейства, типа, индекса и флагов.

    struct ifaddrmsg
    {
        unsigned char  ifa_family;    // Тип адреса (AF_INET или AF_INET6)
        unsigned char  ifa_prefixlen; // Длина префикса адреса (длина сетевой маски)
        unsigned char  ifa_flags;     // Флаги адреса
        unsigned char  ifa_scope;     // Область адреса
        int            ifa_index;     // Индекс интерфейса, равен аналогичному полю в ifinfomsg
    };
    

    Эта структура служит для представления сетевого адреса, назначенного на сетевой интерфейс.

    struct rtattr
    {
        unsigned short rta_len;     // Длина опции
        unsigned short rta_type;    // Тип опции
        /* данные */ 
    }
    

    Эта структура служит для хранения какого либо параметра соединения или адреса.

    Исходный код, монитор

    #include <errno.h>
    #include <stdio.h>
    #include <memory.h>
    #include <net/if.h>
    #include <arpa/inet.h>
    #include <sys/socket.h>
    #include <linux/rtnetlink.h>
    
    // небольшая вспомогательная функция, которая с помощью макрасов netlink разбирает сообщение и 
    // помещает блоки данных в массив атрибутов rtattr
    void parseRtattr(struct rtattr *tb[], int max, struct rtattr *rta, int len)
    {
    	memset(tb, 0, sizeof(struct rtattr *) * (max + 1));
    
    	while (RTA_OK(rta, len)) {	// пока сообщение не закончилось
    		if (rta->rta_type <= max) {
    			tb[rta->rta_type] = rta;	//читаем атрибут
    		}
    		rta = RTA_NEXT(rta,len);	// получаем следующий атрибут
    	}
    }
    
    int main()
    {
    	int fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);	// создаем нужный сокет
    
    	if (fd < 0) {
    		printf("Ошибка создания netlink сокета: %s", (char*)strerror(errno));
    		return 1;
    	}
    
    	struct sockaddr_nl	local;	// локальный адрес
    	char buf[8192];				// буфер сообщения
    	struct iovec iov;			// структура сообщения
    	iov.iov_base = buf;			// указываем buf в качестве буфера сообщения для iov
    	iov.iov_len = sizeof(buf);	// указываем размер буфера
    
    	memset(&local, 0, sizeof(local));	// очищаем структуру
    
    	local.nl_family = AF_NETLINK;		// указываем семейство протокола
    	local.nl_groups = 	RTMGRP_LINK | RTMGRP_IPV4_IFADDR | RTMGRP_IPV4_ROUTE;	// указываем необходимые группы
    	local.nl_pid = getpid();	//в качестве идентификатора указываем идентификатор данного приложения
    
    	// структура сообщения netlink - инициализируем все поля
    	struct msghdr msg;	
    	{
    		msg.msg_name = &local;					// задаем имя - структуру локального адреса
    		msg.msg_namelen = sizeof(local);		// указываем размер
    		msg.msg_iov = &iov;						// указываем вектор данных сообщения
    		msg.msg_iovlen = 1;						// задаем длину вектора
    	}	
    
    	if (bind(fd, (struct sockaddr*)&local, sizeof(local)) < 0) {		// связываемся с сокетом
    		printf("Ошибка связывания с netlink сокетом: %s", (char*)strerror(errno));
    		close(fd);
    		return 1;
    	}	
    
    	// читаем и разбираем сообщения из сокета
    	while (1) {
    		ssize_t status = recvmsg(fd, &msg, MSG_DONTWAIT);	// после вызова bind() мы можем принимать сообщения для указанных групп
    
    		//	небольшие проверки
    		if (status < 0) {
    			if (errno == EINTR || errno == EAGAIN)
    			{
    				usleep(250000);
    				continue;
    			}
    
    			printf("Ошибка приема сообщения netlink: %s", (char*)strerror(errno));
    			continue;
    		}
    
    		if (msg.msg_namelen != sizeof(local)) {	//провряем длину адреса, мало ли :)
    			printf("Некорректная длина адреса отправителя");
    			continue;
    		}
    
    		// собственно разбор сообщения
    		struct nlmsghdr *h; // указатель на заголовок сообщения
    
    		for (h = (struct nlmsghdr*)buf; status >= (ssize_t)sizeof(*h); ) {	// для всех заголовков сообщений
    			int len = h->nlmsg_len;		// длина всего блока
    			int l = len - sizeof(*h);	// длина текущего сообщения
    			char *ifName;				// имя соединения
    
    			if ((l < 0) || (len > status)) {
    				printf("Некорректная длина сообщения: %i", len);
    				continue;
    			}
    
    			// смотрим тип сообщения
    			if ((h->nlmsg_type == RTM_NEWROUTE) || (h->nlmsg_type == RTM_DELROUTE)) {	// если это изменения роутов - печатаем сообщение
    				printf("Произошли изменения в таблице маршрутизации\n");	
    			} else {	// в остальных случаях начинаем более детально разбираться
    				char *ifUpp;		// состояние устройства
    				char *ifRunn;		// состояние соединения
    				struct ifinfomsg *ifi;  // указатель на структуру, содержащюю данные о сетевом подключении
    				struct rtattr *tb[IFLA_MAX + 1];	// массив атрибутов соединения, IFLA_MAX определен в rtnetlink.h
    
    				ifi	= (struct ifinfomsg*) NLMSG_DATA(h);	// получаем информацию о сетевом соединении в кором произошли изменения
    
    				parseRtattr(tb, IFLA_MAX, IFLA_RTA(ifi), h->nlmsg_len);	// получаем атрибуты сетевого соединения
    				
    				if (tb[IFLA_IFNAME]) {	// проверяем валидность атрибута, хранящего имя соединения
    					ifName = (char*)RTA_DATA(tb[IFLA_IFNAME]); //получаем имя соединения
    				}
    
    				if (ifi->ifi_flags & IFF_UP) { // получаем состояние флага UP для соединения
    					ifUpp = (char*)"UP";
    				} else {
    					ifUpp = (char*)"DOWN";
    				}
    
    				if (ifi->ifi_flags & IFF_RUNNING) { // получаем состояние флага RUNNING для соединения
    					ifRunn = (char*)"RUNNING";
    				} else {
    					ifRunn = (char*)"NOT RUNNING";
    				}
    
    				char ifAddress[256];	// сетевой адрес интерфейса
    				struct ifaddrmsg *ifa; // указатель на структуру содержащую данные о сетевом интерфейсе
    				struct rtattr *tba[IFA_MAX+1];	// массив атрибутов адреса
    
    				ifa = (struct ifaddrmsg*)NLMSG_DATA(h);	// получаем данные из соединения
    
    				parseRtattr(tba, IFA_MAX, IFA_RTA(ifa), h->nlmsg_len);	// получаем атрибуты сетевого соединения
    
    				if (tba[IFA_LOCAL]) {  // проверяем валидность указателя локального адреса
    					inet_ntop(AF_INET, RTA_DATA(tba[IFA_LOCAL]), ifAddress, sizeof(ifAddress));	// получаем IP адрес
    				}
    
    				switch (h->nlmsg_type) {	//что конкретно произошло
    					case RTM_DELADDR:
    						printf("Был удален адрес интерфейса %s\n", ifName);
    						break;
    
    					case RTM_DELLINK:
    						printf("Был удален интерфейс %s\n", ifName);
    						break;
    
    					case RTM_NEWLINK:
    						printf("Новый интерфейс %s, состояние интерфейса %s %s\n", ifName, ifUpp, ifRunn);
    						break;
    
    					case RTM_NEWADDR:
    						printf("Был добавлен адрес для интерфейса %s: %s\n", ifName, ifAddress);
    						break;
    				}
    			}
    
    			status -= NLMSG_ALIGN(len);	// выравниваемся по длине сообщения (если этого не сделать - будет очень плохо, можете проверить :))
    
    			h = (struct nlmsghdr*)((char*)h + NLMSG_ALIGN(len));	//получаем следующее сообщение
    		}
    
    		usleep(250000);	// немножко спим, что бы не очень грузить процессор
    	}
    
    	close(fd);	// закрываем дескриптор сокета
    
    	return 0;
    }
    


    Компиляция программы:
    gcc monitor.c -o monitor

    И результат работы:


    Пояснения к коду.
    После запуска программы мы создаем netlink сокет и проверяем успешность его создания. Далее происходит объявление необходимых переменных и заполнение структуры локального адреса. Тут мы указываем группы сообщений, на которые хотим подписаться: RTMGRP_LINK, RTMGRP_IPV4_IFADDR, RTMGRP_IPV4_ROUTE.
    Так же объявляем структуру сообщения и связываем с ней один блок данных.
    После этого происходит связывание с сокетом, с помощью bind(). После этого мы становимся подписанными на сообщения для указанных групп. Можно принимать сообщения через сокет.
    Далее следует бесконечный цикл приема сообщений из сокета. Т.к. принимаемый блок данных может иметь несколько заголовков и ассоциированных с ними данных — начинаем перебирать, с помощью netlink макросов все принятые данные.
    Каждое новое сообщение расположено по указателю struct nlmsghdr *h.
    Теперь можно разбирать собственно сообщение. Смотрим на поле nlmsg_type и выясняем, что же за сообщение к нам приехало. Если оно связано с таблицей маршрутизации — печатаем сообщение и идем к следующему сообщению. А если нет — начинаем детально разбираться.
    Объявляются массивы опций rtattr, куда будут складываться все необходимые данные. За получение этих данных отвечает вспомогательная функция parseRtattr. Она использует макросы netlink и заполняет указанный массив всеми атрибутами из блока данных структуры ifinfomsg или ifaddrmsg.
    После того как мы получили массивы, заполненные атрибутами — можем работать с этим значениями, анализировать их, печатать.
    Доступ к каждому атрибуту осуществляется по его индексу. Все индексы определены в заголовочных файлах netlink и прокомментированы.
    В данном случае мы используем следующие индексы:
    IFLA_IFNAME — индекс атрибута с именем интерфейса.
    IFA_LOCAL — индекс атрибута с локальным IP адресом.
    После всего этого мы обладаем полной информацией о том, что произошло и можем печатать информацию на экран.

    Вот и все. Очень надеюсь, что данный материал будет полезен кому-то.
    Если будет достаточное количество желающих (больше одного человека:) ) — могу написать продолжение и рассмотреть, например, взаимодействие с модулем ядра или реализацию работы с IPv6.

    При написании статьи использовалось:
    1. tools.ietf.org/html/rfc3549
    2. www.linuxjournal.com/article/7356

    Спасибо за внимание.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 4

      +2
      Автору спасибо! После таких статей появляется желание кодить под никсы.
        0
        Молодец! Хочу еще статей про написание сетевых приложений для Linux.
        Я так понимаю, в FreeBSD или другой POSIX-системе написанный код не заработает, потому что netlink только для Linux?
          +2
          Да, netlink — это чисто линуксовая штука, на BSD системах и прочих unix-like можно использовать вышеупомянутые ioctl, либо же воспользоваться похожим socket механизмом, с использованием семейств AF_ROUTE, AF_LINK и т.п.
          Подробнее можете почитать в «Unix network programming» Стивенса.
            0
            Как печально, что на все времени никогда не хватает.

        Only users with full accounts can post comments. Log in, please.