В предыдущей заметке был показан набросок кода модуля ядра Linux для создания дополнительного виртуального сетевого интерфейса. Это был упрощённый фрагмент из реального проекта, отработавшего несколько лет без сбоев и рекламаций, так что он вполне может служить шаблоном для дальнейшего улучшения, исправления и развития.

Но такой подход к реализации, во-первых, не единственный, а, во-вторых, в некоторых ситуациях он может быть и неприемлемым (например, во встраиваемой системе с ядром младше 2.6.36, где ещё нет вызова netdev_rx_handler_register()). Ниже будет рассмотрен альтернативный вариант с той же функциональностью, но реализующий её на совсем другом слое сетевого стека TCP/IP.

Протоколы сетевого уровня

Достаточно много, чтобы не повторяться, написано о том, что уровни (слои) сетевого стека TCP/IP не соответствуют однозначно 7-ми уровням модели взаимодействия открытых систем OSI/ISO (или, если честнее, модель OSI, близкая сердцу академических кругов, оказалась неадекватной реально развивающейся сети TCP/IP). Создание виртуального интерфейса, в предыдущей обсуждавшейся реализации, выполнялось на уровне интерфейсов (L2, Level 2 — очень примерно соответствующий канальному уровню OSI). Нынешняя реализация использует возможности сетевого уровня (L3).

Представляется целесообразным рассмотреть некоторый минимум относительно средств сетевого уровня, в объёме даже чуть шире, чем необходимо для текущей задачи, для возможностей последующего её расширения. На сетевом уровне стека сетевых протоколов (TCP/IP, но не только — здесь же поддерживаются и все другие семейства протоколов, но на сегодня они представляются мало актуальными) обеспечивается обработка таких протоколов как: IP/IPv4/IPv6, IPX, IGMP, RIP, OSPF, ARP, или осуществляется добавление оригинальных пользовательских протоколов. Для установки обработчиков сетевого уровня предоставляется API сетевого уровня (<linux/netdevice.h>):

struct packet_type {     __be16  type; /* This is really htons(ether_type). */     struct net_device *dev; /* NULL is wildcarded here    */     int (*func) (struct sk_buff*, struct net_device*, struct packet_type*, struct net_device*);  ...    struct list_head list;  };  extern void dev_add_pack( struct packet_type *pt );  extern void dev_remove_pack( struct packet_type *pt );  

Фактически, в протокольных модулях ядра мы должны добавить фильтр, через который проходят буфера сокетов из входящего потока интерфейса (исходящий поток реализуется проще, как было показано в предыдущей реализации). Функция dev_add_pack() добавляет ещё один новый обработчик для пакетов заданного типа, реализуемый функцией func(). Функция добавляет, но не замещает существующий обработчик (в том числе и обработчик по умолчанию сетевой системы Linux). На обработку в функцию отбираются (попадают) те буфера сокетов, которые удовлетворяют критерием, заложенным в структуре struct packet_type (по типу протокола type и сетевому интерфейсу dev).

Примечание: По той же схеме (установка функции-фильтра) происходит добавление новых протоколов и на более высоком, транспортном уровне сетевого стека (на котором обрабатываются, например, протоколы UDP, TCP, SCTP). Все более высокие уровни (более-менее аналогичные уровням модели OSI) в ядре не представлены, и обслуживаются в пространстве пользователя техникой программирования BSD сокетов. Но все эти, относящиеся к более высоким уровням, детали более не будут рассматриваться в тексте.

Если мы хотели бы добавить новый протокол (проприетарный), то должны были бы переопределить его тип:

#define PROTO_ID 0x1234  static struct packet_type test_proto = {     __constant_htons( PROT_ID ),     ... } 

Проблему при этом составило бы то, что стандартный IP-стек не знает такого протокола, и всю его обработку нам придётся взять на себя. Но в наши цели входит только переопределить обработку некоторых пакетов, то для этого используем константу ETH_P_ALL, указывающую, что через фильтр должны проходить все протоколы (а если поле dev равно NULL — то и все сетевые интерфейсы).

Для сравнения и конкретизации, большое число идентификаторов протоколов (Ethernet Protocol ID’s) находим в <linux/if_ether.h>, вот некоторые из них, для примера:

#define ETH_P_LOOP   0x0060  /* Ethernet Loopback packet  */ #define ETH_P_IP     0x0800  /* Internet Protocol packet  */ #define ETH_P_ARP    0x0806  /* Address Resolution packet */ #define ETH_P_PAE    0x888E  /* Port Access Entity (IEEE 802.1X) */ #define ETH_P_ALL    0x0003  /* Every packet (be careful!!!) */ ... 

