web-dev-qa-db-ja.com

接続されたユーザー間で帯域幅を均等に共有するファイアウォールディストリビューション

まず、私の状況について説明します。

中央のx86サーバー/ファイアウォール、5つのアクセスポイント、およびその間に2つの管理されていないルーターで構成されたネットワークがあります。

20メガビットのダウンロードと1メガビットのアップロードADSL。
電子メールの添付ファイルをアップロードする単一のユーザーがネットワーク全体のクロール速度を低下させる可能性があるため、アップロードは特に問題があります。

私が必要としているのは、接続されたデバイス間でアップロード速度を均等に分割する方法です。自動的に調整されたらいいのに

  • 5人の接続ユーザー->それぞれがアップロード帯域幅の1/5を取得
  • 10人の接続ユーザー->それぞれがアップロード帯域幅の1/10を取得

私が欲しいもの:

  • 接続されたユーザー間で利用可能な帯域幅を均等に分割できるx86サーバーディストリビューション
  • gUIツールは完璧でしょう

避けたいこと:

  • ポートに基づくトラフィックの優先度(私が目指しているものではありません)
  • 各デバイスにインストールするプログラム(私はそれを行うことはできません)

トラフィックがアクセスポイントから入ってくることを覚えておいてください。これが機能するために特別なソフトウェアが必要かどうかはわかりません。可能であれば、サーバー上で動作したいと思います。

2
user39436

OpenBSDを使用することを強くお勧めします。あなたが問い合わせているタスクは、もともとFreeBSDから移植され、PFに統合されたALTQ(ALTernate Queuingフレームワーク)によって行われます。幸いなことに、OpenBSDは独自のキューイングフレームワークを取得しようとしています(テスト段階です)。 pfSenseの使用をお勧めしません。 pfSenseは、フィルタリングにOpenBSDパッケージフィルター(略してPF)を使用するFreeBSDベースのディストリビューションです。たとえばOpenSSHとは異なり、PFは移植性がなく、その機能はネットワークスタックに依存します。 pfSenseとFreeBSDに同梱されているPFのバージョンは、3年で廃止され、FreeBSDカーネルとネットワークスタックの機能が不足しているため、完全には機能していません。面白いことに、ALTQはデフォルトでFreeBSDカーネルにロードされていませんでした。 FreeBSDを使用している場合は、FreeBSDのデフォルトファイアウォールであるIPFWを使用してください。 FreeBSDはIPfilterもサポートしています。 IPFWはLinuxのIPTablesのベースとして使用され、約1年前まで、OSXが最新バージョンのPFに切り替わったときのOSXのデフォルトファイアウォールでした。 OpenBSDが気に入らない場合は、マルチコアマシン用に独自のNPF最適化を取得したNetBSDを使用してください。 NPFでキューイングがどのように行われるのかわかりません。

また、何かを始める前に、キューイングについて学ぶことをお勧めします。キューイングがアウトバウンド方向のパケットにのみ役立つことに驚かれるかもしれません。パケットがインバウンド方向のインターフェイスに到着すると、キューに入れるにはすでに遅すぎます。パケットを受信したばかりのインターフェイスに到達するには、ネットワーク帯域幅がすでに消費されています。唯一の解決策は、隣接ルーターでキューイングを有効にするか、パケットを受信したホストがルーターとして機能している場合は、パケットがルーターを出る内部インターフェイスでキューイングを有効にすることです。したがって、あなたの場合、OpenBSDボックスは、ユーザーを管理できるようにするためのルーターとして機能する必要があります。

GUIの時点で、ファイアウォールを構成するためにGUIが必要な場合、ファイアウォールを構成するビジネスはおそらくありません。ポートを使用しないキューイングのリクエストの時点で、ALTQのドキュメントに戻って、さまざまなキューイング方法について学習するように指示します。

1

pfSense をお勧めします。ホームページから:

pfSenseは、ファイアウォールおよびルーターとして使用するために調整されたFreeBSDの無料のオープンソースカスタマイズディストリビューションです。強力で柔軟なファイアウォールおよびルーティングプラットフォームであることに加えて、関連する機能の長いリストとパッケージシステムが含まれているため、基本ディストリビューションに肥大化や潜在的なセキュリティの脆弱性を追加することなく、さらに拡張できます。

機能ページもご覧ください。

1
Marco