Linuxベースのアクセス制御

宣言後にiptablesはありませんか？原理図と検索式のバランスの意味の並列実行の実行アクセス制御について、人々は多くのプログラムについて議論しましたが、しませんある種の計画は普遍的であり、そのようなことはないと私は感じます。 RBACはマクロプロトコルスタックのオペレーティングシステム（UNIX、Linuxなど...以前の記事でそれらを逆にしたかもしれません...）には適していませんが、これはすべての人々のメンバーではありません。私も含めて知っているつまり、パケットは「高速でクールな」スタイルのカーネルプロトコルスタック処理プロセスに準拠している必要があり、異なるパケットが異なる「ビジネスロジック」に属している可能性があるため、後続のパケットキューイングにつながることはありません。次のパケットで表されるビジネスロジックが、パケットが遅延するまでの時間を許容しすぎると考えることはできません。すべてのプロトコルに署名しますネットワークデバイスの場合、すべてのパケットが同じです。データストリームは同じです、デバイスはデータを転送するために生まれており、データの宛先はデバイスではありません。すべての中間デバイスは、TMDがクラウド、キャッシュを使用していない場合はいわゆるWEBアクセラレーションサーバーであり、それが詐欺です。ワイヤスピードフォワーディングの方が速いのは何ですか？いいえ！ CAO TMDのはありません。クライアントとサーバーの間にデバイスがある限り、それはTMDにレイテンシを追加します。したがって、中間デバイスを設計するときの目標は、遅延を大幅に減らすのではなく、制御可能な範囲内でできるだけ速くすることです。そのため、アプリケーション処理方法は適していません。プログラミングを理解していないネットワーク管理者の手に渡ることなく、誰かがネットワークケーブルを切断するだけで、TCPはあなたがそれを上品に送ることを保証することができません。すべてを決定するためにネットワークを制御できるFIN、ネットワークの効率性は、エンドツーエンドのプログラムの効率性よりも常に重要です。この記事の目的は、他の方法に関係なく、ローカル処理をできる限り確実に一方向で行えるようにすることです。土曜日の大雨の中で、興奮して、刺激しています！ネットワーク管理者やプログラマーにとって、Otto von Bismarckはそれが不幸で怒っているとしか言いようがないのかもしれません。 OpenSSLは理解できませんが、私はプログラマーです。

前回の記事「nf_conntrackに適用されるLinuxルーティングテーブルの抽象拡張」の後に、LinuxのIPルーティングメカニズムを使用してアクセス制御リスト、つまりLinux ACLを実装できることが指摘されました。これは実装の実現可能性を示しているだけですが、最後に、LinuxのIPルーティングメカニズムを使用して、nf_conntrackの情報文字列を保存しました。この記事では、実際にアクセス制御を実装する方法について詳しく説明します。

iptablesがありませんか？新しいメカニズムを実装する必要があるのはなぜですか？ 1.iptablesはNetfilterの実装に基づいているので、シリアルフィルタリング、すなわち一対一のマッチングしか実装できません; 2.マッチング速度はiptablesルールの設定順序に依存し、カーネル内で一様に最適化することはできません3. iptablesは好きではありませんNetfilterをベースにした並列バージョンを開発することは可能ですが、マルチコア時代には時代遅れですが、それは非常に困難です。したがって、上記の問題を解決するために、Netfilterに依存しない追加のアクセス制御メカニズムを実装することにしました。明らかに、私の目標の1つは、マッチングプロセス中に複数のコアをスケジュールできることです。

実装原理IPデータグラムに一連のアクセス制御メカニズムを実装するのは簡単なことではありませんが、最も基本的なフレームワークは非常に単純で、パケットの送信元IPアドレスと宛先IPアドレスに基づいています。このパケットで何ができるかを決めます。もちろん、IPアドレスに加えて、IPデータパケット内の任意のフィールドがマッチングに参加でき、TCP /UDPプロトコルヘッダーのフィールドでもマッチングに参加できますが、この記事では複雑な状況は含まれません。この記事の概念から拡張するのは簡単なので、この記事ではマッチング要素としてIPアドレスのみを使用します。 「nf_conntrackに適用されるLinuxルーティングテーブルの抽象拡張」で説明されているように、アクションはルーティングエントリに格納できますが、別の一致する要素のターゲットIPが導入されると、アクションはルーティングエントリに存在しなくなります。送信元IPアドレスと宛先IPアドレスに関連付けられたルーティングエントリ間のメディアは、送信元ルーティングエントリに含まれるすべてのIPアドレスが宛先ルーティングエントリに含まれるすべてのIPアドレスに対してアクションを実行できることを示します。アクションは、合格、拒否、アドレス変換など、可能性のあるすべてのアクションです。 2つのルーティング項目に関連付けられているアクションがない場合は、デフォルトのアクションが実行されます。 1つのアクションは2つのロールである必要があると想像できますが、一方ではソースルーティング項目のアクションリストに参加し、他方ではターゲットルーティング項目のアクションリンクリストに参加して2つを関連付けます。 RBAC許可モデルの用語を借りると、パケットの送信元IPアドレスを役割と見なすことができ、パケットの宛先IPアドレスをリソースと見なすことができますが、ここでは実際のRBACのほうが私より優れています。もっと複雑です。私のモデルは、ACLモデル自体ではなく、カーネルがACLとアルゴリズムを実装する方法を検討しているということです。データ構造は図よりもわかりやすいです。各アクションは両方のリンクリストに同時にリンクされているため、アクションの名前はXnodeにすることができます。

[plain] view plaincopyprint？01.struct nf_action_node {02. //struct list_head list; //andアルゴリズム関連、注1を参照03. struct hlist_node nf_dst; 04. struct hlist_node nf_src; 05. struct nf_fib_node * dst_node; //バックポインタ、アルゴリズムの最適化、検索アルゴリズムの節を参照06. struct nf_fib_node * src_node; //バックポインタint extra; 08. //int extra_len; 09. //char extra [0]; 10.}; struct nf_action_node {//struct list_head list; //アルゴリズムに関連した、参照：注意1 struct hlist_node nf_dst;