В данном случае поле type — это не абстрактное числовое значение в программном коде, это значение в бинарном виде будет вписано в заголовок Ethernet кадра, физически отправляемого в среду распространения:

struct ethhdr {     unsigned char h_dest[ETH_ALEN];   /* destination eth addr */     unsigned char h_source[ETH_ALEN]; /* source ether addr    */     __be16       h_proto;             /* packet type ID field */  } __attribute__((packed));  

(Это же описание нам понадобится в коде при заполнении структуры struct packet_type в модуле).

Сама функция фильтра (поле func), которую нам ещё предстоит написать, может быть, в простейшем варианте, нечто подобное:

int test_pack_rcv( struct sk_buff *skb, struct net_device *dev,                     struct packet_type *pt, struct net_device *odev ) {     LOG( "packet received with length: %u\n", skb->len );    kfree_skb( skb );     return skb->len;  }; 

Функция показана здесь, главным образом, из-за обязательного вызова kfree_skb(). Он, в отличие от, казалось бы, близкого по смыслу dev_kfree_skb() в передающем канале, не уничтожает сокетный буфер, а только декрементирует его счётчик использования (поле users). При установке каждого дополнительного фильтра протокола вызовом dev_add_pack() это поле сокетных буферов будет инкрементировано. Вы можете установить несколько фильтров сетевого уровня (в одном и том же, или нескольких загружаемых модулях) и они будут срабатывать все в порядке обратному их установке, но каждый из них должен выполнить kfree_skb(). В противном случае вы будете иметь медленную, но неуклонную утечку памяти в сетевом стеке, так что её результат, как крах системы, обнаружится только через несколько часов непрерывной работы.

Это достаточно интересное и не очевидное место, настолько, что есть смысл отвлечься и посмотреть исходный код реализации kfree_skb() (файл net/core/skbuff.c):

void kfree_skb(struct sk_buff *skb) {    if (unlikely(!skb))       return;    if (likely(atomic_read(&skb->users) == 1))       smp_rmb();    else if (likely(!atomic_dec_and_test(&skb->users)))       return;    trace_kfree_skb(skb, __builtin_return_address(0));    __kfree_skb(skb); } 

Вызов kfree_skb() будет реально освобождать буфер сокета только в случае skb->users == 1, при всех остальных значениях он будет только декрементировать skb->users (счётчик использования).

Теперь у нас есть достаточно деталей для того, чтобы организовать работу виртуального интерфейса, но используя, на этот раз, сетевой уровень IP-стека.

Модуль виртуального интерфейса

Поступим как и ранее: создадим два варианта модуля — упрощённый вариант virtl.ko, сетевой интерфейс (virt0) которого замещает родительский сетевой интерфейс, и полный вариант virt.ko, который анализирует сетевые фреймы протоколов (ARP и IP4), и затрагивает только тот трафик, который его интерфейсу относится. Разница состоит в том, что на время загрузки упрощённого модуля работа родительского интерфейса временно прекращается (до выгрузки модуля virtl.ko), а при загрузке полного варианта оба интерфейса могут работать параллельно и независимо. Код полного модуля заметно более громоздкий, а для понимания принципов он ничего не добавляет. Далее детально рассмотрен упрощённый вариант, показывающий принципы, и только позже мы минимально коснёмся полного варианта (код его и протокол испытаний приведены в архиве примеров):

