GCPとVPN接続する~その2~

GCPとのVPN接続で, ポリシーベースではなくルーティングベースでやってみる。

構成は前回とほぼ変わらず。
クラウドルータとの間のセグメントが増えた感じ。

GCP側にBGPルータができ, それとのルーティング設定が追加となる

前提条件(ポリシーベースの前提を大体引き継ぐ)

  • GCPのアカウント設定済み
  • (VPC作成済み, VPC作成後のインスタンスも作成済み)
  • 家側のNAT設定済み
  • ルーティングベースなので, VTIを採用

流れ

1. クラウドルータ設定
2. VPN設定(Cisco)

1. クラウドルータ設定

ネットワーキングから「ハイブリッド接続」を選択

「ルーターを作成」をクリック

必要事項を記入する。
今回, BGPのAS NoはGCP側は64512とした。

ルーター作成後, 「VPNトンネルを追加」する。

各項目を記入し, BGPセッションの編集ボタンをクリック。

ここでは家側のAS Noを65000とし, トンネル間のセグメント情報を記入する。

設定の結果を確認。

これでGCP側は完了。

2. VPN設定(Cisco)

VTIに準じた設定を入れていく。
関連Config抜粋

crypto ikev2 proposal GCP_proposal
encryption aes-cbc-256 aes-cbc-192 aes-cbc-128
integrity sha256
group 16
!
crypto ikev2 policy GCP_policy
proposal GCP_proposal
!
crypto ikev2 keyring GCP_Key
peer GCP
address <GCPのIPアドレス>
pre-shared-key <共有キー>
!
!
!
crypto ikev2 profile IKEv2_Profile
match identity remote address <GCPのIPアドレス> 255.255.255.255
identity local address <家のGlobal IP>
authentication remote pre-share
authentication local pre-share
keyring local GCP_Key
lifetime 3600
!
!
crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
mode tunnel
!
crypto ipsec profile GCP_Profile
set transform-set TS
set pfs group16
set ikev2-profile IKEv2_Profile
!
crypto ipsec profile VTI
set transform-set TS
set pfs group16
!
interface Tunnel1
ip address 169.254.1.2 255.255.255.252
tunnel source Vlan100
tunnel mode ipsec ipv4
tunnel destination <GCPのIPアドレス>
tunnel protection ipsec profile GCP_Profile
!
!
router bgp 65000
bgp log-neighbor-changes
network 192.168.1.0
network 192.168.10.0
neighbor 169.254.1.1 remote-as 64512
!

通信確認

#ping 10.10.10.10 source 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 160/160/160 ms

IPSecステータス

#show crypto session
Crypto session current status

Interface: Tunnel1
Profile: IKEv2_Profile
Session status: UP-ACTIVE
Peer: 35.231.219.234 port 4500
Session ID: 2209
IKEv2 SA: local 192.168.1.2/4500 remote 35.231.219.234/4500 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map

無事接続確認完了。

GCPとVPN接続する

GCPの$300クレジット(1年)があるのでAWSだけでなくGCPも触ってみる。

例によって自宅とVPN張って見る。構成はこんな感じ。

概略構成

前提条件

  • GCPのアカウント設定済み
  • (VPC作成後)インスタンスは作成済み
  • 家側のNAT等の転送ルールは設定済み
  • 今回はポリシーベースVPNとするので GRE over IPSec (訂正:GRE使いません)

流れ

1. VPC作成
2. サブネット作成
3. FW設定
4. インスタンス作成(ここでは省略)
5. VPN設定(GCP & Cisco)

Google Cloud Consoleにログインして, VPCネットワークを作成する。

1. VPC作成

「VPCネットワーク」から「VPCネットワーク」を選択

「VPCネットワークを作成」を選択

2.  サブネット作成

必要事項記入して「作成」

この後, 作成したサブネット上にインスタンスを作成する。(手順は省略)

3. FW設定

サブネットに対する通信許可設定を入れる。
VPCから作成したVPC「vpc01」を選択
ファイアウォールルールを選択し, ルールの追加をクリック
※画像は既に作成済み
ルールを記入していく
ここでは自宅の環境からサブネット全体に対して全て通信許可としている
完了

4. VPN作成

「VPCネットワーク」から「VPN」選択

「VPN接続を作成」をクリック

必要事項を記入する。IPアドレスはプルダウンをクリックして新規作成する。

名前を適当につけて「予約」

するとGlobal IP Addressが割当たる

