APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

Aiven VPCを使ったAzureとの閉域接続を試してみた

はじめに

こんにちは。ACS事業部)土居です。
先日Aivenについて紹介しましたが、今回はAivenのVirtual Private Cloud(以降VPCと呼びます。)を試してみます。
Aivenはデフォルトでサービスを作成すると、パブリックに公開にされます。 これは昨今のクラウドサービスを利用する上では当たり前な所ではありますが、昨今はセキュリティの観点もありリソースをそれぞれ閉域ネットワークに閉じる事で通信アクセスもプライベートに制限するケースも多いです。
また、AivenはOSSのデータプラットフォームなので、各パブリッククラウドで利用されているシステムから接続したり相互に連携することが前提であります。
データを取り扱うプラットフォームなので、当然その通信アクセス経路もデフォルトのパブリックではなくプライベートにしたいというニーズがあります。

前置きが長くなりましたが、AivenのVPCはAivenのサービスをパブリッククラウドの仮想ネットワークに作成するサービスです。利用ユーザー側の仮想ネットワークとPeeringができるので、システム側からもAivenサービスにプライベートなアクセスが可能になります。

docs.aiven.io

VPC上でAivenサービスを利用する

AivenのVPCをサービスで利用する流れとしては以下になります。

  1. AivenでVPCを作成する
  2. サービスを1.で作成したVPC上に展開する

今回はAzureでPostgreSQLを利用する想定で作成していきます。

まずはAivenコンソールで「VPC」-「Create VPC」を選択し、VPCを作成しましょう。

作成する際に、利用するパブリッククラウドとIPレンジを指定します。IPレンジはPeeringする予定の仮想ネットワークと被らないように注意しましょう。 今回は、Azureの東日本リージョンでIPレンジは「10.0.0.0/24」で作成します。

次はVPC上にPostgreSQLを作成します。「Services」-「Create Service」から作成していきましょう。 Azureのリージョン選択時に、先程作成したVPCが選択できるようになっていますので、VPCを選択してサービスを作成しましょう。

作成されたPostgreSQLですが、デフォルトではパブリックからのアクセスは許可されていません。

When you move your service to a VPC, access from public networks is blocked by default. docs.aiven.io

psql postgres://avnadmin:***********************@doi-test-**-****.aivencloud.com:19872/defaultdb?sslmode=require
psql: error: connection to server at "doi-test-**-****.aivencloud.com" (10.0.0.4), port 19872 failed: Connection timed out (0x0000274C/10060)
Is the server running on that host and accepting TCP/IP connections?

もしパブリックアクセスも許可したい場合は、「Advanced configuration」から「public_access.pg」を有効にすると、Access Routeに表示される「Public」のURIからアクセスできます。

Aiven VPCとAzureのVirtual NetworkをPeeringする

では、ここからAzure Virtual Networkを準備して、先程作成したAiven VPCとPeeringを設定します。Azure上のVirtual MachineからPostgreSQLにアクセスできるかどうか、Aivenのチュートリアルを参考に進めていきます。

docs.aiven.io

構成の全体像は下記のような形になります。
ポイントとしては、AivenのVPCはAiven社が所有しているAzureサブスクリプション上で管理されているため、テナントを跨いだVirtual NetworkのPeeringの設定が必要になる事です。 そのため、サービスプリンシパル(アプリケーション)をマルチテナントで利用できる形で発行し、必要なAzure権限を割り当てる必要があります。

  • まずは、自社のサブスクリプションにVirtual Network(aiven-test-nw)とVirtual Machineを作成します。

  • 次は赤枠のアプリケーションオブジェクトとサービスプリンシパルの作成を行っていきます。

Azure Active Directoryの「アプリの登録」から新規アプリの作成を行います。
※アプリの登録は、組織として許可されているか、アプリケーション管理者のRoleが必要になります。

適当な表示名を付け、アカウントの種類を「マルチテナント」に設定します。これは、アプリケーション(サービスプリンシパル)をAivenのサブスクリプションからも利用するためです。

アプリケーションの作成ができたら、サービスプリンシパルのクライアントシークレットを発行します。発行されたシークレットの値は必ずコピペしてメモっておきましょう。

  • 続いて、赤枠のアプリケーションオブジェクトとサービスプリンシパルを準備していきます。

以下コマンドを使って、グローバルに登録されているAivenアプリケーションオブジェクト(55f300d4-fc50-4c5e-9222-e90a6e2187fb)に対してサービスプリンシパルを設定します。

az ad sp create --id 55f300d4-fc50-4c5e-9222-e90a6e2187fb

サービスプリンシパルが作成されると、「Azure Active Directory」-「エンタープライズアプリケーション」の画面で、以下のようにaiven-prod-executorが表示されます。

  • 作成した2つのサービスプリンシパルにaiven-test-nwへの権限を付与していきます。

