HTTPSのカーネルモジュール（Netfilter）または透過プロキシの作成方法の学習

この記事は、Linuxカーネルモジュールとネットワークアプリケーションのプログラミングを開始している、または開始したい読者を対象としています。 また、HTTPSトラフィックの透過的なプロキシ処理にも役立ちます。



さらに読む価値があるかどうかを評価できる小さな目次：

1. プロキシサーバーはどのように機能しますか？ 問題の声明。
2. クライアント-ノンブロッキングソケットを使用するサーバーアプリケーション。
3. Netfilterライブラリを使用してカーネルモジュールを作成します。
4. ユーザー空間からのカーネルモジュールとの相互作用（Netlink）

PS HTTPおよびHTTPSの透過プロキシサーバーを確認したい場合は、透過ポート3128のSquidなどのHTTPの透過プロキシサーバーを構成し、 Shifter sourcesでアーカイブをダウンロードします 。 コンパイル（make）し、コンパイルが成功したら、。/ Startをルートとして実行します。 必要に応じて、コンパイルの前にshifter.hの設定を調整できます。

問題の声明

ITの分野のすべての初心者と同様に、コアについて少し掘り下げたいと思いました。 ここでは、実験用の領域が単独で表示されました。 Googleを見ると、HTTPの透過プロキシサーバーに誰も問題がない場合、HTTPSの場合、HTTPSプロトコルの透過プロキシがないと確信する人がいることに気付くでしょう。 そして彼は決してそうならないでしょう。 このすべてがこの記事の外観に役立ちました。

まず、必要なプロキシサーバーのいくつかの側面を検討します。 ブラウザがHTTPサーバーに直接アクセスすると、次の典型的なリクエストが作成されます。

GET / HTTP/1.1 Host: www.google.ru …
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ブラウザー設定でプロキシサーバーを指定すると、ブラウザーはプロキシサーバーへの接続を開始し、完全なアドレスを使用してリクエストを送信します。

 GET http://www.google.ru/ HTTP/1.1 Host: www.google.ru …
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の場合のように、プロキシサーバーが不完全なアドレスを持つリクエストを受信した場合、このリクエストの宛先がわからない場合があり、エラーを返します。

HTTPSについて少し説明します。 ブラウザはtcp接続を確立し、SSLプロトコルを使用して：証明書を交換し、暗号化されたHTTPトラフィックを送信します。 SSLプロトコルは、送信されたデータを途中で読み取ることができないようにすることを目的としているため、プロキシサーバーは、HTTPの場合のように、誰と接続を確立するかを判断できません。 プロキシサーバーを介してHTTPS経由でデータを送信するには、ブラウザーはHTTP CONNECTメソッドを使用して接続するプロキシサーバーに通知する必要があります。

 CONNECT mail.google.com:443 HTTP/1.1 Host: mail.google.com …
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

接続が正常に確立されたことをプロキシサーバーが応答する必要があるもの：

 HTTP/1.0 200 Connection established
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、ブラウザーはプロキシサーバーを介して直接tcp接続を受信します。このサーバーでは、すべてのデータを完全に転送できます。 また、プロキシサーバーは、ブラウザで確立されたtcp接続から、CONNECTメソッドで指定されたホストで確立されたtcp接続への正確なデータ転送、およびそれに応じた逆転送のみを処理します。

透明なプロキシが使用される場合、つまり ブラウザーがプロキシサーバーの存在を疑わない場合、ブラウザーはそのデータをそれほど美しく準備しません。 そして、プロキシサーバーはそれについて考える必要があります。

HTTPの透過プロキシを図式的に見てみましょう。