内容確認して「完了」をクリック

GCP側はこれで準備完了

5. Ciscoルータの設定

GCPでサポートしている暗号化セットはここに記載されている。
Supported IKE Ciphers

関連Config抜粋

!
crypto ikev2 proposal GCP_proposal
encryption aes-cbc-256 aes-cbc-192 aes-cbc-128
integrity sha256
group 16
!
crypto ikev2 policy GCP_policy
proposal GCP_proposal
!
crypto ikev2 keyring GCP_Key
peer GCP
address <GCPのIPアドレス>
pre-shared-key <設定した共有キー>
!
!
!
crypto ikev2 profile IKEv2_Profile
match identity remote address <GCPのIPアドレス> 255.255.255.255
identity local address <家のGlobal IP>
authentication remote pre-share
authentication local pre-share
keyring local GCP_Key
lifetime 3600
!

crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
mode tunnel
!
crypto ipsec profile GCP_Profile
set transform-set TS
set pfs group16
set ikev2-profile IKEv2_Profile
!
!
crypto map GCP_map 5 ipsec-isakmp
set peer <GCPのIPアドレス>
set transform-set TS
set pfs group16
set ikev2-profile IKEv2_Profile
match address GCP_ACL
!
!
interface Vlan100
description to 192.168.1.0/24
ip address 192.168.1.2 255.255.255.0
crypto map GCP_map
!
ip access-list extended GCP_ACL
permit ip 192.168.0.0 0.0.255.255 10.10.10.0 0.0.0.255
!
!

通信確認

Ping確認

#ping 10.10.10.10 source 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 160/162/164 ms

IP-Secステータス

#show crypto session
Crypto session current status

Interface: Vlan100
Profile: IKEv2_Profile
Session status: UP-ACTIVE
Peer: 35.231.219.234 port 4500
Session ID: 2208
IKEv2 SA: local 192.168.1.2/4500 remote <GCPのIPアドレス>/4500 Active
IPSEC FLOW: permit ip 192.168.0.0/255.255.0.0 10.10.10.0/255.255.255.0
Active SAs: 2, origin: crypto map

以上。
次はルートベースのVPN設定を試す。

ちなみに, MTUサイズを確認してみるとトンネルのオーバーヘッド含めて1422だった。

$ ping 10.10.10.10  -s 1394 -M do
PING 10.10.10.10 (10.10.10.10) 1394(1422) bytes of data.
1402 bytes from 10.10.10.10: icmp_seq=1 ttl=63 time=162 ms
1402 bytes from 10.10.10.10: icmp_seq=2 ttl=63 time=161 ms
1402 bytes from 10.10.10.10: icmp_seq=3 ttl=63 time=160 ms
^C
--- 10.10.10.10 ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3001ms
rtt min/avg/max/mdev = 160.511/161.357/162.479/0.947 ms
$ ping 10.10.10.10 -s 1395 -M do
PING 10.10.10.10 (10.10.10.10) 1395(1423) bytes of data.
ping: sendmsg: Message too long
ping: sendmsg: Message too long
ping: sendmsg: Message too long
^C
--- 10.10.10.10 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2004ms

OpenStackにEVE-NGをたてる

WinPC上のVMWare Playerではなく, OpenStackのインスタンスとしてEVE-NGをたてる。

手順

  1. EVE-NG公式サイトからovaファイルをダウンロードする
  2. ovaファイルからvmdkファイルを抽出する
  3. vmdkファイルをqcow2へ変換
  4. OpenStackにイメージ登録
  5. 起動

1と2はそのままなのでスキップ。

3. qcow2変換

qemu-img convert -f vmdk -O qcow2 ./EVE_Community_VM-disk1.vmdk EVE_Community_VM-disk1.qcow2

4. イメージ登録

 openstack image create --file ./EVE_Community_VM-disk1.qcow2 --disk-format qcow2 EVE-NG

5. 起動

ダッシュボードからでもCLIからでも。

openstack server create --image EVE-NG --flavor m1.large --network external EVE-NG

dockerでファイルサーバ立てる

背景

今まではOpenStackにCentOSでファイルサーバ立てていたけれど, OpenStack再構築ややらかしちゃったときに退避データが被害受けるのは辛い。
ということで, せめてホストOS直でファイルサーバを立てようかと思ったが, せっかくKollaでOpenStack立てて, dockerが入っているのだからコンテナでファイルサーバ立ててみようと思った。