Aivenから利用するサービスプリンシパルへの権限付与は、できるだけ特定の機能に限定するほうがセキュリティ上好ましいです。 そのため、Azureの組み込みRoleではなくカスタムロールを利用します。
下記を参考に「サブスクリプション」-「アクセス制御(IAM)」-「カスタムロールを作成する」からPeeringのActionのみ実行できるRoleを作成しましょう。

カスタムロールの作成が完了したら、各サービスプリンシパルにaiven-test-nwをスコープに適切なRoleを付与します。

  • Aivenコンソールから、VPCのPeering設定を行います。

Aivenコンソールの「VPC」から作成したVPCを選択し、「VPC Peering connections」を設定します。

設定項目 設置値
Azure Subscription ID 自社のサブスクリプションIDを入力します
Resource Group aiven-test-nwが所属するResource Group名(aiven-test)を入力します
Network name aiven-test-nwを入力します
Active Directory tenant ID 自社のAzure Active DirectoryのテナントIDを入力します
Application Object ID ここには、作成したアプリケーションオブジェクト(aiven-vpc-app)のIDを入力します

Application Object IDaiven-vpc-appのIDを入力することで、Aiven側のテナントでも自動的にVPCへの権限を付与したサービスプリンシパルが作成されます。 これにより、サービスプリンシパルで複数テナントにアクセスすることが可能となります。

設定後、しばらく経過するとPeering connectionsのStatePending peerと表示されます。

ここで、Pending peerにカーソルを合わせると、Peeringの設定詳細を確認できます。 ここで表示される、Aiven tenant IDVPCのリソースIDは控えておきましょう。

  • 最後に、aiven-test-nw側からもPeeringの設定を行います。

aiven-test-nw側のPeeringを行うには、AivenのVPCとaiven-test-nwの両方を触れるように、作成したサービスプリンシパルにログインを行う必要があります。 発行したクライアントシークレットを使ってサービスプリンシパルにaz loginで各テナントにログインしましょう。

az login --service-principal -u <Service Principal Client ID> -p <Client Secret> --tenant <自社のtenant ID>
az login --service-principal -u <Service Principal Client ID> -p <Client Secret> --tenant <Aiven tenant ID>

両方のテナントにログインできたら、az network vnet peering createコマンドでPeeringの設定を行います。

az network vnet peering create --name <peering name> --remote-vnet <VPCのリソースID> --vnet-name aiven-test-nw --resource-groupaiven-test --subscription <自社のtenant ID> --allow-vnet-access

az network vnet peering createが正常に完了したら、 aiven-test-nwのピアリング状態が接続済み、VPCのPeering connectionsのStatePending peerからActiveに変更されます。 これでAivenのVPCとaiven-test-nwが正常にPeeringできました。

  • Virtual Machineから疎通確認を行います。

Virtual Machineからnslookupとpsqlを実行してみました。 無事Peeringされた閉域ネットワーク経路でアクセスされていることが分かります。

C:\Users\azureuser>nslookup
Default Server:  UnKnown
Address:  168.63.129.16

> doi-test-**-****.aivencloud.com
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
Name:    doi-test-**-****.aivencloud.com
Address:  10.0.0.4
C:\Program Files\PostgreSQL\15\bin>psql postgres://avnadmin:***********************@doi-test-**-****.aivencloud.com:19872/defaultdb?sslmode=require
psql (15.2, server 14.6)
WARNING: Console code page (437) differs from Windows code page (1252)
         8-bit characters might not work correctly. See psql reference
         page "Notes for Windows users" for details.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

defaultdb=>

おわりに

いかがだったでしょうか?AivenのVPCを利用すると、既存で利用しているシステムのネットワークとも柔軟な接続が可能です。
是非Aivenをお手元でも活用してみて下さい。

私達ACS事業部はAzureのクラウドネイティブ技術を軸に内製化のご支援をしております。ご相談等ありましたらぜひご連絡ください。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です!
切磋琢磨しながらスキルを向上できる、エンジニアには良い環境だと思います。ご興味を持っていただけたら嬉しく思います。

www.ap-com.co.jp

本記事の投稿者: 土居 幸平

JANOG46 Meeting in Okinawa で「自動化の下ごしらえ」という発表をしました

はじめに

技術開発部 自動化グループの横地です。

少し前のことですが、2020/08/26 ~ 28 にオンラインと沖縄で開催された、JANOG46 Meetingにて、「自動化の下ごしらえ」という発表をオンライン上でさせていただきました。

ネットワーク運用の自動化をご支援をしていく中でたまってきたナレッジを、コミュニティに還元したいと思って今回の発表にいたりました。

7つのポイント

既存のネットワーク運用作業の手順書を自動化する際に、どのようにすれば自動化しやすくなるかというポイントを以下の 7点にまとめてご紹介しました。

  1. 引く: 不要な手順を削除する
  2. 足す: 隠れ手順をあぶりだす
  3. 決める: 判断基準を明確に決める
  4. 分ける: 機械と人の役割を分ける
  5. 整える: フォーマットを整える
  6. 入れ替える: 順序を最適化する
  7. 戻す: あえてデグレ(オプション)

