この記事では、特定のケースに対して選択された2つのアクセスポイントの比較テストの一部について説明します。 興味のある方は誰でも-猫の下のウェルカム。
ポイントモデル: Zyxel NWA1123-AC PROおよびUbiquiti UniFi AP AC PRO
両方のポイントは同じ価格帯にあり、同じ問題を解決するように設計されています。
テスト中に使用された補助機器の場合:
iperfサーバーは、ギガビットネットワークカードを備えた通常のデスクトップコンピューターです。 特別なことは何もありません。
wi-fiクライアントは、2番目のhp probook 430 g4ラップトップです。 5 GHz対応のwi-fiモジュール付き。
ルーター-c9アーサー。
テストベンチトポロジは可能な限り単純です。
機能テスト
私たちの手に渡るすべてのものは、標準プロトコルに従って実行されます。 私たちが依存している特定の開発があります。 TKごとに異なる点もありますが、基本的な機能はタスクに関係なく実質的に変更されていません。 重要なポイントがあり、それがないとすぐにネットワーク上のそのようなデバイスの使用が停止されます(たとえば、sshまたはsnmpがない場合)。また、オプションのポイントがあり、テスト結果を合計するときにデバイスの存在がプラスになります。 たとえば、コンソールポートの存在。 そこに-まあ、いや-まあ、本当に私が欲しかったものがありません。
コンソールといえば
Zyxelポイントで、コンソールポートへのアクセスがシャーシに行われます。
これは間違いなくプラスです。 Ubiquitiでは、コンソールポートはほとんどのメーカーと同じ場所にあります(これはまったく驚くべきことではありません-多くの人が行いますが、足すらありません)。
「通常のデバイスでは、原則としてコンソールポートへのアクセスは必要ないはずです」というトピックに個別にholivarを配置できますが、突然必要になるよりも優れていると思われる傾向があると信じています(避妊と同じように)。
これは間違いなくプラスです。 Ubiquitiでは、コンソールポートはほとんどのメーカーと同じ場所にあります(これはまったく驚くべきことではありません-多くの人が行いますが、足すらありません)。
「通常のデバイスでは、原則としてコンソールポートへのアクセスは必要ないはずです」というトピックに個別にholivarを配置できますが、突然必要になるよりも優れていると思われる傾向があると信じています(避妊と同じように)。
いくつかのポイントはありふれたものになりますが、残念ながら、実際にチェックする必要があります。 仕様に特定の機能のサポートが記載されており、これらの設定チェックボックスがウェブカメラにも存在するデバイスが複数回ありましたが、それらは機能しません。
たとえば、トラフィックの優先順位付け。 設定で必要なチェックマークをオンにし、トラフィックアナライザーでパケットの収集を開始します。実際、ヘッダーでは何も変更されていません。 悲しいです
この場合、両方のポイントが素晴らしい仕事をしました。 苦情はなく、必要な機能全体が実装されています。 なんとなく退屈。 これは、nslookup'aからの「セグメンテーションフォールト」を確認できる低セグメントピッキングではありません(はい、そのような場所がいくつかあります)。
機能リスト
1.マルチSSIDをサポートします。 異なるSSIDを持つ少なくとも2つのネットワークを上げる機能+隠れたネットワークを上げる機能。
2. 802.11iのサポート(セキュリティ、AES暗号化のサポート)。
3. 802.11q(タグ付きトラフィックを送信する機能)のサポート。
3. VLAN管理のサポート。
4.無線送信機の信号強度を変更する機能。
5. QOSおよび802.1p(トラフィックに優先順位を付ける機能)のサポート。
6.アクセスポイントに接続するクライアントの最大数を制限する機能。
7. telnet / ssh / webGUIによるポイント管理。
8. SNMPを介したアクセスポイントの監視と管理をサポートします。
9.集中/自律モードでポイントを機能させる能力。
10. LLDPディスカバリをサポートします。
11.ポイントには、システムイベントの内部ログと、ログをリモートサーバーに送信する機能があります。
12.ポイントでの内部トラフィックアナライザーの存在(オプションおよびオプション、ただし両方のポイントに存在)。
13.スペクトルアナライザの存在と、他のポイントの隣で機能するアクセスポイントを検出する機能。
2. 802.11iのサポート(セキュリティ、AES暗号化のサポート)。
3. 802.11q(タグ付きトラフィックを送信する機能)のサポート。
3. VLAN管理のサポート。
4.無線送信機の信号強度を変更する機能。
5. QOSおよび802.1p(トラフィックに優先順位を付ける機能)のサポート。
6.アクセスポイントに接続するクライアントの最大数を制限する機能。
7. telnet / ssh / webGUIによるポイント管理。
8. SNMPを介したアクセスポイントの監視と管理をサポートします。
9.集中/自律モードでポイントを機能させる能力。
10. LLDPディスカバリをサポートします。
11.ポイントには、システムイベントの内部ログと、ログをリモートサーバーに送信する機能があります。
12.ポイントでの内部トラフィックアナライザーの存在(オプションおよびオプション、ただし両方のポイントに存在)。
13.スペクトルアナライザの存在と、他のポイントの隣で機能するアクセスポイントを検出する機能。
主な機能を確認した後、何か面白いものを見つけても悪くありません。 特定の機能の存在だけでなく、「過剰」がないことも確認する必要があります。
両方のポイントでnmapを実行します。
ユビキティ
チクセル
次に、ftpの21番目の開いているポートが画面に表示されませんでした。
次に、ftpの21番目の開いているポートが画面に表示されませんでした。
両方のポイントでsshが開いています。これは良いことです。 ユビキティでは、sshだけがそれ以上のものではありません。 ハードコアのみ。 Zyxelでは-ftp、ssh、http(標準セット)および40713 / tcpで不明なもの。
後で判明したように、これは、Nebulaクラウドを介してアクセスポイント(アクセスポイントだけでなく、利用可能なその他の機器も)を管理するための集中型サービスです。 一般的に、ポイント自体のウェブカメラよりも気に入っています。 大まかに理解するためのいくつかのスクリーンショット(最初の縮尺は、すべてが適合するように特別に大幅に縮小されています):
Zyxelのデフォルトのログインとパスワードはポイントのどこにも指定されていないため、クラゲ(Kali linuxのブルート向けの標準ユーティリティ)を使用しました。 「admin / 1234」というユーザー名とパスワードのペアを取得しました。ユビキティからは、「ubnt / ubnt」という形式の標準ロゴがすでにわかっています。
この時点では、ユビキティにはウェブサーバーがありませんでした。 絶対に。 コントローラと特別なユーティリティを介した管理のみ。 / wwwフォルダは単に空であり、80/8080ポートで何も回転していません。 しかし、Zyxelとは異なり、ここでは少なくとも標準のbusybox(およびコマンドでは非常に無料)です。 左側にステップがあり、右側にステップがあります-実行。
両方の時点で、脆弱性スキャナー(Nessus)を通過しました。 彼は何も超臨界を示さなかった。 以下は、結果と見つかったものの詳細な説明です。
192.168.0.196-チクセル
192.168.0.126-ユビキティ
ユビキティ:
重大ではありません。 考慮-何も見つかりませんでした。
チクセル:
ここでは、簡単に言えば、もっと興味深いものです。古い安全でないバージョンのSSLと標準のパブリックsnmpコミュニティを使用します。設定では、起動時にすぐに変更することが提案されています。
tyk
- リモートサービスは、SSL 2.0またはSSL 3.0を使用して暗号化された接続を受け入れます。 これらのSSLバージョンは、いくつかの暗号化エラーの影響を受けます。
- X.509サーバー証明書は信頼できません。 このサービスのX.509証明書チェーンは、認証された認証局によって署名されていません。 リモートホストがパブリックホストの場合、誰でもリモートホストに対する中間者攻撃を設定できるため、SSLの使用が無効になります。
- リモートホストでIP転送が有効になっています。 攻撃者はこれを使用してパケットをホストにルーティングし、一部のファイアウォール/ルーター/ NACフィルタリングをバイパスする可能性があります。
- デフォルトのSNMPコミュニティ(パブリック)。
- SNMPデーモンは、GET-BULK要求に対して、max-repetitionsの通常の値よりも多くのデータで応答します。 リモートの攻撃者は、このSNMPサーバーを使用して、展開された分散型サービス不能攻撃を任意のリモートホストで実行する可能性があります。
負荷試験
まず、周りのネットワークを見てみましょう。 5 GHzの範囲のみを見ていきます。 スキャンには、アクリルを使用しましたが、ドット自体は、互いに干渉しないように、一度に1つずつ点灯しました。 さらに、実験の純度を高めるために、ルーターアダプターもオフにしました。
その結果、後で、より多くのテストを行う必要がありましたが、別のより平和な場所で、 最初のケースでは、誰かの企業ネットワークが、非常に広範囲のチャネルで、膨大な数のポイントから展開されました(下のスクリーンショットで見ることができ、多くは適合しませんでした)。
トラフィックは、5つのスレッドでiperfによって追跡されました。 最初は60分間テストしましたが、それが完全に有益ではないことに気付き、4時間負荷をかけました。
これがネタバレで下にあるもの:
ユビキティ
最大値:300 Mbps(この上限に達していないため、問題は発生しません)
最小値:228 Mbps
平均:296.5 Mbps
Cは安定性です。 常時接続が良好です。 短期的なドローダウンがありますが、重要ではありません。
勤務時間の統計:
(CPU黄色、青色-メモリ+トラフィック)
チクセル
最大値:584 Mbps
最小値:324 Mbps
平均:426 Mbps
しかし、CPU負荷は少し驚きました。
テストの開始時に、負荷は91%に跳ね上がりました。 この時点でポイントを使用するとき、特別な問題に気付きませんでした。ポイントは熱くならず、ウェブカメラは遅れず、パケット損失はありませんでした。
テストは可能な限り最大のパフォーマンスのためであり、これが完全に標準的な状況ではないという事実にもかかわらず、大量のトラフィックが長期間にわたって駆動される場合、そのようなケースがあります。 (「モバイル」クライアント用の大量のデータを持つサーバーへのアクセス)テストに合格したと思います。 いずれにせよ、質問はZyxelのサポートによって尋ねられ、現在この状況について交渉中です。
CPU /メモリ統計:
まとめ
中間結果を要約すると、Zyxelポイントは、必要なタスクの使用に関してはるかに魅力的に見えると言えます。 比較的同一の機能範囲で、選択は常に長期間にわたる安定性と、もちろんパフォーマンスのためです。
残念ながら、実験室のテストですべてを完全にカバーし、生産で発生する可能性のあるすべての状況をエミュレートし、すべてを予測することは不可能です。 したがって、両方のポイントは、条件に対処するために、できる限りネットワークでのフィールドテストを確実に待機します。