Office365通信のローカルブレイクアウトを自動化させる - 後編 -

ビジネス推進本部 第1応用技術部
コアネットワークチーム
由原 亮太、川畑 勇貴

Office365通信のローカルブレイクアウトを自動化させる - 前編 -ではMicrosoft Office365のアドレス一覧を扱いやすい形に組み替え、CSVファイルとして出力するPythonプログラム作成の取り組みを紹介しました。

後編の本コラムでは前編で作成したCSVファイルを基にAnsibleを駆使したコンフィグ作成の自動化に対する挑戦を紹介します。

前回のまとめ

前回のコラムではMicrosoftが公開しているOffice365利用時の宛先一覧を自動化に利用しやすい形に加工する仕組みを紹介しました。
なお現在はXML形式ではなく、RESTベースのリストが公開されています。

<Microsoftが公開しているRESTベースのOffice365アドレスリスト>
https://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-service

こちらも前編で記述したプログラムコードを書き換えることにより同様に実現可能です。

Office365ローカルブレイクアウトを行う仕組み

昨今、クラウドサービスをローカルブレイクアウトする場合はDPI(DeepPacketInspection)によるアプリケーション識別をベースにローカルブレイクアウトさせる手法が各社ベンダーから登場しています。

DPIを用いる方法は設定が手軽で管理負担が少なくて済むという利点がありますが、シグネチャベースでの識別となるため全てのトラフィックを正常に識別することは現在の技術では困難です。しかし、この課題は公開されている宛先一覧を基に経路制御を行う方法を採用することで正確性を向上させることができます。

具体的な方法としては、CiscoのIOSルータであればPBR(Policy-Based Routing)を用いて宛先一覧に該当するトラフィックに対するネクストホップをインターネットへ繋がるインターフェースへと向ける方法をとります。

自動化の仕組みを大きく4つの要素に分けて解説していきます。
1. PBRを行う為のベースコンフィグ
2. playbookのディレクトリ構造
3. ファイル内容解説
4. 実行結果

1.PBR ベースコンフィグ

    Router#sh run | s route-map
    route-map o365_LBO permit 10
    match ip address o365
    set ip default next-hop <インターネット網に繋がるネクストホップ>
    

この方法であればアドレスリストに変更があった際に、対象のACLを変更するだけで済むため管理する箇所が1か所となり管理の負担が少なく済みます。

ACLに記載された宛先一覧の管理を自動化する

PBRに用いるACLを前回作成したCSVファイルとAnsibleを使って設定変更の自動化をします。
AnsibleではCSVのデータを元にPBRに用いるACLを作成させています。作成されたACLはPlaybookを実行する。
度に最新の状態に更新されます。今回はAnsibleのPlaybookの構造が分かりやすいように複数のファイルに分割して作成してあります。

構成は以下になります。

2.Ansibleプロジェクトディレクトリ構造

Ansible-Project #Ansibleプロジェクトフォルダ
       O365_IPv4.csv #前編で作成したCSV
       master.yml #roleを呼び出すためのマスターファイル
       host #管理するホスト定義用ファイル
       /roles #Playbookで利用する為のロール保存用フォルダ
          common/
             tasks/
                main.yml #roleで実行されるタスクを定義するファイル
       /host_vars #ホスト変数定義用フォルダ
          xxx #対象ホストのIPアドレスをファイル名とする
       /library #外部ライブラリ保存用フォルダ
    

Ansibleの詳しいディレクトリ構造に関してはAnsible公式ドキュメントに記載されています。

<Ansible公式ドキュメント>
https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html

3.Playbookファイル解説

3-1.master.yml

    ---
    - hosts: localhost
    name: INCLUDE_CSV VARS
    tasks:
    - include_csv: src=O365_IPv4.csv
    - hosts: Router
    gather_facts: no
    connection: network_cli
    roles:
    - common
    

master.ymlではどのホストに対して、どのロールを実行するかを定義しています。

今回はCSVファイルのデータをPlaybook内で扱うために、自身に対してCSVファイルを読み込ませ、読み込んだデータを基に対象機器に対して設定変更を行うロールを実行させています。

CSVファイルの内容を取り込むために外部ライブラリであるinclude_csvというライブラリを利用しています。
外部ライブラリはansible-galaxyコマンドでインストールすることが可能です。

3-2.roles/common/tasks/main.yml

    ---
    - name: reset_o365ACL
    ios_config:
    match: none
    authorize: yes
    lines:
    - "no ip access-list extended o365"
    - name: load new acl
    with_items: "{{hostvars.localhost.O365_IPv4}}"
    ios_config:
    match: none
    lines:
    - permit ip any {{item.IPv4}} {{item.wildcard}}
    parents: ip access-list extended o365
    

roles/common/tasks/main.ymlではロールの中でどのタスクを実行するかを定義しています。

今回は、2つのタスクを実行するよう定義してあります。
１つ目は、既に設定されているACLを削除するタスク
２つ目は、master.ymlで取得したデータを基にACLの設定を行うタスクを実行させています。

実行するタスクが多い場合は、「タスクごとにファイルを分割し、main.ymlで分割したファイルを呼び出す。」といった使い方をしますが、今回は実行するタスクが少ない為１つのファイルにまとめています。

3-3.host

    [Router] #[グループ名]でグループを作成
    aa.bb.cc.dd　#管理対象のアクセス先を記述
    

hostファイルにはAnsibleで設定管理を行う機器情報を記述することができます。

今回はOffice365の経路制御を行う機器の管理IPが記述されています。

3-4.host_vars/aa.bb.cc.dd

    ansible_connection: network_cli　#接続方式
    ansible_network_os: ios　#接続先OS
    ansible_user: <sshアクセス用password>
    ansible_ssh_pass: <sshアクセス用password>
    ansible_become: yes
    ansible_become_method: enable
    ansible_become_pass: <password>
    

host_varsにはそれぞれの管理対象機器に対する変数を設定することができます。

今回は接続に使用するログイン情報等が記載されています。

実際にこのplaybookを実行していくと以下のような出力が行われます。

※出力量が多くなってしまうため今回のplaybookには件数を絞ったCSVファイルを利用しました。

4.実行結果

実行後の機器の設定を確認すると以下のような状態に変更が行われ、最新の宛先一覧が反映された状態で経路制御を行うことが可能になっていることが分かります。

Ansibleを用いることにより管理者が差分のチェックやコンフィグの作成を行う時間を大幅に削減することが可能になり、人の手を介することによる人的なミスを減らすことにも繋がります。

Office365の宛先一覧のサービスは更新日が付与された状態で配信されているため、 これをもとに更新の有無を確認することで、宛先情報と機器の設定との間で発生する差異を最小限に抑えることが可能になります。

この仕組みを定期的なデータの取得や、ファイル監視といった機能と組み合わせることでより完全自動化に近づけることが可能になります。

今回のまとめ

今回は前後編に渡りOffice365宛の経路制御に関して自動化の追求を行いました。

クラウドサービスに対する通信のローカルブレイクアウトによるWAN回線の負荷軽減は、Office365以外の様々なクラウドサービスに対しても活用が可能です。

ベンダー各社が提供するローカルブレイクアウト機能を持ったプロダクトは高価であったり、かゆい所に手が届かなく導入しにくい場合もあります。
そういった場合に、今回のようなネットワーク機器の裏側で動作するプログラムを利用し、それぞれ異なる環境にチューニングし利用満足度を向上させるといった適用が可能となります。

今後、ローカルブレイクアウトを検討される時には、プログラムを利用し自社環境により最適化したローカルブレイクアウトの実現を検討してみてはいかかでしょうか。詳細をお聞きしたい方は弊社担当営業までご連絡下さい。

執筆者プロフィール

由原 亮太
ネットワンシステムズ株式会社 ビジネス推進本部
第1応用技術部 コアネットワークチーム
所属
新卒入社で応用技術部に配属されてから今日までCisco社ルータ製品（ISR/ASR1000シリーズ）の担当として、評価・検証および様々な案件サポートに従事。
ネットワークの可能性を広げるためにプログラミングスキルを活かして奮闘中。

• CCNP
• 応用情報技術者

川畑 勇貴
ネットワンシステムズ株式会社 ビジネス推進本部
第1応用技術部 コアネットワークチーム
所属
ネットワンシステムズに入社し、Ciscoミドルエンド・ローエンドルータ製品を担当。
ネットワークに関わる先進テクノロジーの調査、研究に従事している。
執筆者プロフィールに「・CCIE」と載せるべく日々研鑽中。

• CCNP
• TOEIC L&R 915

ナレッジセンターを検索する