コンテナでsambaを立てる

参考情報

Docker上 で samba を動かしてファイル共有する
dperson/samba
docs.docker.com
Docker道場「Dockerの基本概念」0825インフラ勉強会資料

手順

  1. ファイルマウント用のディレクトリ作成
  2. アカウントにdocker権限付与
  3. sambaコンテナデプロイ
  4. smb.conf編集
  5. コンテナ再起動

1.共有ディレクトリ準備

/share/NAS という場所にする。

mkdir /share/NAS
chmod 777 /share/NAS

2.dockerグループ追加

root以外のアカウントでコンテナ実行したいのでdockerグループに追加。(セキュリティ的に好ましくないそう)

sudo usermod -aG docker user

コンテナデプロイ

$ docker run --name NAS             # コンテナ名
-p 139:139 -p 445:445 # ポート139と445を開放
-v /share/NAS:/mnt/nas # /share/NAS を /mnt/nas にバインド
-d dperson/samba # dperson/samba をデプロイ
-u "samba;sambapass" # dperson option) samba ユーザを作成(パスワードも一緒に)
-s "nas:/mnt/nas;no;no;no;samba" # dperson option) /mnt/nasを nas という名前で, 公開せず, ROせず, ゲストも拒否, sambaユーザ限定

3.smb.conf編集

デフォルトだとsmbuserに作成者とか上書きされるので, コンテナにログインしてsmb.confを編集。

$ docker exec -it NAS /bin/bash
bash-4.4#

vi /etc/samba/smb.conf

   pam password change = yes
map to guest = bad user
usershare allow guests = yes
create mask = 0664
force create mode = 0664
directory mask = 0775
force directory mode = 0775
# force user = smbuser #コメントアウト
# force group = users #コメントアウト
follow symlinks = yes
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
socket options = TCP_NODELAY
strict locking = no
vfs objects = recycle
recycle:keeptree = yes
recycle:versions = yes
min protocol = SMB2

4.コンテナ再起動

$ docker restart NAS

完成。確認。

アクセスできてファイルも置けた

$ ls /share/NAS/
test test2

ファイルも置けている。確かに早い!

OpenStack Kolla Horizon HTTPS化

horizon のコンテナでhorizonをHTTPS化する。

手順

  1. horizon コンテナにログイン
  2. /etc/httpd/conf.d/ssl.conf 修正
  3. コンテナ再起動

ログイン

# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ab109739a033 kolla/centos-source-manila-share:queens "kolla_start" 2 hours ago Restarting (1) 51 seconds ago manila_share
43c45131b740 kolla/centos-source-manila-scheduler:queens "kolla_start" 2 hours ago Up 2 hours manila_scheduler
313fcf872a06 kolla/centos-source-manila-data:queens "kolla_start" 2 hours ago Up 2 hours manila_data
e8d723fef1a4 kolla/centos-source-manila-api:queens "kolla_start" 2 hours ago Restarting (1) 4 seconds ago manila_api
df0eeda4a35b kolla/centos-source-horizon:queens "kolla_start" 2 hours ago Up 3 minutes horizon
ba1aa66b3c70 kolla/centos-source-heat-engine:queens "kolla_start" 2 hours ago Up 2 hours heat_engine
7a99a622e247 kolla/centos-source-heat-api-cfn:queens "kolla_start" 2 hours ago Up 2 hours heat_api_cfn
d3b5669aff16 kolla/centos-source-heat-api:queens "kolla_start" 2 hours ago Up 2 hours heat_api
7c6b49e46961 kolla/centos-source-neutron-bgp-dragent:queens "kolla_start" 2 hours ago Up 2 hours neutron_bgp_dragent
7b043fc70e34 kolla/centos-source-neutron-metadata-agent:queens "kolla_start" 2 hours ago Up 2 hours neutron_metadata_agent
cb58001b41f6 kolla/centos-source-neutron-l3-agent:queens "kolla_start" 2 hours ago Up 2 hours neutron_l3_agent
1d5fc5630757 kolla/centos-source-neutron-dhcp-agent:queens "kolla_start" 2 hours ago Up 2 hours neutron_dhcp_agent
b2fc74c8e428 kolla/centos-source-neutron-openvswitch-agent:queens "kolla_start" 2 hours ago Up 2 hours neutron_openvswitch_agent
3e8ef7289077 kolla/centos-source-neutron-server:queens "kolla_start" 2 hours ago Up 2 hours neutron_server
832cae84fab4 kolla/centos-source-openvswitch-vswitchd:queens "kolla_start" 2 hours ago Up 2 hours openvswitch_vswitchd
4dd0a7fa6d31 kolla/centos-source-openvswitch-db-server:queens "kolla_start" 2 hours ago Up 2 hours openvswitch_db
8096e4ec00e5 kolla/centos-source-nova-compute:queens "kolla_start" 2 hours ago Up 2 hours nova_compute
ea8129516288 kolla/centos-source-nova-novncproxy:queens "kolla_start" 2 hours ago Up 2 hours nova_novncproxy
6703fef99aab kolla/centos-source-nova-consoleauth:queens "kolla_start" 2 hours ago Up 2 hours nova_consoleauth
fb2068c78891 kolla/centos-source-nova-conductor:queens "kolla_start" 2 hours ago Up 2 hours nova_conductor
97057ff78bb6 kolla/centos-source-nova-scheduler:queens "kolla_start" 2 hours ago Up 2 hours nova_scheduler
25e12c436198 kolla/centos-source-nova-api:queens "kolla_start" 2 hours ago Up 2 hours nova_api
f3d3d445c1d2 kolla/centos-source-nova-placement-api:queens "kolla_start" 2 hours ago Up 2 hours placement_api
f47d12a757df kolla/centos-source-nova-libvirt:queens "kolla_start" 2 hours ago Up 2 hours nova_libvirt
1d8e05ba3c99 kolla/centos-source-nova-ssh:queens "kolla_start" 2 hours ago Up 2 hours nova_ssh
810e9ff31daf kolla/centos-source-cinder-backup:queens "kolla_start" 2 hours ago Up 2 hours cinder_backup
3bf3abd9b269 kolla/centos-source-cinder-volume:queens "kolla_start" 2 hours ago Up 2 hours cinder_volume
417c1087b432 kolla/centos-source-cinder-scheduler:queens "kolla_start" 2 hours ago Up 2 hours cinder_scheduler
fda972374b3f kolla/centos-source-cinder-api:queens "kolla_start" 2 hours ago Up 2 hours cinder_api
fd9107b2cc79 kolla/centos-source-glance-api:queens "kolla_start" 2 hours ago Up 2 hours glance_api
b814c910e21f kolla/centos-source-keystone-fernet:queens "kolla_start" 2 hours ago Up 2 hours keystone_fernet
7bda77c6543d kolla/centos-source-keystone-ssh:queens "kolla_start" 2 hours ago Up 2 hours keystone_ssh
0a151029226c kolla/centos-source-keystone:queens "kolla_start" 2 hours ago Up 2 hours keystone
d76caff26d23 kolla/centos-source-rabbitmq:queens "kolla_start" 2 hours ago Up 2 hours rabbitmq
113a23dfefb6 kolla/centos-source-mariadb:queens "kolla_start" 2 hours ago Up 2 hours mariadb
d64c194fa844 kolla/centos-source-memcached:queens "kolla_start" 2 hours ago Up 2 hours memcached
4ce505333564 kolla/centos-source-chrony:queens "kolla_start" 2 hours ago Up 2 hours chrony
c230924e585e kolla/centos-source-cron:queens "kolla_start" 2 hours ago Up 2 hours cron
5d9710d55d76 kolla/centos-source-kolla-toolbox:queens "kolla_start" 2 hours ago Up 2 hours kolla_toolbox
b9bc9d971441 kolla/centos-source-fluentd:queens "kolla_start" 2 hours ago Up 2 hours fluentd
# docker exec -it horizon /bin/bash
(horizon)[root@openstack /]#

ssl.conf 修正

(自己証明書はすでに作成されているのでそのまま利用する)
最終行に以下追加。

Listen 443 https #コメント削除
<Location />
Require all granted
</Location>
WSGIScriptReloading On
WSGIDaemonProcess horizon-https processes=5 threads=1 user=horizon group=horizon display-name=%{GROUP} python-path=/var/lib/kolla/venv/lib/python2.7/site-packages
WSGIProcessGroup horizon-https
WSGIScriptAlias / /var/lib/kolla/venv/lib/python2.7/site-packages/openstack_dashboard/wsgi/django.wsgi
WSGIPassAuthorization On
WSGIApplicationGroup %{GLOBAL}

Alias /static /var/lib/kolla/venv/lib/python2.7/site-packages/static

コンテナ再起動

docker restart horizon

アクセスすると。

無事HTTPS化された

パスワードの定期的変更

総務省が方針変更したというニュースを受けて, その他界隈はどうなっているのかググってみた。

総務省:定期的変更は不要(2018年3月1日に方針変更)
http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/basic/privacy/01-2.html

内閣サイバーセキュリティセンター(NISC):定期的変更は不要(ハンドブック ver3.0)
https://www.nisc.go.jp/security-site/files/handbook-all.pdf

経産省:パスワードは随時変更(定期的とは言っていない)
http://www.meti.go.jp/policy/netsecurity/UAaccessCMG.htm

IPA:定期的変更には意味がある(あくまで予防的?)
https://www.ipa.go.jp/security/personal/onlinegame/index.html

海外ではずいぶん前からパスワードの定期的変更はセキュリティ上問題となりえると言われているようです。
https://www.schneier.com/blog/archives/2016/08/frequent_passwo.html

OpenStack Queens をKollaで入れ直す

Newtonのリポジトリがなくなっているので, Kollaで入れ直すことにした。
都度対処療法で進めていったので, 一般的な流れでは無いことをご了承ください。

まず, Packstack環境をこちらのスクリプトで削除する。
付録A PackStack デプロイメントの削除

# ./unpack.sh

一旦再起動&yum update。

# yum update -y

ここからはオフィシャルのページを参考にすすめていく・・・とやってみはいいけれど, うまくいかなかったのでQiitaのこちらも参考にやっていく。
Kolla Ansible Quick Start
kolla-ansibleでOpenStack(stable/queens)を構築する

最小要件は

  • NIC 2つ
  • メモリ 8GB以上
  • ディスク 40GB

今回はRDOの名残のbr-exをマネジメント用にして, もう一方のNICをExternal用にする。
External用のNICはIP無し。
と思ってやってみたけれど, 実際やってみるとbr-exはprecheck時にエラーになるので, openvswitchを利用せず, 物理NICに戻す必要あり。

1. 事前準備

$ sudo yum install epel-release
$ sudo yum install python-pip
$ sudo pip install -U pip
$
$ sudo yum install python-devel libffi-devel gcc openssl-devel libselinux-python
$
$ sudo yum install ansible

/etc/ansible/ansible.cfg 編集。

[defaults]
host_key_checking=False
pipelining=True
forks=100

その他, openstack-newtonのリポジトリで入れたPython系はごっそり消してキレイにしておく。

2. Kolla-ansible インストール

この手順でエラーがでる。

pip install -r kolla/requirements.txt

<エラーメッセージ>

oslo-config 6.4.0 has requirement PyYAML>=3.12, but you'll have pyyaml 3.10 which is incompatible.

この対応のため, 以下インストール実施。

$ wget http://pyyaml.org/download/pyyaml/PyYAML-3.12.tar.gz
$ tar xvfz ./PyYAML-3.12.tar.gz
$ sudo python ./PyYAML-3.12/setup.py install

今一度ansible インストール

$ sudo yum install ansible
$ sudo pip install -r kolla/requirements.txt
$ sudo pip install -r kolla-ansible/requirements.txt

うまくいった。

3. 初期設定ファイル準備

今回はAll-in-oneなので特にファイルいじらない。

$ sudo ansible -i all-in-one all -m ping
localhost | SUCCESS => {
"changed": false,
"ping": "pong"
}

成功。

4. Kolla パスワード設定

$ sudo kolla-genpwd

5. Kolla globals.yml 編集

kolla_base_distro: "centos"
kolla_install_type: "source"
openstack_release: "queens"
kolla_internal_vip_address: "192.168.1.100"
docker_registry: ""
network_interface: "enp4s0"
neutron_external_interface: "enp1s0"
enable_neutron_provider_networks: "yes" #追加(2018/08/29) 外部ネットワークにつなげたい時はこれ必要
enable_cinder: "yes"
enable_cinder_backup: "yes"
enable_cinder_backend_nfs: "yes"
enable_haproxy: "no"
enable_heat: "yes"
enable_horizon: "yes"
enable_manila: "yes"
enable_manila_backend_generic: "yes" #追加(2018/08/25)
enable_neutron_bgp_dragent: "yes"
glance_backend_file: "yes"
enable_cinder_backend_nfs: "yes"
nova_compute_virt_type: "kvm"
tempest_image_id:
tempest_flavor_ref_id:
tempest_public_network_id:
tempest_floating_network_name:

6.NFS設定

/share/cinder をcinderの共有先とした。
/etc/kolla/config/nfs_shares 編集

#storage01:/share/cinder    #コメントアウト
localhost:/share/cinder #all-in-oneなのでlocalhostに編集

7. デプロイ

$ sudo kolla-ansible -i all-in-one bootstrap-servers
$ sudo kolla-ansible -i all-in-one prechecks
$ sudo kolla-ansible -i all-in-one deploy
$ sudo kolla-ansible post-deploy

8. OpenStack CLIインストール

色々と依存関係でエラーが出たので対処療法で以下実施。
sudo mv ./ipaddress* /tmp/

sudo mv /lib/python2.7/site-packages/pyinotify* /tmp/
pip install python-openstackclient python-glanceclient python-neutronclient

この後, これも足りないとインストール。

sudo yum install python-stevedore.noarch

そしてサンプル構成をデプロイ時にまたエラーが出て以下対応をした。

sudo yum install python-stevedore.noarch

9. デプロイ

改めてサンプル構成デプロイ実行。

. /etc/kolla/admin-openrc.sh
. /usr/share/kolla-ansible/init-runonce

一応できている。

$ openstack subnet list
+--------------------------------------+----------------+--------------------------------------+-------------+
| ID | Name | Network | Subnet |
+--------------------------------------+----------------+--------------------------------------+-------------+
| 0d5a4b6f-a873-4ea1-9b50-f4f7b2c52c95 | public1-subnet | 6c5000d4-6cdc-4ded-8e04-dce9f85dd4eb | 10.0.2.0/24 |
| 72bd7b51-9ab0-4be3-956a-dd3ce1085048 | demo-subnet | ccc2adc9-9b5e-42c6-9787-b19d11605f63 | 10.0.0.0/24 |
+--------------------------------------+----------------+--------------------------------------+-------------+

ダッシュボードにアクセス。
http://<kolla_internal_vip_address>

https化したいけれど, どうしたらいいのだろう

ひとまず無事?にできたので今日はここまで。

はじめてのAnsible on EVE-NG

EVE-NGでAnsibleを触ってみるための環境構築メモ。

手順

  1. VMWare Playerで仮想マシンのNIC追加
  2. Ubuntu VMを立てる
  3. Ansible 入れる
  4. Playbook試す

VMWare Playerで仮想マシンのNIC追加

シミュレータ上でUbuntuをたて, apt-getでAnsibleをインストールするために外部接続用のNICを追加する。

ブリッジタイプのvNICを追加

外部ネットワークとの接続設定の確認。
eth1はCloud1に, eth2はCloud2というようにブリッジの設定が入っている。

# Cloud devices
iface eth1 inet manual
auto pnet1
iface pnet1 inet manual
bridge_ports eth1
bridge_stp off

iface eth2 inet manual
auto pnet2
iface pnet2 inet manual
bridge_ports eth2
bridge_stp off

今回はeth1が外部接続用のネットワークとなる。

簡単な構成イメージ

Ubuntu VMを立てる

ubuntuイメージは以下からダウンロードする。
linux_image_for_eve_pro
ちなみにバージョンは16.04.4。

その後はオフィシャルにある通りのやり方でイメージを登録する。

# cp ./virtioa.qcow2 /opt/unetlab/addons/qemu/linux-ubuntu-srv-16.04.4-webmin/
# /opt/unetlab/wrappers/unl_wrapper -a fixpermissions

これでVMを登録できる。

Linuxが選択できるようになる

追加したubuntuのイメージで起動
今回はNICは2つ

Cloud1とUbuntuを接続してInternetにつながるか確認。

テスト環境はこんな感じ
「To Internet」とあるのがCloud1

Ansibleインストール

UbuntuにログインしてアップデートからのAnsibleインストール。
オフィシャルドキュメントに従っていけばOK。
ただし, このイメージだとwebminのリポジトリがリンク切れ?なのかエラーになるので, これをコメントアウトする。

# vi /etc/apt/sources.list

# deb http://download.webmin.com/download/repository sarge contrib

Ansibleインストール。

# apt-get update
# apt-get install software-properties-common
# apt-add-repository ppa:ansible/ansible
# apt-get update
# apt-get install ansible

完了。

Playbookお試し