もちろん、ポート3128でパケットを受信するプロキシがGoogleにそれ以上転送せず、Googleとの新しい接続を作成するなど、不正確な点もありますが、一般的に、相互作用スキームはほぼ次のとおりです。 この図は、NATが意図されていないプロキシサーバーにパケットの転送を開始することを示しており、NATは誰に同じように送信するかを知る必要があります。 HTTPトラフィックの場合、一部のプロキシはHTTPリクエストヘッダーのHOSTフィールドからの情報を不正に使用し始め、仕様に違反します。 もちろん、ほとんどの場合、HOSTには要求の宛先となるホスト名が正確に含まれていますが、一般的な場合、HOSTには何でも含めることができます。 HTTPSの場合、このようなソリューションはまったく適していません。 パケットの宛先を特定するために、プロキシサーバーがNATを調べてデータの宛先を確認し、問題がないソリューションがすぐに発生します。 それが実際に行うことです。

残念ながら、iptablesはiptables自体では有用ではありませんが、それでも、その操作の基本原則は十分に理解されています。 概略的には、次のようになります。



意図した目的のためには、小さなカーネルモジュール（Module Shifter）を記述し、ユーザー空間に小さなソフトウェアレイヤー（Shifter）を実装して、モジュールと対話し、プロキシサーバーのデータを準備します。

クライアント-サーバーアプリケーション（シフター）

Shifterと呼ばれる小さなクライアントサーバーアプリケーションを作成します。 シフターはそのポートでハングし、誰かが彼とのtcp接続を確立すると、プロキシサーバーとのtcp接続を作成し、CONNECT（HTTP）メソッドを送信します。その後、彼はこれら2つの接続間の正確なデータ転送のみを処理します。 クライアントまたはプロキシがそれとの接続を閉じると、このソケットのペアが閉じられます。

CONNECTメソッドを送信するには、クライアントが実際に接続を確立したいリモートホストのIPアドレスが必要です。 この情報を取得するために、ShifterはNetlinkライブラリを使用してModule Shifterに連絡します。 これについては、この記事の最後の部分で説明します。

このアプリケーションでは、プロキシサーバーについて何も知らないクライアントからデータ（HTTPS）を受信するためにプロキシサーバーを準備します。 ソケットについて詳細に記述されているリソースは多数あるため、ここでは、詳細なコメント付きのShifterソースコードの一部へのリンクのみを提供します 。

カーネルモジュールシフター

カーネルモジュールとは何かを調べるには、たとえば、 Linuxでのカーネルモジュールの操作を読んでください。 モジュールの作成を始めましょう。 最初に、モジュールがカーネルにロードされるときに一度発生するモジュールの初期化を実行する必要があります。 また、モジュールがカーネルからアンロードされるときに過去の存在の不要なトレースを残さないように、モジュールの正しいシャットダウンも実行する必要があります。 これらの目的のために、ライブラリ<linux / module.h>：<linux / init.h>には2つのマクロmodule_initおよびmodule_exitがあり、この目的の関数名をパラメーターとして受け取ります。 また、名前を永続化するためのマクロMODULE_AUTHOR 、 MODULE_DESCRIPTION 、 MODULE_LICENSEもあります:)ライブラリ<linux \ kernel.h>：<linux \ printk.h>には非常に便利な出力関数int printk（const char * fmt、...）もあります 。 通常のprintf（..）と大差ありません。 モジュールはカーネル内にあり、コンソールでは起動されないため、メッセージはログに表示されます（ dmesgコマンドを使用して表示できます）。 さまざまなタイプのメッセージを表示できます。

 #define KERN_EMERG "<0>" /* system is unusable */ #define KERN_ALERT "<1>" /* action must be taken immediately */ #define KERN_CRIT "<2>" /* critical conditions */ #define KERN_ERR "<3>" /* error conditions */ #define KERN_WARNING "<4>" /* warning conditions */ #define KERN_NOTICE "<5>" /* normal but significant condition */ #define KERN_INFO "<6>" /* informational */ #define KERN_DEBUG "<7>" /* debug-level messages */ #define KERN_DEFAULT "<d>" /* Use the default kernel loglevel */
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、最初のモジュールのスケルトンを作成するためのすべての情報が得られました。

 #include <linux/module.h> #include <linux/kernel.h> MODULE_AUTHOR("Denis Dolgikh <sindo@sibmail.com>"); MODULE_DESCRIPTION("Module for the demonstration"); MODULE_LICENSE("GPL"); int Init(void) { printk(KERN_INFO "Init my module\n"); printk("Hello, World!\n"); return 0; } void Exit(void) { printk(KERN_INFO "Exit my module\n"); } module_init(Init); module_exit(Exit);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてをコンパイルして実行する方法についてもう少し説明します。 Ubuntu 11.10（x86）Kernel 3.0をインストールしたとすぐに言います。