#include <linux/module.h>  #include <linux/version.h>  #include <linux/netdevice.h>  #include <linux/etherdevice.h>  #include <linux/inetdevice.h>  #include <linux/moduleparam.h>  #include <net/arp.h>  #include <linux/ip.h>   #define ERR(...) printk( KERN_ERR "! "__VA_ARGS__ )  #define LOG(...) printk( KERN_INFO "! "__VA_ARGS__ )  #define DBG(...) if( debug != 0 ) printk( KERN_INFO "! "__VA_ARGS__ )   static char* link = "eth0";  module_param( link, charp, 0 );   static char* ifname = "virt";  module_param( ifname, charp, 0 );   static int debug = 0;  module_param( debug, int, 0 );   static struct net_device *child = NULL;  static struct net_device_stats stats;  // статическая таблица статистики интерфейса  static u32 child_ip;   struct priv {     struct net_device *parent;  };   static char* strIP( u32 addr ) {      // диагностика IP в точечной нотации     static char saddr[ MAX_ADDR_LEN ];     sprintf( saddr, "%d.%d.%d.%d",              ( addr ) & 0xFF, ( addr >> 8 ) & 0xFF,              ( addr >> 16 ) & 0xFF, ( addr >> 24 ) & 0xFF            );     return saddr;  }   static int open( struct net_device *dev ) {     struct in_device *in_dev = dev->ip_ptr;     struct in_ifaddr *ifa = in_dev->ifa_list;      /* IP ifaddr chain */     LOG( "%s: device opened", dev->name );     child_ip = ifa->ifa_address;     netif_start_queue( dev );     if( debug != 0 ) {        char sdebg[ 40 ] = "";        sprintf( sdebg, "%s:", strIP( ifa->ifa_address ) );        strcat( sdebg, strIP( ifa->ifa_mask ) );        DBG( "%s: %s", dev->name, sdebg );     }     return 0;  }   static int stop( struct net_device *dev ) {     LOG( "%s: device closed", dev->name );     netif_stop_queue( dev );     return 0;  }   static struct net_device_stats *get_stats( struct net_device *dev ) {     return &stats;  }   // передача фрейма  static netdev_tx_t start_xmit( struct sk_buff *skb, struct net_device *dev ) {     struct priv *priv = netdev_priv( dev );     stats.tx_packets++;     stats.tx_bytes += skb->len;     skb->dev = priv->parent;   // передача в родительский (физический) интерфейс     skb->priority = 1;     dev_queue_xmit( skb );     DBG( "tx: injecting frame from %s to %s with length: %u",          dev->name, skb->dev->name, skb->len );     return 0;     return NETDEV_TX_OK;  }   static struct net_device_ops net_device_ops = {     .ndo_open = open,     .ndo_stop = stop,     .ndo_get_stats = get_stats,     .ndo_start_xmit = start_xmit,  };   // приём фрейма  int pack_parent( struct sk_buff *skb, struct net_device *dev,                   struct packet_type *pt, struct net_device *odev ) {     skb->dev = child;          // передача фрейма в виртуальный интерфейс     stats.rx_packets++;     stats.rx_bytes += skb->len;     DBG( "tx: injecting frame from %s to %s with length: %u",          dev->name, skb->dev->name, skb->len );     kfree_skb( skb );     return skb->len;  };    static struct packet_type proto_parent = {     __constant_htons( ETH_P_ALL ), // перехватывать все пакеты: ETH_P_ARP & ETH_P_IP     NULL,     pack_parent,     (void*)1,     NULL  };   int __init init( void ) {     void setup( struct net_device *dev ) { // вложенная функция (расширение GCC)        int j;        ether_setup( dev );        memset( netdev_priv( dev ), 0, sizeof( struct priv ) );        dev->netdev_ops = &net_device_ops;        for( j = 0; j < ETH_ALEN; ++j )     // заполнить MAC фиктивным адресом           dev->dev_addr[ j ] = (char)j;     }     int err = 0;     struct priv *priv;     char ifstr[ 40 ];     sprintf( ifstr, "%s%s", ifname, "%d" );  #if (LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0))     child = alloc_netdev( sizeof( struct priv ), ifstr, setup );  #else     child = alloc_netdev( sizeof( struct priv ), ifstr, NET_NAME_UNKNOWN, setup );  #endif     if( child == NULL ) {        ERR( "%s: allocate error", THIS_MODULE->name ); return -ENOMEM;     }     priv = netdev_priv( child );     priv->parent = dev_get_by_name( &init_net, link ); // родительский интерфейс      if( !priv->parent ) {        ERR( "%s: no such net: %s", THIS_MODULE->name, link );        err = -ENODEV; goto err;     }     if( priv->parent->type != ARPHRD_ETHER && priv->parent->type != ARPHRD_LOOPBACK ) {        ERR( "%s: illegal net type", THIS_MODULE->name );        err = -EINVAL; goto err;     }     memcpy( child->dev_addr, priv->parent->dev_addr, ETH_ALEN );     memcpy( child->broadcast, priv->parent->broadcast, ETH_ALEN );     if( ( err = dev_alloc_name( child, child->name ) ) ) {        ERR( "%s: allocate name, error %i", THIS_MODULE->name, err );        err = -EIO; goto err;     }     register_netdev( child );         // зарегистрировать новый интерфейс     proto_parent.dev = priv->parent;     dev_add_pack( &proto_parent );    // установить обработчик фреймов для родителя     LOG( "module %s loaded", THIS_MODULE->name );     LOG( "%s: create link %s", THIS_MODULE->name, child->name );     return 0;  err:     free_netdev( child );     return err;  }   void __exit virt_exit( void ) {     struct priv *priv= netdev_priv( child );     dev_remove_pack( &proto_parent ); // удалить обработчик фреймов     unregister_netdev( child );     dev_put( priv->parent );     free_netdev( child );     LOG( "module %s unloaded", THIS_MODULE->name );     LOG( "=============================================" );  }   module_init( init );  module_exit( virt_exit );   MODULE_AUTHOR( "Oleg Tsiliuric" );  MODULE_LICENSE( "GPL v2" );  MODULE_VERSION( "3.7" );  

Всё достаточно прозрачно:

• После регистрации нового сетевого интерфейса (virt0) он выполняет вызов dev_add_pack(), устанавливающий фильтр принимаемых пакетов для родительского интерфейса;
• Предварительно устанавливается в структуре packet_type поле dev на указатель родительского интерфейса: только с этого интерфейса входящий трафик будет перехватываться определённой в структуре функцией pack_parent();
• Эта функция фиксирует статистику интерфейса и, самое главное, подменяет в сокетном буфере указатель родительского интерфейса на виртуальный.
• Обратная подмена (виртуального на физический) происходит в функции отправки фрейма start_xmit().

Вот как это работает:

• На тестируемом компьютере загружаем модуль и конфигурируем его на отдельную новую подсеть:
  

  $ ip address  ... 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000      link/ether 08:00:27:52:b9:e0 brd ff:ff:ff:ff:ff:ff      inet 192.168.1.21/24 brd 192.168.1.255 scope global eth0      inet6 fe80::a00:27ff:fe52:b9e0/64 scope link         valid_lft forever preferred_lft forever  3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000      link/ether 08:00:27:0f:13:6d brd ff:ff:ff:ff:ff:ff      inet 192.168.56.102/24 brd 192.168.56.255 scope global eth1      inet6 fe80::a00:27ff:fe0f:136d/64 scope link         valid_lft forever preferred_lft forever  $ sudo insmod virt.ko link=eth1 debug=1  $ sudo ifconfig virt0 192.168.50.19  $ sudo ifconfig virt0  virt0     Link encap:Ethernet  HWaddr 08:00:27:0f:13:6d            inet addr:192.168.50.19  Bcast:192.168.50.255  Mask:255.255.255.0            inet6 addr: fe80::a00:27ff:fe0f:136d/64 Scope:Link            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1            RX packets:0 errors:0 dropped:0 overruns:0 frame:0            TX packets:46 errors:0 dropped:0 overruns:0 carrier:0            collisions:0 txqueuelen:1000            RX bytes:0 (0.0 B)  TX bytes:8373 (8.1 KiB)  

  (Здесь показана статистика с нулевым числом принятых байт на интерфейсе).

• На компьютере, с которого проводим тестирование, создаём алиасный IP для новой подсети (192.168.50.0/24) и можем осуществлять трафик на созданный интерфейс:
  

  $ sudo ifconfig vboxnet0:1 192.168.50.1 $ ping 192.168.50.19  PING 192.168.50.19 (192.168.50.19) 56(84) bytes of data.  64 bytes from 192.168.50.19: icmp_req=1 ttl=64 time=0.627 ms  64 bytes from 192.168.50.19: icmp_req=2 ttl=64 time=0.305 ms  64 bytes from 192.168.50.19: icmp_req=3 ttl=64 time=0.326 ms  ^C  --- 192.168.50.19 ping statistics ---  3 packets transmitted, 3 received, 0% packet loss, time 2000ms  rtt min/avg/max/mdev = 0.305/0.419/0.627/0.148 ms  