詳細は後述の動画や資料をご参照ください。

動画・資料

以下のページで 2020/10/19 13:00 まで、当日の動画のアーカイブが公開されています。

www.janog.gr.jp

また、資料は SlideShare にもアップしました。

www.slideshare.net

当日のディスカッションの時間では、ポイントに対応した具体的な事例なども情報をいただけました。

手順書をもとにして自動化するときにどうしたらよいか、そのヒントになれば幸いです。

参考

広報ブログ

JANOG46 Meeting にテクニカルエバンジェリスト横地が登壇しました | INSIDE APC

ExPing以外に使っているツールは無い?Windowsで使えるPing実行ツールを調べてみました。

本記事は下記URLに移動しました。
5秒後に自動的に移動します。

https://needlework.jp/article/exping

 

 

先進サービス開発事業部の内藤です。

ネットワークエンジニアなら誰でも1度は触れたことがあるツール「ExPing」。

2005年に更新が終了していますが、いまだに使わる続ける凄いツールです。

www.woodybells.com

 

私もネットワークエンジニアをやっていた10年間はPCに必ずインストールしていました。

最近、他部署とPingツールの話になりましたが、やはり皆さんExPingをつかっているみたい・・・。

 

他に使っているPing実行ツールはないのか?と疑問に思ったので、少し調べてみました。

※Windowsで使えるツールを探しました


Twitterアンケート結果

Twitterで募集した「Ping実行ツール何使ってる?」アンケート結果です。

Ping実行ツールアンケート結果

ExPingが圧倒的でした。

 

ExPing

自分はネットワーク構築後のテストで主に使っていました。

送信間隔 500ミリ秒、タイムアウト 500ミリ秒 がよく使う設定で、1回NGがあるとネットワーク断時間約1秒とみなしていました。

ネットワークエンジニア_ExPing

 

Ping実行画面。見てるとなぜか落ち着く・・・。

ネットワークエンジニア_ExPing

 

UIもわかりやすく、シンプルだけど必要な機能はそろってます。

これは長く使われますね。

pexpo

作業PCをWindowsからMacに変更してから使っていたツールです。

Windowsでも利用できます。以前 別の記事でも紹介しました。

techblog.ap-com.co.jp

 

こちらもシンプルで使いやすい。

Ping対象リスト(ping-list.txt)を作成して、コマンド実行するだけ。

pexpo -f ping-list.txt

NGだった箇所もわかりやすく、同じ画面に統計も表示されます。

Ping実行間隔とタイムアウト値もオプションで変更可能です。

ネットワークエンジニア_ExPing_pexpo

 

動作画面は公式ページに掲載されている動画のほうが見やすいです。

github.com

 

エビデンスはこんな感じです。こちらもシンプルで良いですね。

[2020-08-20 19:08:34.362] o support.needlework.jp 73.3413ms noname_host
[2020-08-20 19:08:34.877] o 8.8.8.8 1.2467ms Google_IPv4
[2020-08-20 19:08:35.397] o 8.8.4.4 2.0679ms Google_IPv4
[2020-08-20 19:08:35.991] o support.needlework.jp 69.3738ms noname_host
[2020-08-20 19:08:39.004] x 8.8.8.8 ping...faild... Google_IPv4
[2020-08-20 19:08:42.014] x 8.8.4.4 ping...faild... Google_IPv4
[2020-08-20 19:08:42.686] o support.needlework.jp 69.5217ms noname_host
[2020-08-20 19:08:43.206] o 8.8.8.8 1.0845ms Google_IPv4
[2020-08-20 19:08:43.720] o 8.8.4.4 1.114ms Google_IPv4

エビデンスの保存先は「C:\Users\ユーザ名\.pexpo」です。

 

curlを継続的に実行することもできるようです。

※対象のIPアドレスにHTTP Getを継続して実施

 

pingkeeper

※追記※

金魚さんから教えてもらいました。

ExPingとpexpoは直列でのPingのみ対応していますが、pingkeeperは並列Pingに対応しています。

ネットワーク障害テストの断時間は秒単位で測定します。
直列Pingの場合、宛先の数が多いと結果にズレが出てしまいます。

並列でPing実行できるツールは少ない(他にある?)ので貴重です。

 

こんなツールが出てるとは・・・。

www.vector.co.jp

 

XPing

※追記※

TwitterのDMで教えていただきました。

 

並列Ping対応しているツールです。トーレスルート確認も可能。

xping

 

パラメータはExPingに近いですね。

xping

 

x-aaa.seesaa.net

 

番外編

deadman

番外編です(おそらく、そのままだとWindowsで使えない)。

※今回はMacで動かしています

名前はdeadman。デッドマン!!?と思いましたが、Pingの死活を監視するツールなのでその名がつけられているみたいです。

 