システムには、ディレクトリ/ lib / modules / [カーネルバージョン] /があり、対応するカーネルバージョンのモジュールが含まれています。 ビルドもあります-これは、 / usr / src / linux-headers- [カーネルバージョン] /ディレクトリにあるカーネルライブラリのヘッダー（カーネルヘッダー）へのシンボリックリンクです。 カーネルヘッダーがまだない場合は、ダウンロードする必要があります（ sudo apt-get install linux-headers- [カーネルバージョン] ）。 現在作業しているカーネルのバージョンを確認するには、 uname –rコマンドを実行します。 現在のカーネルのバージョンとは異なるバージョンのライブラリを使用する場合、そのようなコンパイルされたモジュールは正常に動作するか、せいぜい起動しない可能性があります。 それはすべて、カーネルでどのような変更が発生したか、およびモジュールでどの機能を使用するかによって異なります。

モジュールをコンパイルするには、 Makefileを作成します。 2つの目標を作成しましょう： all （モジュールの構築）とclean （プロジェクトの掃除）、それらを書くために、既に書かれた目標を使用します ： modulesとkernel-headersの Makefileで 掃除します 。

 #        # module_test.o – ,       module_test. obj-m += module_test.o #  Makefile  kernel-headers   -, #     /lib/modules/[ ]/build #     modules      obj-m # M=$(PWD)   ,      all: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules clean: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、 makeコマンドを使用してモジュールを簡単にコンパイルし、 make cleanプロジェクトをクリーンアップできます。 その結果、完成したモジュールmodule_test.koを取得します。これは、 insmod ./module_test.koコマンドを使用してカーネルにすぐにロードできます。 modprobe module_testコマンドを使用して、カーネルにモジュールをロードする別のオプションがあります。 これを行うには、モジュールmodule_test.koモジュールを/ lib / modules / [カーネルの現在のバージョン] / [任意のディレクトリ] /ディレクトリに 置き 、忘れずにdepmodを実行します 。 このコマンドは、 / lib / modules /にモジュールの依存関係のリストを作成します 。 モジュールに依存関係がない場合でも、 modprobeはdepmodなしでは追加されたモジュールを認識しません。 insmodとmodprobeの主な違いは次のとおりです。モジュールをロードすると、 modprobeは依存するすべてのモジュールを自動的にロードしますが、 insmodは任意のディレクトリからモジュールをロードできます。 カーネルからモジュールを削除します： rmmod module_test 。 モジュール情報の表示： modinfo module_testまたはmodinfo ./module_test.ko

Netfilterライブラリ

そして、HTTPSのプロキシに戻ります。 私たちのタスクは、モジュールがDNAT（iptables）によって処理される前にネットワークパケットをスキャンすることです。 このために、 Netfilterライブラリが役立ちます。 （より詳細な理解のために、少なくともWikipediaで他のソースのNetfilterについてさらに読むことをお勧めします）カーネル内のネットワークパケットパスがどのように見えるかを考慮してください。



詳細はこちらをご覧ください 。

Netfilter <linux / netfilter.h>は、5つの異なる場所でネットワークパケットへのアクセスを提供する5つのフック関数を提供します。

1. NF_INET_PRE_ROUTING-関数は、パケットがすでに単純なチェックに合格する前に、すべての入力パケットを完全にキャッチします（パケットは失われません、IPチェックサムはOKなど）。
   
   その後、パケットはルーティングを通過し、パケットが別のインターフェイス用であるかローカルプロセス用であるかが決定されます。 ルーティングできない場合、ルーティングはパケットを破棄できます。
