前のメモで、追加の仮想ネットワークインターフェイスを作成するためのLinuxカーネルモジュールのコードスケッチを示しました。これは実際のプロジェクトからの単純化された断片であり、失敗や苦情なしに数年間機能したため、さらなる改善、修正、開発のテンプレートとして役立つ可能性があります。

しかし、この実装へのアプローチは、第一に、それだけではなく、第二に、状況によっては受け入れられない場合があります（たとえば、netdev_rx_handler_register（）がまだ呼び出されていない2.6.36よりも若いカーネルを備えた組み込みシステム）。以下では、同じ機能を備えた代替案を検討しますが、TCP / IPネットワークスタックのまったく異なる層に実装します。

ネットワーク層プロトコル

繰り返しないように、TCP / IPネットワークスタックのレベル（レイヤー）はOSI / ISOオープンソースシステム相互作用モデルの7つのレベル（または、より正直に言うと、学界の中心に近いOSIモデル）に明確に対応していないと書かれています不適切に進化しているTCP / IPネットワーク）。前述の実装の仮想インターフェイスの作成は、 インターフェイスレベル（L2、レベル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構造体に規定された基準を満たすソケットバッファーを選択（取得）します（プロトコルタイプおよびネットワークインターフェイス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の場合、すべてのネットワークインターフェイスを通過する必要があります）。

比較と具体化のために、多数のプロトコル識別子（イーサネットプロトコルID）が<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!!!) */ ...

この場合、タイプフィールドはプログラムコードの抽象的な数値ではありません。バイナリ形式のこの値は、配信環境に物理的に送信されるフレームのイーサネットヘッダーに入力されます。

 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（）（file 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スタックのネットワーク層を使用しています。

仮想インターフェースモジュール

以前のように進みます：モジュールの2つのバージョンを作成します-ネットワークインターフェース（virt0）が親ネットワークインターフェースに置き換わる virtl.koの簡易バージョンと、ネットワークプロトコルフレーム（ARPおよびIP4）を分析し、そのトラフィックのみに影響するvirt.koのフルバージョンこれはそのインターフェースに関連しています。違いは、簡略化されたモジュールのロード中、親インターフェースが一時的に動作を停止することです（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（）を呼び出します。これにより、親インターフェイスのパケットフィルターが設定されます。
devフィールドはpacket_type構造体で親インターフェースポインターに事前設定されています。このインターフェースからのみ、構造体で定義された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)

（これは、インターフェースで受信したゼロバイトの統計を示しています）。

テスト対象のコンピューターで、新しいサブネット（192.168.50.0/24）のエイリアスIPを作成し、作成したインターフェイスへのトラフィックを実行できます。

 $ 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

機会の拡大

簡潔に、簡単に言えば、独自のトラフィックでのみ動作し、親インターフェイスの動作を中断しない本格的な仮想インターフェイスを作成する方法について（モジュールのフルバージョンがアーカイブで行うこと）。これを行うには、以下を行う必要があります。

2つの別個のプロトコルハンドラーを宣言します（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と一致するフレームに対してのみインターフェイススプーフィングを実行する必要があります...
2つの別個のハンドラーは、ARPフレームとIPフレームのヘッダーの形式がまったく異なるため、宛先IPを異なる方法で割り当てる必要があるという点で便利です（すべてのコードはアーカイブの例に示されています）。

このようなフルウェイトモジュールを使用すると、たとえば、異なるインターフェイス上で（異なるIPを使用して）2つの並列SSHセッションを開くことができ、実際には単一の共通物理インターフェイスを並列に使用します。

 $ 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)

示されている最後のコマンド（誰）は、SSHセッションで、つまり2つの異なるサブネットからの2 つの独立した接続が固定されている（出力の最後の2行）、実際には1つのホストを表していますが、その観点からは、SSHセッションで既に実行されていますさまざまなネットワークインターフェイス。

さらなる洗練

サンプルモジュールの準備とデバッグでは、詳細を明確にするために、この（かなり最近の）本が積極的に使用されました。RamiRosen：「Linux Kernel Networking：Implementation and Theory」、Apress、650ページ、2014年、ISBN-13：978-1-4302 -6196-4。

著者は、本が発売される前に無料でダウンロードできるように親切に提供しました（2013-12-22）。このページからダウンロードできます。

この記事で説明したような問題に興味がある人は、自分のネットワークインターフェイスを使用する技術をさらに発展させるために、この出版物で多くのアイデアを見つけることができます。

ここかここで実験とさらなる開発のためにテキストで言及されたコードのアーカイブを取ることができます。

別の仮想インターフェイス

ネットワーク層プロトコル

仮想インターフェースモジュール

機会の拡大

さらなる洗練

More articles: