ハンズオンの流れ
最初に、ハンズオンに必要な環境を準備します。
今回のハンズオン環境用にVMを準備してありますので、以下のリンクからVMをダウンロードします。
VMのダウンロードが完了したら、VirtualBox にVMイメージをインポートして起動し、起動確認をします。
VirtualBoxを起動し、ダウンロードしたVMのイメージをインポートしましょう。 インポートの方法については、こちらを参考にしてください。
なお、VMへのSSHアクセスにはVirtualBoxのポートフォワード設定が必要ですので、こちらを参考に設定しておきましょう。
インポートが完了したら、メモリを4GB以上割り当ててVMを起動します。(メモリ 4GB は最低限動作するレベルです。4GB よりも多く割り当てられる場合は多めに割り当てることを推奨します。)
VMの中の構成は以下のようになっています。
中には複数のVMが入れ子で起動しており、それぞれの子VMは 親VMの scenario からアクセスすることができます。これらのVMは、「テスト対象」と「テストシステム(NetTester)」です。本来「テスト対象」はスイッチやルータなど物理的なネットワーク機器ですが、ハンズオンではこれを仮想マシンとして用意します。各 VM がどのような役割を持つかについては、後述するミッションを参照してください。
Teratermなどを開き、起動したVM ( scenario ) にログインしてみましょう。ログイン先IPアドレスは localhost、ポートは先程設定したポートフォワードのポートを指定します。
| VM | IPアドレス | ユーザ | パスワード |
|---|---|---|---|
| scenario | localhost:ssh_forwarded_port | handson | handson |
scenario には screen, tmux がインストール済みです。複数VMの操作や時間のかかるテストの実行などで便利なので、必要に応じて利用してください。
scenario にログイン出来たのち、ほかのVMも起動しましょう。
handson@scenario:~$ sudo ./hands-on/setup/scenario/boot-vm.sh
Domain global-vyos started
Domain yoyodyne-vyos started
Domain tajimax-nettester started
Domain yoyodyne-nettester started
starting NetTester APIs
done
コマンド実行後、3～5分で上記のように done が表示されるまで待ちます。
scenario から、それぞれのVMにログインできることを確認してください。IPアドレス、ユーザ、パスワードは以下のとおりです。
VM (on scenario) |
IPアドレス | ユーザ | パスワード |
|---|---|---|---|
| yoyodyne-nettester | 172.16.0.2 | handson | handson |
| tajimax-nettester | 172.16.0.3 | handson | handson |
| yoyodyne-vyos | 172.16.0.4 | vyos | vyos |
| global-vyos | 172.16.0.5 | vyos | vyos |
ここまでの手順で環境が正しく起動していることが確認できました。それでは、scenario でテストシナリオを流して動作するところを見てみましょう。
今回はあらかじめテストシナリオと必要なライブラリはインストールされているため、シナリオディレクトリに入る部分だけを実行します。
handson@scenario:~$ # シナリオのインストール。ハンズオン用VMでは不要。
handson@scenario:~$ # git clone https://github.com/net-tester/hands-on.git
handson@scenario:~$
handson@scenario:~$ # シナリオディレクトリへ移動。
handson@scenario:~$ cd hands-on/scenario
handson@scenario:scenario$ # シナリオの更新
handson@scenario:scenario$ git pull
handson@scenario:scenario$ # ライブラリのインストール・更新
handson@scenario:scenario$ bundle install --path=vendor/bundle
handson@scenario:scenario$ # Vyosの設定を初期化
handson@scenario:scenario$ scp ../setup/yoyodyne-vyos/apply-acl.sh [email protected]:/home/vyos/apply-acl.sh
The authenticity of host '172.16.0.4 (172.16.0.4)' can't be established.
RSA key fingerprint is ce:13:1b:0a:fe:6d:99:4c:1a:7a:e7:24:d8:f0:20:0b.
Are you sure you want to continue connecting (yes/no)? yes ( <- yesを入力 )
Warning: Permanently added '172.16.0.4' (RSA) to the list of known hosts.
Welcome to VyOS
[email protected]'s password: ( <- vyosを入力)
apply-acl.sh 100% 5276 5.2KB/s 00:00
handson@scenario:scenario$ ssh [email protected] /home/vyos/apply-acl.sh
Welcome to VyOS
[email protected]'s password: ( <- vyosを入力)
準備が整ったら、テストシナリオを実行します。(注意: 全シナリオ実行なので時間がかかります。)
handson@scenario:scenario$ bundle exec rake
このログの背景で一体何が起こっているかを、こちらのドキュメントを見ながら説明します。
大まかな仕組みがわかったところで、早速実際にシナリオを書いてみましょう。
あなたの企業(ヨーヨーダイン社)では現在、ソフトウェアの開発プロジェクトを持っています。 開発業務の一部は協力会社(タジマックス通信工業社)に委託しており、委託先からはVPNで接続した上で開発いただいている状況にあります。 セキュリティに煩い昨今、ネットワーク通信はファイアウォールにより厳格にコントロールされているようです。
突然ですが、この度ネットワーク管理者が全治2ヶ月程度の怪我をしてしまい、あなたはその間の代理として任命されました。 管理者はどうやらファイアウォール運用業務について負担の多い人力ACL管理をどうにかしようと、NetTesterを使ってテストシナリオを記述している最中だったようです。 話によればシナリオはほぼ完成しているそうで、ACLをリファクタリングしようとしていたとのことです。
このネットワークは以下のような構成になっているようです。
このネットワークがVMのネットワークとどのように関連しているかを以下に示します。
- テスト対象: ヨーヨーダイン社およびタジマックス社のネットワーク機器 (
yoyodyne-vyosおよびtajimax-vyos) - テストシステム: NetTester (
yoyodyne-nettesterおよびtajimax-nettester)- テストに必要なテスト用ノードの操作とテスト対象への接続、テストプロセス(
ping等)の実行をおこないます。
- テストに必要なテスト用ノードの操作とテスト対象への接続、テストプロセス(
このネットワークでは、以下のような通信要件があるようです。
| No. | 送信元 | 送信先 | サービス | プロトコル | 内容 | feature |
|---|---|---|---|---|---|---|
| 1 | 社内 PC | インターネット上のサーバ | http、https | 443/tcp | Web検索 | features/user/user_pc_to_internet_host/web.feature |
| 2 | 社内 PC | 社内のテスト環境サーバ | telnet | 23/tcp | テストサーバでの作業 | features/user/user_pc_to_test_host/telnet.feature |
| 3 | 社内 PC | 社内のテスト環境サーバ | http | 13000/tcp | Jenkins webコンソールアクセス | features/user/user_pc_to_test_host/jenkins.feature |
| 4 | 社内 PC | インターネット上の NTP サーバ | ntp | 123/udp、123/tcp | 時刻同期 | features/user/user_pc_to_internet_ntp_host/ntp.feature |
| 5 | 社内 PC | 社内の資産管理サーバ | git | 11000/tcp | 資産へのアクセス | features/user/user_pc_to_git_host/git.feature |
| 6 | 社内 PC | DMZ の DNS サーバ | dns | 53/udp、 53/tcp | 名前解決 | features/user/user_pc_to_dns_host/dns.feature |
| 7 | 社内 PC | インターネット上のサーバ | ping | icmp | 疎通確認 | features/admin/user_pc_to_internet_host/ping.feature |
| 8 | 社内 PC | 社内のテスト環境サーバ | ssh | 22/tcp | 管理業務 | features/admin/user_pc_to_test_host/ssh.feature |
| 9 | 社内 PC | DMZ のサーバ | ping | icmp | 疎通確認 | features/admin/user_pc_to_dmz_host/ping.feature |
| 10 | 社内 PC | DMZ のサーバ | ssh | 22/tcp | 管理業務 | features/admin/user_pc_to_dmz_host/ssh.feature |
| 11 | DMZ のサーバ | インターネット上の NTP サーバ | ntp | 123/udp、123/tcp | 時刻同期 | features/admin/dmz_host_to_internet_ntp_host/ntp.feature |
| 12 | DMZ の DNS サーバ | インターネット上の DNS サーバ | dns | 53/udp、 53/tcp | 名前解決 | features/admin/dns_host_to_internet_dns_host/dns.feature |
| 13 | 社内 PC | VPN サーバ | ssh | 22/tcp | 管理業務 | features/admin/user_pc_to_vpn_host/ssh.feature |
| 14 | DMZ の VPN アドレスプール | 社内の資産管理サーバ | git | 11000/tcp | 資産へのアクセス | features/admin/vpn_address_pool_to_git_host/git.feature |
| 15 | 社内 PC | 社内の資産管理サーバ | ssh | 22/tcp | 管理業務 | features/admin/user_pc_to_git_host/ssh.feature |
| 16 | インターネット上のサーバ | 外部 LAN のルータ | ping | icmp | 疎通確認 | features/admin/internet_pc_to_router/ping.feature |
| 17 | DMZ のサーバ | 社内 PC | ping | icmp | 疎通確認 | features/admin/dmz_host_to_user_pc/ping.feature |
| 18 | DMZ の VPN アドレスプール | 社内のテスト環境サーバ | telnet | 23/tcp | テストサーバでの作業 | features/admin/vpn_address_pool_to_test_host/telnet.feature |
| 19 | DMZ の VPN アドレスプール | 社内のテスト環境サーバ | http | 13000/tcp | Jenkins webコンソールアクセス | features/admin/vpn_address_pool_to_test_host/jenkins.feature |
| 20 | インターネット上のサーバ | 外部 LAN のファイアウォール | ping | icmp | 疎通確認 | features/admin/internet_pc_to_firewall/ping.feature |
| 21 | DMZ のサーバ | インターネット上のパッケージサーバ | http | 80/tcp、 443/tcp | パッケージアップデート | features/admin/dmz_host_to_internet_host/web.feature |
| 22 | DMZ のサーバ | インターネット上のサーバ | ping | icmp | 疎通確認 | features/admin/dmz_host_to_internet_host/ping.feature |
| 23 | 社内 PC | DMZ の DNS サーバ | ping | icmp | 疎通確認 | features/admin/user_pc_to_dns_host/ping.feature |
| 24 | 社内 PC | DMZ の DNS サーバ | ssh | 22/tcp | 管理業務 | features/admin/user_pc_to_dns_host/ssh.feature |
話によれば、シナリオは完成間近ではありましたが、No.3 ユーザPCからテスト環境へのJenkins Webコンソール接続、No.12 DMZのDNSサーバからインターネット上のDNSサーバへのTCP接続のシナリオは要件としてあるものの、まだシナリオが完成していない、とのことでした。
これらについて、シナリオを作成し、テストを実行してみてください。
今回修正する必要があるシナリオは No.3 と No.12 です。
修正が必要なシナリオについては、非常によく似たシナリオが既に定義されています。
- 参考
こちらを参考に記述してみましょう。(なお、単純なコピーペーストでは動作しません。)
先ほどの背景で不足しているシナリオを書いていきます。編集するシナリオファイルは下記2ファイルです。直接開いて編集します。
- 要修正
@wip (Work In Progress) タグがファイルの先頭に記述されているテストシナリオは実行されず、記述を保留するのに利用されます。今回は jenkins.feature に@wip がついていて作業中になっているため、この行を削除して作業を進めます。
また、 features/admin/dns_host_to_internet_dns_host/dns.feature に関しては一旦完成として @wip が無い状態ですが、どうやら要件が追加されたようですので、そのまま追記することにします。
記述が完了したら、シナリオを実行してみましょう。先ほどは rake で全てのシナリオを実行しましたが、個別に実行することも可能です。
handson@scenario:scenario$ bundle exec cucumber features/user/user_pc_to_test_host/jenkins.feature
handson@scenario:scenario$ bundle exec cucumber features/admin/dns_host_to_internet_dns_host/dns.feature
結果を確認してみましょう。
jenkins.feature に関しては成功したものの、 dns.feature に関しては要件どおりに試験を書いたにも関わらず、以下のようにテストは失敗してしまったはずです。
handson@scenario:scenario$ bundle exec cucumber features/admin/dns_host_to_internet_dns_host/dns.feature
Feature: DNS で名前解決
ネットワーク管理者として、
社内の DNS サーバから上位 DNS サーバへ問い合わせたい
なぜなら、毎回 IP アドレスを指定するのは不便だから
Scenario: DNS サーバで名前解決 (UDP) # features/admin/dns_host_to_internet_dns_host/dns.feature:7
Given DMZ の DNS サーバ # features/step_definitions/virtual_host.rb:14
And インターネット上の DNS サーバ # features/step_definitions/virtual_host.rb:34
When DMZ の DNS サーバにログイン # features/step_definitions/client_steps.rb:10
And インターネット上の DNS サーバに dig コマンドで "www.google.com" の IP アドレスを問い合わせる # features/step_definitions/dns_steps.rb:26
Then 名前解決に成功 # features/step_definitions/success_steps.rb:29
-- snip --
Then 〇〇〇 # features/step_definitions/〇〇〇.rb:〇〇〇
expected "" to match /〇〇〇/
Diff:
@@ -1,2 +1,2 @@
-/〇〇〇/
+""
(RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/〇〇〇.rb:〇〇〇:in `/^〇〇〇$/'
features/admin/dns_host_to_internet_dns_host/dns.feature:〇〇〇:in `Then 〇〇〇'
Failing Scenarios:
cucumber features/admin/dns_host_to_internet_dns_host/dns.feature:〇〇〇 # Scenario: 〇〇〇
2 scenarios (1 failed, 1 passed)
10 steps (1 failed, 9 passed)
1m4.096s
どうやら、修正した dns.feature については要件通りのACL設定になっていない可能性がでてきました。
シナリオどおりに通信が成功するよう、ACLを見直してみましょう。
仮想ノード定義が記述されている features/factories.rb と features/step_definitions/virtual_host.rb を見ると、それぞれのテストノードのIPアドレスは以下のようになっています。
| 仮想ノード | 日本語名 | IPアドレス |
|---|---|---|
| git_host | 社内の資産管理サーバ | 10.10.10.1/24 |
| test_host | 社内のテスト環境サーバ | 10.10.10.2/24 |
| user_pc | 社内 PC | 10.10.10.4/24 |
| dmz_host | DMZ のサーバ | 10.10.0.100/24 |
| dns_host | DMZ の DNS サーバ | 10.10.0.10/24 |
| vpn_host | VPN サーバ | 10.10.0.11/24 |
| vpn_addrpool | DMZ の VPN アドレスプール | 10.10.0.130/24 |
| internet_pc | インターネット上の PC | 198.51.100.1/24 |
| internet_dns_host | インターネット上の DNS サーバ | 198.51.100.2/24 |
| internet_host | インターネット上のサーバ | 198.51.100.3/24 |
| internet_ntp_host | インターネット上の NTP サーバ | 198.51.100.4/24 |
| tajimax_pc | タジマックス社の PC | 198.51.100.94/24 |
Vyosへログインして、ACLの確認と修正を行いましょう。IPアドレスやアカウントは以下のようになっていました。
VM (on scenario) |
IPアドレス | ユーザ | パスワード |
|---|---|---|---|
| yoyodyne-vyos | 172.16.0.4 | vyos | vyos |
| global-vyos | 172.16.0.5 | vyos | vyos |
ログイン後、ACLを確認するには以下のコマンドを入力します。編集モードに入ってからの show firewall では、具体的な設定の記述が表示されます。
vyos@yoyodyne-vyos:~$ configure
[edit]
vyos@yoyodyne-vyos# show firewall
name dmz {
default-action drop
rule 50 {
action accept
state {
established enable
related enable
-- snip --
firewall の編集に関しては、こちら を参考にしながら行います。
vyos@yoyodyne-vyos# # 編集の例
vyos@yoyodyne-vyos# set firewall name to-internet rule 100 protocol udp
[edit]
vyos@yoyodyne-vyos# set firewall name to-internet rule 100 destination port 123
[edit]
vyos@yoyodyne-vyos# …
編集が完了したら、 commit と save を実行します。
vyos@yoyodyne-vyos# commit
[edit]
vyos@yoyodyne-vyos# save
Saving configuration to '/config/config.boot'...
Done
[edit]
vyos@yoyodyne-vyos#
修正が終わったら、再度 cucumber を実行し、仕様通りに動作することを確認しましょう。
handson@scenario:scenario$ # 修正対象の確認
handson@scenario:scenario$ bundle exec cucumber features/admin/dns_host_to_internet_dns_host/dns.feature
最後に、他の通信に影響がでていなかを確認しましょう。 なお、回帰テストについては初回同様非常に時間が掛かるため、修正が完璧であると感じたら実行してみましょう。
handson@scenario:scenario$ # 回帰テスト
handson@scenario:scenario$ bundle exec rake
scenario の停止前に子VMを停止します。
handson@scenario:~$ sudo ./hands-on/setup/scenario/shutdown-vm.expect
spawn virsh console yoyodyne-nettester
(snip)
Will now halt.
[ 787.258159] reboot: Power down
done
上記の done 表示後、 scenario をshutdownしてください。