2. NF_INET_LOCAL_IN-パッケージをローカルプロセスに渡す場合、パッケージを渡す前に呼び出されます。
3. NF_INET_FORWARD-パケットがあるインターフェースから別のインターフェースにルーティングされるとき。
4. NF_INET_LOCAL_OUT-ローカルプロセスを作成するパッケージのトラップ。
5. NF_INET_POST_ROUTING-ネットワークカードドライバーにパケットを送信する前の最終ポイント。

カーネルモジュールは、これら5つの場所のいずれかにその機能を登録できます。 登録するとき、モジュールはこの場所での機能の優先順位を示す必要があります。 <linux / netfilter_ipv4.h>ライブラリで、さまざまな標準タスクの優先順位を確認できます。

 enum nf_ip_hook_priorities { NF_IP_PRI_FIRST = INT_MIN, NF_IP_PRI_CONNTRACK_DEFRAG = -400, NF_IP_PRI_RAW = -300, NF_IP_PRI_SELINUX_FIRST = -225, NF_IP_PRI_CONNTRACK = -200, NF_IP_PRI_MANGLE = -150, NF_IP_PRI_NAT_DST = -100, NF_IP_PRI_FILTER = 0, NF_IP_PRI_SECURITY = 50, NF_IP_PRI_NAT_SRC = 100, NF_IP_PRI_SELINUX_LAST = 225, NF_IP_PRI_CONNTRACK_CONFIRM = INT_MAX, NF_IP_PRI_LAST = INT_MAX, };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リストからDNATの優先度は-100であることがわかります。したがって、-100未満の優先度が目的に適しています。 関数の優先度が-100より大きい場合、宛先IP（宛先）がすでに変更されたパケットを受信します。

5つのポイントのいずれかで登録された各関数は、転送されるパケットのさらなる運命を決定する次の値のいずれかを返す必要があります。

 #define NF_DROP 0 /* discarded the packet */ #define NF_ACCEPT 1 /* the packet passes, continue iterations */ #define NF_STOLEN 2 /* gone away */ #define NF_QUEUE 3 /* inject the packet into a different queue (the target queue number is in the high 16 bits of the verdict) */ #define NF_REPEAT 4 /* iterate the same cycle once more */ #define NF_STOP 5 /* accept, but don't continue iterations */
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私の無料翻訳では、このように聞こえます：

• NF_DROP-このパッケージを削除
• NF_ACCEPT-パケットはさらに進んで、繰り返しが続きます
• NF_STOLEN-このパッケージを削除します（カーネルはそれを処理しなくなります。モジュール自体はこのパッケージに割り当てられたメモリを解放する必要があります）
• NF_QUEUE-パケットをキューに入れる （通常はユーザー空間でパケットを処理するため）
• NF_REPEAT-反復を繰り返します（同じパッケージで関数を再度呼び出します）
• NF_STOP-パケットをさらにスキップしますが、反復を続行しません

この場合、反復とは、機能から機能へのパッケージの移行を指します。 ある時点で、多くの機能を登録でき、順番に優先順位を付けることができます。



私たちは理論を理解し、今ではモジュールを書き続けています。 モジュールをカーネルにロードするとき、関数を登録する必要があります。それをHook_Funcと呼びましょう。これはすべての着信パケットを調べ、最後にこの関数を登録解除する必要があります。そうしないと、カーネルは存在しない関数を呼び出そうとします。

 #include <linux/module.h> #include <linux/kernel.h> #include <linux/netfilter.h> #include <linux/netfilter_ipv4.h> /*       ip  */ struct nf_hook_ops bundle; int Init(void) { printk(KERN_INFO "Start module Shifter\n"); /*     hook  */ /*   ,     */ bundle.hook = Hook_Func; /*    ,  hook */ bundle.owner = THIS_MODULE; /*    */ bundle.pf = PF_INET; /* ,       */ bundle.hooknum = NF_INET_PRE_ROUTING; /*       */ bundle.priority = NF_IP_PRI_FIRST; /*  */ nf_register_hook(&bundle); return 0; } void Exit(void) { /*    hook  */ nf_unregister_hook(&bundle); printk(KERN_INFO "End module Shifter\n"); } module_init(Init); module_exit(Exit);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