• На этом же (тестирующем) компьютере (ответной стороне) очень информационно наблюдать трафик (в отдельном терминале), фиксируемый tcpdump:
  

  $ sudo tcpdump -i vboxnet0  tcpdump: verbose output suppressed, use -v or -vv for full protocol decode  listening on vboxnet0, link-type EN10MB (Ethernet), capture size 65535 bytes  ...  18:41:01.740607 ARP, Request who-has 192.168.50.19 tell 192.168.50.1, length 28  18:41:01.741104 ARP, Reply 192.168.50.19 is-at 08:00:27:0f:13:6d (oui Unknown), length 28  18:41:01.741116 IP 192.168.50.1 > 192.168.50.19: ICMP echo request, id 8402, seq 1, length 64  18:41:01.741211 IP 192.168.50.19 > 192.168.50.1: ICMP echo reply, id 8402, seq 1, length 64  18:41:02.741164 IP 192.168.50.1 > 192.168.50.19: ICMP echo request, id 8402, seq 2, length 64  18:41:02.741451 IP 192.168.50.19 > 192.168.50.1: ICMP echo reply, id 8402, seq 2, length 64  18:41:03.741163 IP 192.168.50.1 > 192.168.50.19: ICMP echo request, id 8402, seq 3, length 64  18:41:03.741471 IP 192.168.50.19 > 192.168.50.1: ICMP echo reply, id 8402, seq 3, length 64  18:41:06.747701 ARP, Request who-has 192.168.50.1 tell 192.168.50.19, length 28  18:41:06.747715 ARP, Reply 192.168.50.1 is-at 0a:00:27:00:00:00 (oui Unknown), length 28  

Расширяем возможности

Теперь коротко, в два слова, о том, как сделать полновесный виртуальный интерфейс, работающий только со своим трафиком, и не нарушающий работу родительского интерфейса (то, что делает полная версия модуля в архиве). Для этого необходимо:

• Объявить два раздельных обработчика протоколов (для протоколов разрешения имён ARP и собственно для протокола IP):
  

  // обработчик фреймов ETH_P_ARP  int arp_pack_rcv( struct sk_buff *skb, struct net_device *dev,                    struct packet_type *pt, struct net_device *odev ) {     ...    return skb->len;  };   static struct packet_type arp_proto = {     __constant_htons( ETH_P_ARP ),     NULL,     arp_pack_rcv,  // фильтр пртокола ETH_P_ARP     (void*)1,     NULL  };   // обработчик фреймов ETH_P_IP  int ip4_pack_rcv( struct sk_buff *skb, struct net_device *dev,                    struct packet_type *pt, struct net_device *odev ) {     ...    return skb->len;  };   static struct packet_type ip4_proto = {     __constant_htons( ETH_P_IP ),     NULL,     ip4_pack_rcv,    // фильтр пртокола ETH_P_IP     (void*)1,     NULL  };  

• Оба их последовательно зарегистрировать в функции инициализации модуля:
  

     arp_proto.dev = ip4_proto.dev = priv->parent; // перехват только с родительского интерфейса     dev_add_pack( &arp_proto );     dev_add_pack( &ip4_proto );  

• Каждый из установленных фильтров должен осуществлять подмену интерфейса только для тех фреймов, IP получателя которых совпадает с IP интерфейса…
• Два раздельных обработчика удобны тем, что заголовки фреймов ARP и IP имеют совершенно разный формат, и выделять IP назначения в них приходится по-разному (весь полный код показан в архиве примера).

Используя такой полновесный модуль, можно открыть к хосту, например, две параллельные сессии SSH на разные интерфейсы (использующие разные IP), которые будут в параллель реально использовать единый общий физический интерфейс:

$ ssh olej@192.168.50.17  olej@192.168.50.17's password:  Last login: Mon Jul 16 15:52:16 2012 from 192.168.1.9  ... $ ssh olej@192.168.56.101  olej@192.168.56.101's password:  Last login: Mon Jul 16 17:29:57 2012 from 192.168.50.1  ... $ who  olej     tty1         2012-07-16 09:29 (:0)  olej     pts/0        2012-07-16 09:33 (:0.0)  ... olej     pts/6        2012-07-16 17:29 (192.168.50.1)  olej     pts/7        2012-07-16 17:31 (192.168.56.1)  

Последняя показанная команда (who) выполняется уже в сессии SSH, то есть на том самом удалённом хосте, к которому и фиксируется два независимых подключения из двух различных подсетей (последние две строки вывода), которые на самом деле представляют один хост, но с точки зрения различных его сетевых интерфейсов.

Дальнейшие уточнения

При подготовке и отладке примеров модулей, для уточнения деталей, активно использовалась вот эта (достаточно свежая) книга: Rami Rosen: «Linux Kernel Networking: Implementation and Theory», Apress, 650 pages, 2014, ISBN-13: 978-1-4302-6196-4.

Автор любезно предоставил её для свободного скачивания ещё до выхода книги в продажу (2013-12-22). Скачать её можно на этой странице.

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

Архив кодов, упоминаемых в тексте, для экспериментов и дальнейшего развития, можно взять здесь или здесь.

ссылка на оригинал статьи http://habrahabr.ru/post/270517/