Interop TokyoのShowNet用に作られたツールのようです。

github.com

 

こちらもシンプルなツールで、リストに記載した宛先にPingを送信して結果を表示するというもの。

パッと見た感じ、エビデンス出力やPing送信間隔、タイムアウト値の変更はできないようでした。

ネットワーク構築後のテストで使うというより、ネットワーク監視で使う用途だからだと思います。

ネットワークエンジニア_ExPing_deadman

mtr

金魚さんが紹介していたツール。

Linuxで使えるようです。

経路の切り替わりまで分かるすぐれもの。

今回試してませんが、Windowsで使えるWinMTRというツールもありました。

NEEDLEWORK

最後は宣伝をさせてください(笑)

当社で開発している「NEEDLEWORK」にもPing実行機能があります。

他ツールとの機能的な違いは1台で複数宛先のPingを実行できるというものです。

(もちろん、他ツールにはあってNEEDLEWORKに無い機能もあります)

 

Pingの送信元・宛先として使うPCを用意する必要がなく、NEEDLEWORK上で仮想的にPC(ホスト)を生成して複数のPingを実行可能です。

 

ご興味ある方は下記の記事をご覧ください。

techblog.ap-com.co.jp

www.ap-com.co.jp

www.ap-com.co.jp

おわりに

今回Windowsで使えるPing実行ツールを探しましたが想像以上に少なかったです。

※「ネットワークテスト時に利用する」という観点で

 

ExPingの完成度が高く必要十分な機能が実装されているというのも、市場にあまり同じようなツールがない理由かもしれません。

 

みなさんはどんなツールを使っていますか?

ぜひTwitterのDM等で教えて下さい。

 

Ping実行ツール以外にも、ネットワークエンジニアがマストで使っているツールについて今度調べてみようと思います。

NEEDLEWORKでQoSのテストを実施する

本記事は下記URLに移動しました。
5秒後に自動的に移動します。

https://needlework.jp/article/needlework-throughput-pa

 

先進サービス開発事業部の内藤です

当社で開発・販売をしている、ネットワーク/ポリシーテスト自動化製品「NEEDLEWORK」はネットワーク負荷テストを行うことが可能です

 

techblog.ap-com.co.jp

 

本記事はネットワーク負荷テスト機能を利用して、ネットワーク機器のQoS動作を確認するテスト方法について記載します。

テスト環境

テスト対象のネットワーク機器には「パロアルトネットワークス社 次世代ファイアウォール」を利用します、

負荷テスト-Palo Alto_QoS

NEEDLEWORKの設定

NEEDLEWORKはPPPoE等の一部の設定を除いて、テスト内容・設定はテストシナリオに記載します。

※テストシナリオはCSVファイルを読み込むか管理画面から直接編集することも可能です

 

今回のテストシナリオは下記のとおりです。

テストシナリオを3つ作成し、それぞれ異なるDSCP値をマーキングして送信します。

負荷テスト-Palo Alto_QoS

①192.168.220.100 → 100.100.100.100 :DSCP値 14

②192.168.220.110 → 100.100.100.100  :DSCP値 12

③192.168.220.120 → 100.100.100.100 :DSCP値 10 

ファイアウォールの設定

ファイアウォールのインタフェースでQoSを有効にします。

負荷テスト-Palo Alto_QoS

 

各クラスの帯域を設定します。

class 1 保証帯域:75 Mbps

class 2 保証帯域:20 Mbps

class 3 保証帯域:5 Mbps

※合計帯域 100Mbps

負荷テスト-Palo Alto_QoS

 

QoSポリシーを設定し、マーキングされた値をもとに各クラスに分類します。

DSCP値 14(af13) → class 1 

DSCP値 12(af12) → class 2

DSCP値 10(af11) → class 3

テスト実行と結果

テストを実行するとNEEDLEWORKの送信元から宛先にパケットを送信します。

ファイアウォール

ファイアウォールのQoS統計情報確認画面です。

それぞれのclassに入った通信が、設定した帯域に制御されていることがわかります。

設定値
class 1 保証帯域:75 Mbps

class 2 保証帯域:20 Mbps

class 3 保証帯域:5 Mbps

負荷テスト-Palo Alto_QoS

NEEDLEWORK

NEEDLEWORKの実行画面です。

こちらもリアルタイムに値が変化します。(下記は静止画です)

それぞれのシナリオの使用帯域、パケットロス率等を確認可能です。

負荷テスト-Palo Alto_QoS

※画面取得タイミングの関係で利用帯域がファイアウォール側と少し差異が出ています

 

テスト停止後に下記のようなグラフを表示可能です。(画面をキャプチャし保存可能)

 

負荷テスト-Palo Alto_QoS

また、テスト停止と同時にエビデンスファイルもPC内に保存されます。

エビデンス詳細は下記の記事をご参照ください。

techblog.ap-com.co.jp

おわりに