あとは、 Hook_Func関数自体を記述するだけです 。 次のプロトタイプが必要です。

 unsigned int Hook_Func(uint hooknum, struct sk_buff *skb, const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *) ) { /*    firewall */ /*    ()     :) */ return NF_DROP; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのパラメーターを考慮してください。

• uint hooknumには、次の値のいずれかが含まれます： {NF_INET_PRE_ROUTING = 0、NF_INET_LOCAL_IN = 1、NF_INET_FORWARD = 2、NF_INET_LOCAL_OUT = 3、NF_INET_POST_ROUTING = 4} 。 このパラメーターは、関数の呼び出し元を見つけるために必要です。なぜなら、 同じ機能を複数の場所に登録できます。
• struct sk_buff * skbパッケージ構造へのポインター。
• 入力インターフェースに関する情報のconst struct net_device * 。 発信パケットの場合、パラメーターはNULLです。
• const struct net_device *出力インターフェイスに関する情報。 着信パケットの場合、パラメーターはNULLです。
• int（* okfn）（struct sk_buff *）は、すべての反復が正の答えを返すときにパッケージとともに呼び出されるコールバック関数です。

パッケージstruct sk_buff * skbへのポインターについて詳しく説明します。

sk_buffは、パッケージを操作するためのバッファーです。 パケットが到着するか、送信する必要があるとすぐに、sk_buffが作成されます。パケットが配置される場所、および関連情報、場所、場所、目的...パケットの移動中、ネットワークスタックでsk_buffが使用されます。 パケットが送信されるか、データがユーザーに転送されるとすぐに、構造が破壊され、メモリが解放されます。

sk_buff構造は<linux / skbuff.h>で説明されています。また、快適な作業のためのさまざまな関数も説明されています。

tcpを使用する場合、さらに2つの構造体を使用できます。これらはstruct iphdrとstruct tcphdrです。

名前が示すように、これらの構造はIPヘッダー 、したがってTCPヘッダーで機能するように設計されています 。 2つの関数を使用して、これらの構造体へのポインターをskb_buffから取得できます。

 static inline unsigned char *skb_network_header(const struct sk_buff *skb); static inline unsigned char *skb_transport_header(const struct sk_buff *skb);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この時点で、読者にアピールしたいと思います。 sk_buff構造体でtransport_headerポインターを設定する必要があるのは正確には明確ではありませんでした。 ポイントNF_INET_PRE_ROUTINGおよびNF_INET_LOCAL_IN （優先度を指定） では 、 skb_transport_headerを使用してtcpヘッダーの構造を取得できませんでしたが、他のポイントでは正常に機能しました。 void skb_set_transport_header（skb、offset）を使用して、 sk_buff->データポインターからtransport_headerのオフセットを手動で指定する必要がありました。

前述のsk_buff->データポインターは、パッケージの内容へのポインターです。 イーサネットプロトコルの後のメモリ領域を指します。たとえば、すぐにIPヘッダー構造を指し、その後にTCPヘッダー構造または独自のプロトコルが続きます。

パッケージ自体のデータへのポインターはどこでも使用されるため、さまざまなフィールドを読み取るだけでなく、それらを変更することもできます。 ただし、たとえば送信者または受信者のIPアドレスを変更する場合、IPパケットヘッダーのチェックサムも再計算する必要があることに注意してください。

したがって、ポート443（HTTPS）に行き、クライアントがHTTPSプロトコルのTCP接続を確立したいというSYNフラグを含むIP-TCPパケットを検出した場合にのみ、関数は宛先IPアドレスを保存します。 また、TFTP接続が切断され、このIPアドレスが不要になったことを示すFINまたはRSTフラグを含むパケットが表示されたら削除します。

 #include <linux/skbuff.h> #include <linux/ip.h> #include <linux/tcp.h> #define uchar unsigned char #define ushort unsigned short #define uint unsigned int /* Hook_Func - ,       */ /*  IP  ,  : */ /* -  tcp  */ /* -   443  (HTTPS) */ /* -   SYN ( tcp ) */ uint Hook_Func(uint hooknum, struct sk_buff *skb, const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *) ) { /*      ip   */ struct iphdr *ip; /*      tcp   */ struct tcphdr *tcp; /*    IP  */ if (skb->protocol == htons(ETH_P_IP)) { /*      IP */ ip = (struct iphdr *)skb_network_header(skb); /*    IP  4   TCP  */ if (ip->version == 4 && ip->protocol == IPPROTO_TCP) { /*        TCP  */ /* ip->ihl -  IP   32-  */ skb_set_transport_header(skb, ip->ihl * 4); /*      TCP */ tcp = (struct tcphdr *)skb_transport_header(skb); /*     443  (HTTPS) */ if (tcp->dest == htons(443)) { /*    SYN,   IP   */ if (tcp->syn) AddTable((uint)ip->saddr, (ushort)tcp->source, (uint)ip->daddr); /*    FIN  RST,    IP   */ if (tcp->fin || tcp->rst) DelTable((uint)ip->saddr, (ushort)tcp->source, (uint)ip->daddr); } } } /*     */ return NF_ACCEPT; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

AddTableとDelTableの 2つの関数があり、送信者のIPとポートごとに、受信者のIPアドレスをメモリから保存および削除する必要があります。 これは、ShifterクライアントサーバーがShifterモジュールと通信し、 ReadTable関数を使用して、クライアントのIPとポートによって、どのIPアドレスに実際に連絡したいかを見つけるために必要です。 IPを保存するためのデータ型についてはあまり考えず、基本的なハッシュ関数を使用して通常の静的配列を使用しました。 ハッシュ関数（ KeyHash ）は、送信側ポートと入力での入力を受け取り、宛先IPアドレスが格納されている配列のインデックスを返します。 クライアントがnatの背後にあり、255.255.255.0のマスクを持つサブネットを持っていることを考慮して記述されているため、送信者のIPの最後のバイトのみを使用し、このバイトには2つのポートバイトの3ビットが重畳されています。 その結果、配列をサイズ0x1FFFFF（〜8 Mb）に圧縮することができました。 もちろん、カーネルにロードした後、このモジュールが少なくとも8 MBのメモリを占有することを考慮する必要があります。これは、一部の組み込みシステムにとっては大きすぎる可能性があります。 そして、衝突を忘れないでください:)しかし、私のデモでは、これはすべて単純さで報われ 、さらに、 DelTableは一般に空です。

 /*     IP   */ #define MaxTable 0x1FFFFF uint Table[MaxTable]; /* KeyHash -     */ /*    IP    */ uint KeyHash(uint src_IP, ushort src_Port) { return (uint)(((src_IP & 0xFF000000) >> 11) ^ (uint)src_Port) % MaxTable; } /* AddTable -  IP     */ /*     IP    */ void AddTable(uint src_IP, ushort src_Port, uint dst_IP) { Table[KeyHash(src_IP, src_Port)] = dst_IP; } void DelTable(uint src_IP, ushort src_Port, uint dst_IP) { /*         IP  */ /*      */ } /* ReadTable -  IP   */ /*    IP    */ uint ReadTable(uint src_IP, ushort src_Port) { return Table[KeyHash(src_IP, src_Port)]; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、記事のこの長い部分は終了し、ShifterクライアントサーバーとShifterカーネルモジュールを接続するためだけに残ります。