ルータ4台構成し, バナーメッセージを変更するPlaybookを作成して試行する。
事前準備として, ルータにはIPアドレス設定とSSH設定までは行っておく必要がある。(AnsibleはSSH接続前提のため)

まず最初に /etc/ansible/hosts の設定をする。ここに管理対象となる機器のIPアドレス(ないしはホスト名)を記述する。今回は簡単にルータのIPアドレスを記述し, それらをCiscoというグループでまとめる。
# vi /etc/ansible/hosts

[Cisco]
10.10.10.2
10.10.10.3
10.10.10.4
10.10.10.5

[Cisco:vars] # Ciscoグループ共通のパラメータ設定
ansible_connection=network_cli # ネットワーク機器なので network_cli を指定する
ansible_network_os=ios # Ciscoのiosを指定する
ansible_user=cisco # SSHのログインユーザ名
ansible_ssh_pass=cisco # SSHのログインパスワード(本番環境では非推奨)
ansible_become=yes # 特権モードになるか
ansible_become_method=enable # Ciscoなのでenable
ansible_become_pass=cisco # enable パスワード

Playbook準備。

# vi ~/playbook/ios.yml

- hosts: Cisco                                    # Ciscoグループ対象
gather_facts: no # 機器情報取得しない

tasks: # タスクを登録
- name: insert banner # 1つ目。バナー入れるタスク
ios_banner: # ios_banner というモジュールを利用
banner: motd # motd を対象
text: | # バナーメッセージ登録
You are logged in on $(hostname)
state: present # 登録。absent ならバナー削除

- name: save running to startup when modified # 設定保存するタスク
ios_config: # iso_config というモジュール利用
save_when: modified # 変更されていれば保存実行

実行結果。
# ansible-playbook ios.yml

root@ubuntu:~/playbook# ansible-playbook ./ios.yml

PLAY [Cisco] *********************************************************************************************************************************************************

TASK [insert banner] *************************************************************************************************************************************************
changed: [10.10.10.5]
changed: [10.10.10.4]
changed: [10.10.10.3]
changed: [10.10.10.2]

TASK [save running to startup when modified] *************************************************************************************************************************
changed: [10.10.10.2]
changed: [10.10.10.4]
changed: [10.10.10.3]
changed: [10.10.10.5]

PLAY RECAP ***********************************************************************************************************************************************************
10.10.10.2 : ok=2 changed=2 unreachable=0 failed=0
10.10.10.3 : ok=2 changed=2 unreachable=0 failed=0
10.10.10.4 : ok=2 changed=2 unreachable=0 failed=0
10.10.10.5 : ok=2 changed=2 unreachable=0 failed=0

すっごい簡単。
ログインしてみると・・・。

ちゃんと変わっている

Ansibleは冪等性といわれる「何度やっても同じ結果が得られる」というコンセプトのもと開発されているので, このPlaybookを2回目やってみると,

root@ubuntu:~/playbook# ansible-playbook ./ios.yml

PLAY [Cisco] *********************************************************************************************************************************************************

TASK [insert banner] *************************************************************************************************************************************************
ok: [10.10.10.3]
ok: [10.10.10.5]
ok: [10.10.10.4]
ok: [10.10.10.2]

TASK [save running to startup when modified] *************************************************************************************************************************
ok: [10.10.10.3]
ok: [10.10.10.4]
ok: [10.10.10.2]
ok: [10.10.10.5]

PLAY RECAP ***********************************************************************************************************************************************************
10.10.10.2 : ok=2 changed=0 unreachable=0 failed=0
10.10.10.3 : ok=2 changed=0 unreachable=0 failed=0
10.10.10.4 : ok=2 changed=0 unreachable=0 failed=0
10.10.10.5 : ok=2 changed=0 unreachable=0 failed=0

このように, 「changed=0」と変更したものは無いよ, という結果になる。スバラシイ。マクロよりも全然よいと思われる。

まだ手を付け始めたばかりのため理解及んでいませんが, これはすごい楽しい未来がやってくる気がする。なので, これからどんどん試していく。

なお, ネットワーク機器においてのAnsibleはこちらのスライドが超絶わかりやすいのでオススメです。

【メモ】EVE-NGのキャプチャ

EVE-NGのrootのパスワード変えると、キャプチャ用のバッチファイルの中身も変えないとキャプチャ開始時に「unable connect」って出る。

C:Program FilesEVE-NGwireshark_wrapper.bat の3行目

@ECHO OFF
SET USERNAME="root"
SET PASSWORD="eve" #これ