従来の方法では負荷を掛けるためのPCの準備はもちろんのこと、パケットにマーキングすることが面倒でしたが、NEEDLEWORKを利用することで簡単にテスト可能です。

 

資料ダウンロード

form.run

 

www.ap-com.co.jp

 

 

5社共催「SmartCS x ALAXALA x Ansible ハンズオン」を開催しました

2020/01/31 に弊社会場で開催した「SmartCS x ALAXALA x Ansible ハンズオン」の開催レポートです。

趣旨

ネットワーク機器へのリモート作業は、IPリーチできる必要があるめ、初期設定時や障害時はリモート作業不可になってしまいます。 この課題を解決するのが、セイコーソリューションズ様のコンソールサーバー SmartCS です。

昨年、SmartCS が Ansible に対応したことにより、自動化できる作業が拡大しました。今回は ALAXALA ネットワーク機器を対象にして、SmartCS と Ansible の連携による可能性を体験していただくためのハンズオンを開催しました。

利用された資料はこちら

共催

  • セイコーソリューションズ株式会社
  • アラクサラネットワークス株式会社
  • レッドハット株式会社
  • SB C&S株式会社
  • 株式会社エーピーコミュニケーションズ

■ 実施内容

主な実施内容は以下の通りです。

座学

ハンズオンの前に、SmartCS や ALAXALA ネットワーク機器どういったものかを知れる座学パートがありました。 そもそもコンソールサーバーがどういうものかを知らない状態でも、安心して進められる流れでした。

  • SmartCS のご紹介(セイコーソリューションズ様から)

    • コンソールサーバーが解決する課題
    • コンソールサーバーの様々な機能紹介
  • ALAXALA ネットワーク機器のご紹介(アラクサラネットワークス様から)

    • 製品ラインナップ、今回ハンズオンで利用するスイッチについて
    • Ansible 対応モジュール「AX modules for Ansible」について
    • 実践的Playbookサンプル集について

f:id:c_komatsu:20200205110541p:plain

ハンズオン

弊社内に構築したハンズオン環境を利用し、受講者のみなさんにハンズオンをしていただきました。まずは SmartCS 単体の操作を体験し、その後 Ansible と連携する流れでした。

ハンズオンのコンテンツは以下のリポジトリにあります。詳細に書かれていますので、ご興味がある方は是非ご覧ください。

github.com

  • SmartCS 基礎ハンズオン
    • コンソールサーバー経由のリモートアクセス
    • セッションミラーリング
  • SmartCS x ALAXALA x Ansible ハンズオン
    • 基礎
      • 初期設定
      • 追加設定(ユーザー、VLAN、IPアドレス設定)
      • 情報取得
    • 応用
      • オペミスからの復旧自動化
      • ファームウェアアップデート自動化
  • Ansible Tower のご紹介(レッドハット様から)※時間の都合で座学
    • 自動化 2.0 と Ansible Tower

f:id:c_komatsu:20200205110537p:plain

■ 受講者として参加した当社エンジニアの感想

当社エンジニアからは以下の感想が寄せられました。

  • 今回はじめてコンソールサーバー SmartCS を操作しました。 通常は機器のそばにいないとできない再起動など作業もリモートでできる点が便利でした。 また、IP リーチできなくても操作できるのも心強かったです。 SmartCS が Ansible に対応したことにより、今までは自動化できない、またはしにくかった作業領域にも手が届くようになってきていることを感じました。

  • 一つ一つ丁寧に基礎から段階的に進めていく内容で、資料も行間がしっかりしていてわかりやすく、腑に落ちる感覚が常にあり、最後まで飽きずに楽しく進めることができました。 SmartCSをほとんど知らなかった私が、ハンズオンを通して最後にはオペミスからの復旧自動化ができるまでになっていました。 「最後のライフライン」として活躍するSmartCSの有用性を感じる内容で満足度が高かったです。 これからSmartCSをもっと触ってみたくなりました。

改めて、SmartCS と Ansible の連携による可能性を体験できるハンズオンでした!

NEEDLEWORKにネットワーク負荷テスト機能を追加しました

本記事は下記URLに移動しました。
5秒後に自動的に移動します。

https://needlework.jp/article/needlework-throughputtest

先進サービス開発事業部の内藤です。

当社で開発・販売をしているネットワーク/ポリシーテスト自動化製品「NEEDLEWORK」が、アップデートによりネットワーク負荷テスト(以下、負荷テストと記載)に対応いたしました。

 ※2020年7月10日にセッション負荷テストにも対応しました※

support.needlework.jp

 

本機能により、環境の用意が難しく気軽に行えなかった負荷テストを簡単に実施可能になります。

 

www.dreamnews.jp

www.ap-com.co.jp

 

※本記事はVersion 5.1.0の機能・仕様をもとに記述しています

負荷テストとは?

今回対応した負荷テストは、ネットワークに大量のパケットを流すテストです。