ユーザー空間からのカーネルモジュールとの相互作用（Netlink）

ここでの目標は、ShifterおよびShifterモジュールに1つのソケットを作成し、それらを接続することです。モジュールとShifterサーバー間の交換プロトコルは簡単です。シフターは4バイトのクライアントIPと2バイトのクライアントポートを送信し、モジュールはテーブルから取得した4バイトのIP宛先で応答します。これを行うには、Netlinkライブラリを使用します。

私は注意したいという見出しは<linux / netlink.h>カスタムアプリケーションのための /usr/include/linux/netlink.h とカーネルモジュール は/ usr / src / linuxに、ヘッダなど [ カーネルバージョン] / / linuxに/ネットリンクが含まれています。 hに は多くの違いがあります。

ユーザー空間のネットリンク

ネットリンクについては、ネットワークのユーザー空間側に多くの情報があります（たとえば、

RFC 3549-IPサービスのプロトコルとしてのLinux Netlink）

。 パート1

netlinkを使用したLinuxネットワークインターフェイスの簡単なモニター

したがって、ここでは、カーネルモジュールとユーザー空間プログラム間の情報交換を保証するために必要なものについてのみ説明します。

Netlinkソケットは、通常の関数int socket（PF_NETLINK、socket_type、netlink_family） によって作成されます。

どことsocket_typeには、として使用することができSOCK_RAWとSOCK_DGRAM。これにもかかわらず、netlinkプロトコルはデータグラムとrawソケットを区別しません。また、netlink_familyは、通信用のカーネルモジュールまたはネットリンクグループを選択します。<linux / netlink.h> 、次のことができ、家族の完全なリストを表示します。

Netlinkメッセージは、1つ以上のnlmsghdr（netlinkメッセージヘッダー）ヘッダーを持つバイトのストリームです。バイトストリームにアクセスするには、NLMSG_ *マクロのみを使用します。また、netlinkプロトコルは保証されたメッセージ配信を提供しないことに注意してください。十分なメモリがないか、他のエラーが発生した場合、プロトコルはパケットをドロップする可能性があります。

考えてみましょうsockaddr_nl構造、のnlmsghdr（<linuxの/ netlink.h> ）、IOVECとのmsghdr（は<sys / socket.h>に）、動作します：



構造体sockaddr_nlを -ユーザープログラムとカーネルモジュールのためのネットリンクアドレスを記述します。この構造は、データの送信者または受信者を記述するために使用されます。

 struct sockaddr_nl { sa_family_t nl_family; /*   AF_NETLINK */ unsigned short nl_pad; /*   */ __u32 nl_pid; /*     0,    ,     */ __u32 nl_groups; /* netlink  32 multicast-. nl_groups    ,         ,      */ };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

struct nlmsghdrはネットリンクメッセージヘッダーであり、送受信されたデータは構造体の直後のメモリにあります。NLMSG_DATA（struct nlmsghdr *）マクロを使用してアクセスします。

 struct nlmsghdr { __u32 nlmsg_len; /*      */ __u16 nlmsg_type; /*   () */ __u16 nlmsg_flags; /*     */ __u32 nlmsg_seq; /*   (      ) */ __u32 nlmsg_pid; /*   (PID),   */ };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

struct iovec - msghdrにあり、nlmsghdr構造体へのポインタを含みます。

 struct iovec { void * iov_base; /*    (  nlmsghdr) */ size_t iov_len; /*  ()  */ };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

struct msghdr-アドレス（sockaddr_nl）およびデータ（iovec）へのポインターを含む

 struct msghdr { void * msg_name; /*     */ socklen_t msg_namelen; /*   */ struct iovec * msg_iov; /*    */ size_t msg_iovlen; /*   */ void * msg_control; /*      */ size_t msg_controllen; /*     */ int msg_flags; /*    */ };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いくつかのNetlinkマクロを検討してください。

 int NLMSG_ALIGN(size_t len);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ネットリンクメッセージサイズを最も近い境界整列値に丸めます。

 int NLMSG_LENGTH(size_t len);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データフィールドのサイズをパラメーターとして取得し、nlmsghdrヘッダーのnlmsg_lenフィールドに書き込むための境界整列サイズ値を返します。

 int NLMSG_SPACE(size_t len);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

nlmsghdr構造体が占有するメモリのサイズ（バイト単位）と、netlinkパケットの指定されたlen長のデータ（バイト単位）を返します。

 void *NLMSG_DATA(struct nlmsghdr *nlh);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