※大量のセッションを確立する機能(セッション負荷テスト)も2020年に追加予定です

 

負荷テスト_スループットテスト-イメージ

 

大量のパケットを送信し、スループット・パケットロス率等の測定を行います。

 

今までの負荷テスト(課題)

今までは負荷テストを行う際に、端末を2台用意しそれぞれにフリーソフトウェア(iperfが代表的です)をインストールして実施していたため、以下のような課題がありました。

 

  • 高負荷をかけるには高スペックな端末が必要(想定の帯域がでない)
  • パターン数に応じて端末の数が増加(多数の端末が必要)
  • 細かな設定ができない(マーキング、送信パケット数等)

 ※高機能な負荷テスト専用機器は高価&操作が複雑なため導入が困難

 

NEEDLEWORKの負荷テスト機能は上記課題を解決いたします。

以下より、具体的な機能について説明をしていきます。

機能紹介

1台で負荷テストが可能

NEEDLEWORKは送信元と宛先のIPアドレスを自身で生成するため、送信側と受信側を1台で実現可能です。

 

負荷テスト_スループットテスト-NEEDLEWORK

 

テストパターン(送信元、宛先、ポート番号等の組合せ)も最大で10項目記載ができます。

※全てのテストパターンを同時実行します

 

今までのように、パターンが増えるたびに端末を増やす必要がありません。

負荷テスト_スループットテスト-テストシナリオ

マーキングに対応

DSCP、IP Precedence、ToSによるマーキングが可能で、QoSの優先制御・帯域制御の確認にも利用できます。

負荷テスト_スループットテスト-QoS

マーキング設定

細かな通信設定に対応

テストトラフィックの「パケットサイズ(*1)」「最大PPS(*2)」を設定可能なため、環境に合わせたチューニングが行なえます。

 

*1. デフォルトのパケットサイズはIMIXです
*2. 1秒あたりにNEEDLEWORKが送信するパケット数

 

ミッドレンジのルータ等、スペックが高くない機器がネットワーク上に存在する場合、テストトラフィックのPPSが多すぎると、CPU負荷が上がってしまいパケットが転送できない状態になります(正常にテストができない)。

最大PPSパラメータを調整することで、適切な数のパケットを送信させることができ、正常にテストが可能になります。

 

テスト結果/エビデンス

テスト結果はグラフで表示可能です。

負荷テスト_スループットテスト-グラフ

テスト結果詳細(送受信ビット数、スループット、パケットロス率)をcsvとして保存することが可能です。また、テストサマリーもテキストで保存されます。

(各ファイルはZIPファイルで一括ダウンロード)

 

テストサマリー例

+--------++--------++--------+
throughput test summary
+--------++--------++--------+
start time: 2019/12/19 11:52:21
finish time: 2019/12/19 12:00:03
elapsed time: 462

+--------++--------++--------+
test result: total
+--------++--------++--------+
BPS(Mbps): 81
Bandwidth Percentage(%): 100
Send Bit(Mbit): 196427
Receive Bit(Mbit): 35542
loss Percentage(%): 82
Send Packet: 69414338
Receive Packet: 12635423

+--------++--------++--------+
test result: #1
+--------++--------++--------+
BPS(Mbps): 55
Bandwidth Percentage(%): 66
Send Bit(Mbit): 66805
Receive Bit(Mbit): 23452
loss Percentage(%): 65
Send Packet: 23639497
Receive Packet: 8303609

+--------++--------++--------+
test result: #2
+--------++--------++--------+
BPS(Mbps): 21
Bandwidth Percentage(%): 28
Send Bit(Mbit): 64692
Receive Bit(Mbit): 9667
loss Percentage(%): 85
Send Packet: 22807008
Receive Packet: 3462067

イメージ動画

 

 

techblog.ap-com.co.jp

 

www.ap-com.co.jp

 

※セッション負荷テストにも対応しました※

support.needlework.jp

資料ダウンロード

form.run

アンケートのお願い

NEEDLEWORK機能拡張の参考にさせていただくため、以下のアンケートにご回答お願いいたします。

※無記名で記入できます

 

docs.google.com

 

 

NEEDLEWORKにネットワークテスト自動化機能を追加しました

本記事は下記URLに移動しました。
5秒後に自動的に移動します。

https://needlework.jp/article/needlework-networktest

NEEDLEWORKがネットワークテストに対応

 

先進サービス開発事業部の内藤です。

当社で開発・販売をしている、テスト自動化製品「NEEDLEWORK」がアップデートによりネットワークテストに対応いたしました。

 

今まではファイアウォールのセキュリティポリシー、ルータ・L3スイッチなどのアクセスリストに対する通信テストに特化していましたが、活用の幅を増やしていただけるようアップデートを行いました。

 

www.ap-com.co.jp

 

本記事では、現状のネットワークテストにおける課題とNEEDLEWORKを使うことによるメリット(課題の解決方法)をお伝えできればと思います。