渡されたnlmsghdrヘッダーに関連付けられたデータへのポインターを返します。

 struct nlmsghdr *NLMSG_NEXT(struct nlmsghdr *nlh, int len);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

多くの部分で構成されるメッセージの次の部分を返します。このマクロは、マルチパートメッセージで次のnlmsghdrヘッダーを受け入れます。呼び出し側アプリケーションは、現在のnlmsghdrヘッダーのNLMSG_DONEフラグを確認する必要があります。メッセージが処理されるときに、関数はNULLを返しません。2番目のパラメーターは、メッセージバッファーの残りの部分のサイズを設定します。マクロは、メッセージヘッダーのサイズだけこの値を減らします。

 int NLMSG_OK(struct nlmsghdr *nlh, int len);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メッセージが切り捨てられておらず、その逆アセンブリが成功した場合、TRUE（1）を返します。

 int NLMSG_PAYLOAD(struct nlmsghdr *nlh, int len);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

nlmsghdrヘッダーに関連付けられているデータのサイズを返します。



Netlinkを備えたShifterサーバーのソースコードの一部。

Netlinkカーネルスペース

カーネルモジュールでnetlinkライブラリを使用する場合、いくつかの違いがあります。たとえば、<linux / netlink.h>のnlmsghdr構造は同じままですが、すでにおなじみのsk_buff構造にラップされています。また、ソケットを操作するための通常の関数の代わりに、新しい関数セットを使用します。それらのいくつかを考えてみましょう。

モジュールでは、ソケットはint型ではなく、<net / sock.h>のsock構造によって表されます。struct sock-非常に大きいので、説明は必要ありませんが、説明はしません。

netlinkソケットを作成するために、<linux / netlink.h>にはnetlink_kernel_create関数があります。netlinkソケットを作成するだけでなく、データが到着するたびに呼び出される関数を登録します。

 struct sock *netlink_kernel_create( struct net *net, int unit, unsigned int groups, void (*input)(struct sk_buff *skb), struct mutex *cb_mutex, struct module *module);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

netlinkソケットを閉じて「関数登録」を削除するには、次を使用します。

 void netlink_kernel_release(struct sock *sk);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、<net / netlink.h>の関数も必要になります。ここでは、すばらしい説明のある関数を見つけることができます。

必要な機能の一部を翻訳します。

 /** * nlmsg_new –     netlink  * @payload:    * @flags:     * *  NLMSG_DEFAULT_SIZE,      */ static inline struct sk_buff *nlmsg_new(size_t payload, gfp_t flags) { return alloc_skb(nlmsg_total_size(payload), flags); } /** * nlmsg_put -    NetLink  skb  * @skb:     netlink  * @pid:   * @seq:    * @type:   * @payload:    ( ) * @flags:   * *  NULL,   skb    , *        netlink , *    netlink  */ static inline struct nlmsghdr *nlmsg_put(struct sk_buff *skb, u32 pid, u32 seq, int type, int payload, int flags) /** * nlmsg_unicast –   netlink  * @sk: netlink  * @skb:    netlink  * @pid: netlink    */ static inline int nlmsg_unicast(struct sock *sk, struct sk_buff *skb, u32 pid) /** * nlmsg_data –      * @nlh:  netlink  */ static inline void *nlmsg_data(const struct nlmsghdr *nlh) { return (unsigned char *) nlh + NLMSG_HDRLEN; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Module Shifterを追加します。

おわりに

結論として、プロキシサーバーにパケットをリダイレクトするには、ゲートウェイのiptablesにルールを追加するだけで十分だと思います。

 #   nat   (-A)   PREROUTING #   tcp    443    443  iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 443
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Shifterソースを含むアーカイブをダウンロードする

終わり。

使用された有用な文献

NetFilter.org

Linux、カーネル、ファイアウォール

カーネルコーナー-Netlink Socket

RFC 3549 を使用する理由と方法-IPサービスのプロトコルとしてのLinux Netlink はLinux上のNetLinkと連携し

ます。 パート1

Linux netlinkプロトコル