続きを読む

GoPacketでネットワークと直接お喋りしよう

はじめに

先進サービス開発事業部の山岡です。

Go言語は標準でかなり強力なネットワーク用のライブラリーがありますが、GoPacket *1 を使うと更に細かいところをイジれるようになります。

仕事でパケットをごにょごにょしたところ結構面白かったのでここで紹介したいと思います。

コード

早速ですがコードを貼り付けます。ネットワークの素養がある方ならかなり直感的に見ることができるかと思います。

なお環境は前回の記事を前提としてserver1からserver2へICMP Echo Requestの送信までをやってみます。

main.go

package main

import (
    "net"
    "time"

    "github.com/google/gopacket"
    "github.com/google/gopacket/layers"
    "github.com/google/gopacket/pcap"
)

func main() {
    srcMAC, _ := net.ParseMAC("ca:50:4c:06:7d:5f")
    dstMAC, _ := net.ParseMAC("fe:8e:41:70:79:ec")

    ethernetLayer := &layers.Ethernet{
        SrcMAC:       srcMAC,
        DstMAC:       dstMAC,
        EthernetType: layers.EthernetTypeIPv4,
    }

    ipLayer := &layers.IPv4{
        Version:  uint8(4),
        Flags:    layers.IPv4DontFragment,
        SrcIP:    net.ParseIP("10.0.0.1"),
        DstIP:    net.ParseIP("10.0.1.1"),
        Protocol: layers.IPProtocolICMPv4,
        TTL:      uint8(64),
        Id:       uint16(1),
    }

    icmp := &layers.ICMPv4{
        TypeCode: layers.CreateICMPv4TypeCode(layers.ICMPv4TypeEchoRequest, uint8(0)),
        Id:       uint16(1),
        Seq:      uint16(1),
    }

    buf := gopacket.NewSerializeBuffer()
    gopacket.SerializeLayers(
        buf,
        gopacket.SerializeOptions{
            ComputeChecksums: true,
            FixLengths:       true,
        },
        ethernetLayer,
        ipLayer,
        icmp,
    )

    h, _ := pcap.OpenLive("server1-veth1", int32(1500), false, 3*time.Second)
    defer h.Close()
    h.WritePacketData(buf.Bytes())
}

使い方

基本的な考え方はOSI参照モデル *2 のレイヤーで捉えます。

「ネットワークと直接お喋り」とは銘打ちましたが、流石にビット演算して云々というわけではありません。GoPacketのサブパッケージである layers 内にはレイヤー毎に構造体が定義されており、ここにヘッダー情報を埋め込んでいきます。設定内容についても基本的には定数が提供されているので「ICMP Echo RequestはType8」等のように丸暗記しなくても大体なんとかなるでしょう(まぁ実際に使っているとすぐ覚えてしまいますが)。

チェックサムやデータ長を書くためのフィールドは自動計算することができる(後述)ので通常手入力する必要はありません。

L2 (Ethernet)

ここで設定すべき内容は「送信元MAC」「宛先MAC」「イーサネットタイプ」の3つです。

本来であれば宛先MACはARPを使って求めるところですが、今回は単純化のため既にARP解決済みという想定で手入力します。実際の値は sudo ip netns exec server1 ip addrsudo ip netns exec router ip addr で求めて下さい。

L3 (IP)

IPヘッダーを入力しますが送信元IPアドレス、宛先IPアドレス以外はほぼ決め打ちです。よりリアルにやるのであればIDに乱数を入れたりしてもいいでしょう。

L3 (ICMP)

Type/Codeを入力します。今回はEcho RequestなのでType8 Code0をセットします。IDに乱数、シーケンス番号に通し番を振るようなコードにするとよりPingっぽくなります。

シリアライズ

gopacket.SerializeLayers() にシリアライズ用のバッファ、シリアライズオプション、各レイヤー構造体を放り込みます。 ComputeChecksumsFixLengths をtrueにしておくと各所のヘッダー長等を勝手に入れてくれるので便利です。

ビルドと動作確認

ビルドは通常通り go build して下さい。なおGoPacketのビルドには libpcap-dev が、実行には libpcap が必要になります。

Echo Request -> Echo Replyのやり取りを見るため中間のルーターでパケットキャプチャーしてみましょう。

$ go build main.go
$ sudo ip netns exec server1 ./main
$ sudo ip netns exec router tcpdump -nn -l
12:57:56.950376 IP 10.0.0.1 > 10.0.1.1: ICMP echo request, id 1, seq 1, length 8
12:57:56.950410 IP 10.0.1.1 > 10.0.0.1: ICMP echo reply, id 1, seq 1, length 8

今回書いたコードはあくまでEcho Requestを送るだけですが、通信相手である server2 は有効なICMPパケットとみなしてEcho Replyが返されていることが確認できました。

諸注意

上記の通りかなり自由度が高い通信を行えるため、コードによっては予期しない事象を引き起こす可能性があります。例えばヘッダーにデタラメな値を入れてIPSから怒られが発生したりするかもしれません。自分以外のARP RequestにもARP Replyを送るようなロジックを書くと結果的にネットワークが落ちたりするかもしれません。

くれぐれも他人の通信にイタズラしたりネットワーク管理者の手を煩わせたりすることのないようご注意下さい。

FWポリシーテスト自動化製品「NEEDLEWORK」のご紹介①

本記事は下記URLに移動しました。
5秒後に自動的に移動します。

https://needlework.jp/article/needlework-firewall-policytest

ファイアウォールのポリシーテストを自動化する製品「NEEDLEWORK」の販売開始から1年が経過し、先日メジャーバージョンアップもいたしました。

 

より製品のことを知ってもらうために、何回かに分けてNEEDLEWORKの紹介記事を書いていきたいと思います。

 

目次

  • NEEDLEWORKとは?
  • 今までのテスト
    • 今までのテスト構成
    • 今までのテスト方法
  • NEEDLEWORKでのテスト
    • NEEDLEWORKでのテスト構成
    • NEEDLEWORKでのテスト方法
  • 最後に
  • 資料ダウンロード
続きを読む

次世代ファイアウォールのBotnet(ボットネット)レポート機能

本記事の内容はPAN-OS7.1系をもとに記載しています

 PAN-OS4.0から実装されたBotnet(ボットネット)レポート機能、皆さん活用できていますか?

 

Botnetレポートは、Bot化した可能性があるホストを検出するための機能です(無料で使用可能)。

※Bot化したホストは、C&Cサーバー(Command and Control Server)にコントロールされ、攻撃・情報収集等に利用されます

 

Botnetレポートの確認

日本語表記の場合、次世代ファイアウォールの管理画面で「Monitor」➔「ボットネット」から確認することができます。

f:id:apc-sieg:20170926170956j:plain

パロアルトネットワークス次世代ファイアウォール Botnetレポート
続きを読む

「ネットワークの自動化、何つかう?~自動化ツール紹介~」 APC勉強会 8a1 #30 を開催しました

今回のテーマは「ネットワークの自動化、何つかう?~自動化ツール紹介~」。

自動化に興味があるエンジニアなら耳慣れたキーワードになってきた「Python」や「Ansible」。
一方で「興味はあるけど、試してみる時間も環境もない!」という方も多いはず。
そんな方のために、弊社エンジニア横地( id:akira6592 )が自ら試してみた色々な自動化ツールの特徴や、 触ってみた所感などをご紹介しました。


AnsibleとSaltはデモも実施。
百聞は一見に如かず、でアンケートでも好評をいただきました。

発表の後は、"スグキク"でリアルタイムに投稿頂いた質問へ答える形でQ&Aを行いました。

多くの関心が寄せられた質問は「Netmiko / NAPALM には Ansible のように冪等性があるか」というもの。
構成管理ツールを調べると必ずと言っていいほど出てくる冪統性の話ですが、ライブラリについても同様に気になるポイントのようです。
ちなみに、Netmiko や NAPALM 自身には冪等性担保の仕組みはなく、ロジックを自身でコーディングする必要があります。

他にはsalt に関してのご質問を多くいただきました。
まだ情報が少ない状況の中で、今回ご紹介したことで興味を持っていただいたようです。

 

f:id:apc-sieg:20170725175118p:plain

金曜日の夜にも関わらず、たくさんの方にご参加いただきありがとうございました。
申込者多数ということで、8/18(金)にも同じ内容で"APC勉強会 8a1 #30その2"を開催します。 

8a1-apc.connpass.com
■お知らせ
"APC勉強会 8a1 #31"は10月頃の開催を予定しています。
開催のお知らせはconnpassやFacebookで行いますので、是非チェックしてください。
 ▼connpass
 「8a1」APC勉強会 - connpass
 ▼Facebook
 https://www.facebook.com/APCommunications/

【Palo Alto-FW】詳細ログにVirusTotalへのリンクを貼る方法

本記事はPAN-OS6.1.xを対象としています

 

Webサイトやファイルのマルウェア検査を行うことができるサービス「VirusTotal

そのVirusTotal」へのリンクを、パロアルトネットワークス社の次世代ファイアウォールのログに自動で表示させることができます。

 

www.virustotal.com

 

続きを読む

Windows7でTOS値(DSCP)を変更する方法

QOSの試験で、TOS値を変更して「iperf」 などの負荷ツールで負荷を掛けたい場合があるので、備忘録として方法を記述します。

 

※当社で開発しているネットワークテスト自動化製品NEEDLEWORKで、マーキング&負荷テストが可能です※

techblog.ap-com.co.jp

 

1.スタートメニューの「プログラムとファイルの検索」から「gpedit.msc」を実行し、ローカルグループポリシーエディターを開きます。

f:id:apc-sieg:20130523165226j:plain

 

続きを読む