/
カテゴリー
 /

1問目

問題文

LinuxカーネルでXenが動作するアーキテクチャとして最も近いものを答えてください。

  • KVM
  • Docker
  • VirtualBox
  • Hyper-V

解説

  • KVM
    • ネイティブ型ハイパーバイザ
    • モノリシックカーネルアーキテクチャ
  • Docker
    • アプリケーションコンテナ
  • VirtualBox
    • ホスト型ハイパーバイザ
  • Hyper-V
    • ネイティブ型ハイパーバイザ
    • マイクロカーネルアーキテクチャ
  • OpenVZ
    • OSコンテナ

Docker, OpenVZと言ったソフトはコンテナ仮想化であり、カーネルを全ての仮想マシンで共有してユーザ空間を隔離する技術です。

VirtualBoxはQemuと同じように、OSの上でソフトウェアを起動し、OSの機能を利用して仮想化を行う技術です。

KVM・Xen・Hyper-Vと言ったソフトは、仮想化とその管理の機能を含めたOS制御全ての機能をカーネルに含めたアーキテクチャです。

このうち、KVMでは管理カーネル上でその他のプログラムが動作しますが、
Xenではdom0と呼ばれる管理用の仮想マシンが作成され、その上でカーネルに対して仮想化サーバーの起動などを命令します。
Hyper-VはXenと同様に、管理を行うための仮想マシンが作成され、その上で管理用のプログラムやGUIが動作しています。

Xenでは、管理用の仮想マシンをDomain-0(dom0)、その他の仮想マシンをDomain-U(domU)と呼び、
Hyper-Vではそれぞれ親パーティション (Root Partition, Parent Partition)、子パーティション (Child Partition)と呼びます。

講評

調べればわかる問題ということもあり、問題の正答率は高かったです。
誤答を見ると、同じLinux OS上で動作するということからか「KVM」を選択するチームも見られました。
仮想化を扱う際にはその仮想化の動作原理を知るとトラブルシューティングの際に便利なことがあります。

2問目

問題文

Xenのトラブルシューティングを行う際に見るべきファイル・実行するべきコマンドを箇条書きで答えよ。
なおこの問題はファイル・コマンドの出力結果から見ることの出来る情報の種類や重要度により点数が増減する。

解説

Xenでは、ログファイルを /var/log/xen に保存しています。
また、Xenの管理を行うプログラムに xm (以前のバージョンは xl )があります。
Xenのシステムのトラブルシューティングはこれらのファイル・コマンドで充分に行えます。
またその他にも /var/lib/xen/, /var/xen/dump/ に内部で生成されるダンプやデータベースが、
/etc/xenに設定ファイルが、
/proc/xenでXenのカーネル情報が取得できます。

参考: 第32章 Xen para-virtualized ドライバーのトラブルシューティング – Red Hat Customer Portal

その他、この問題では言及していないものとして、現在稼働中の物を確認するためのコマンドとしてのxentop
libvirtを使用している場合はそれに関連するディレクトリ、
ネットワークに関連するトラブルとしては ネットワークのパケットキャプチャなど、仮想マシンのトラブルシューティングでは見るべき部分が多数あります。

今回の問題はXen本体のトラブルを解決するために必要なファイル・コマンド群双方に言及している場合に最高点数を付与しています。
ファイルのみ・コマンドのみの場合は取得できる情報から30%〜70%で付与しています。
その他のトラブルについて解決するためのコマンド類を記述しているチームには、問題の最高点を上限として加点をしています。

講評

問題文と自由記述の欄から、回答に苦労したチームが多かったのではと思います。
問題文に「見るべきファイル・実行するべきコマンド」と明記しており、ファイルとコマンド双方を回答してくれることを想定していたのですが、コマンドのみ・ログファイルのディレクトリのみの回答も複数ありました。
中には20以上のファイル・コマンドを回答として提出したチームもありました。
情報の中からトラブルの原因を見つけ出し解決に漕ぎ着ける為に、トラブルごとに見るべき項目は異なります。
その際に「どの情報が必要か」を考え、その時々で適切なコマンドの実行・ファイルの閲覧を行うことが大切です。
この時に「どのコマンドで何が取得できる」という事を知っておく事はプラスになります。

3問目

問題文

Xenの仮想化方式にPVとHVMがありますが、それぞれの違いについて説明してください。

解説

まずPVですが、これはCPUの機能である仮想化支援がなくてもVMを動作させることができる方式です。ただし、VMを動作させるにはPVに対応するドライバが必要なので、そのドライバを別途インストールする必要があります。また、Xenに対応したゲストOSを用いることで、ハードウェアを触らずに高速動作しますが、メモリマッピングといった直接ハードウェアを触る部分で遅延が発生する欠点があります。
HVMはPVと違い、使用するCPUに仮想化支援の機能が必要です(intelならVT-x, AMDならAMD-V)。HVMはqemuを使用してBIOSや様々なコントローラをエミュレートするため、PVのように専用ドライバをインストールする必要がありません。仮想化支援の機能を使うのでハードウェアを触る処理が高速に行える特徴を持ちます。

講評

XenはAmazonが運営しているAWSに採用されています。そのためか、解答にAWS特有の名称などを用いて説明しているチームが複数ありました。
全体的に見てしっかりと説明しているチームが多かったなと思います。

4問目

問題文

PVとHVMを組み合わせたPVHがりますが、この仮想化方式についてPVとHVMを使って説明してください。

解説

3問目の解説にもある通り、PVはXenに対応したゲストOSを用いることで、ハードウェアを触らずに高速動作しますが、メモリマッピングといった直接ハードウェアを触る部分で遅延が発生します。PVの欠点であるハードウェアを触る処理を、HVMで使われている仮想化支援の機能を使って高速にできるのがPVHとなります。

講評

3問目より4問目の方が回答率が高かったです。

 /

問題文

上記のトポロジー図の通りに配線してある機材に設定を投入しましたが、Router-Bから対外への疎通が取れません。
そのため、Router-Bから対外疎通がとれるようにしたいと考えています。
Router-AにGigabitEthernet1側が外部ネットワーク、
GigabitEthernet2側が内部ネットワークとなるようにNATの設定を書き加え、
Router-Bからインターネット(例えばIPアドレス8.8.8.8)へpingを飛ばせるようにしてください。
pingを飛ばす際、経路はRouter-Aを経由します。
Router-AでIPアドレスの設定変更をする必要はありません。

解答メールを送る際は、
・参加者が設定したコンフィグ
・Router-Bからのpingコマンド実行結果
を添えて下さい。

ゴール

Router-AにNATの設定を書き加え、Router-BからRouter-Aを経由してインターネットにpingを飛ばせるようにする。

トラブルの概要

Router-Bから、Router-Aを経由して対外接続がはかれない。

解説

今回はCiscoのルータにNATの設定を書き加えてもらう問題でした。
Router-Bは、Router-AにNATの設定を施すことによって対外疎通が可能になります。
こちらの解説では、当初想定していた回答とよく見られた別解を説明します。

まず、当初想定していたNAPT(PAT)の説明をします。
NAPTの設定をする際はまずNAPT変換対象とする送信元IPアドレスをAccess-listで定義する必要があります。
access-list 1 permit any
例えば上記のように設定すると、全ての送信元IPアドレスを許可します。
続いて先程定義したAccess-listと外部インターフェースを関連付けさせます。
ip nat inside source list 1 interface GigabitEthernet1 overload
最後にどのインターフェースを「内部ネットワーク」または「外部ネットワーク」に指定するのか定義します。
ip nat outside
ip nat inside

続いてよく見られた別解であるスタティックNATを説明します。
NAT変換する 「 内部ローカルアドレス 」 と 「 内部グローバルアドレス 」を定義します。
ip nat inside source static 10.0.0.100 192.168.0.100
上記では最も多かった192.168.0.100を内部グローバルアドレスとして定義しています。
最後にどのインターフェースを「内部ネットワーク」または「外部ネットワーク」に指定するのか定義します。
ip nat outside
ip nat inside

なお、Poolを用いたNATやNAPTで設定していても正答となります。

解答例

NAPT(PAT)の場合

!Router-A
!
enable
!
configure terminal
!
!
access-list 1 permit any
ip nat inside source list 1 interface GigabitEthernet1 overload
!
!
interface GigabitEthernet1
ip nat outside
!
exit
!
interface GigabitEthernet2
ip nat inside
!

 

[別解]スタティックNATの場合

!Router-A
!
enable
!
configure terminal
!
!
ip nat inside source static 10.0.0.100 192.168.0.100
!
!
interface GigabitEthernet1
ip nat outside
!
exit
!
interface GigabitEthernet2
ip nat inside
!

採点基準

  • グローバルコンフィグレーションモードでNATの設定をしている(30%)
  • 内部ネットワーク,外部ネットワークの指定を各インターフェースに適切に設定している(30%)
  • 8.8.8.8等グローバルIPアドレスにpingが通る(40%)

講評

こちらはトラブルを解決するのではなく、参加者に一部だけ構築してもらう問題でした。そのためか回答結果がチームによってさまざまでとても面白かったです。回答を提出してくださったチームのうち、正答であるチームは多かったです。

 /

問題文

Kubernetes クラスタ環境を移行後、Kubernetes上のWordPressにアクセスできなくなりました。
原因をつきとめ、修正してください。

情報

Kubernetesクラスタの移行手順書は存在しません。アドレスレンジに以下の変更があったことのみ分かっています。

Address Range: 172.16.0.0/24 -> 192.168.0.0/24
Cluster Address Range: 192.168.0.0/24 -> 10.254.0.0/24

  • Address Range: Kubernetes Node に振られるアドレスのレンジ
  • Cluster Address Range: Kubernetes Service に振られるアドレスのレンジ

ゴール

VNC 踏み台サーバ上のブラウザにて「192.168.0.1:30080」を入力することで、WordPressの画面が表示される

トラブルの概要

Kubernetes Pod の名前解決に失敗するため、wordpress Pod のセットアップに失敗する。その結果、外部からWordPressへのhttpアクセスに失敗する。

解説

当問題の環境では、kube-apiserver が掴んでいる証明書の Subject Alternative Names (SANs) が誤っていることが原因で、Pod からsvc/kubernetesへhttpsでの通信が失敗します。そのため svc/kubernetes との通信が必要である kube-dns Pod を正常に動作させることが出来ず、wordpress Pod から mysql.default.svc.cluster.local:3306 への通信における名前解決に失敗するため、wordpress Pod のセットアップに失敗するという問題が生じます。

当問題は、kube-apiserver が正常な SANs を持つ証明書を掴むよう、証明書を再生成することで解決します。

なおKubernetesは、kube-apiserverの --tls-cert-file オプションにサーバ証明書、 --tls-private-key-file オプションに秘密鍵、kube-controller-managerの --root-ca-file オプションにCA証明書を指定することで Podからsvc/kubernetesへのhttps通信が可能となります。

回答例

まず、現在のPodの稼働状況を確認します。

# kubectl get pod
NAME READY STATUS RESTARTS AGE
mysql-755f57f594-mc9cr 1/1 Running 1 2h
wordpress-dc9bb949d-9glcx 1/1 Running 4 2h
wordpress-dc9bb949d-sntj9 1/1 Running 4 2h

アクセス先のPodである pod/wordpress のログを確認します。

# kubectl logs wordpress-dc9bb949d-9glcx
WordPress not found in /var/www/html - copying now...
Complete! WordPress has been successfully copied to /var/www/html

Warning: mysqli::__construct(): php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution in Standard input code on line 22

Warning: mysqli::__construct(): (HY000/2002): php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution in Standard input code on line 22

MySQL Connection Error: (2002) php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution
... (省略)

以上のログより名前解決に失敗していることがわかります。/root/manifests/wordpress/deployment-wordpress.yaml の中身を見ると、WORDPRESS_DB_HOST 環境変数に mysql.default.svc.cluster.local というドメイン名が渡されているため、当箇所における名前解決に失敗しているものであると考えられます。

Kubernetesクラスタ内のServiceリソースの名前解決は kube-system ネームスペース内の kube-dns Pod が行います。

kube-dns Pod の稼働状況を確認します。

# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
kube-dns-7c7877989-8frxc 2/3 Running 1 1m

kube-dns Pod のログを確認します。

# kubectl -n kube-system logs kube-dns-7c7877989-8frxc kubedns
...(省略)
E0729 13:29:49.132142 1 reflector.go:201] k8s.io/dns/pkg/dns/dns.go:192: Failed to list *v1.Service: Get https://10.254.0.1:443/api/v1/services?resourceVersion=0: x509: certificate is valid for 172.16.0.1, 192.168.0.1, not 10.254.0.1
E0729 13:29:49.139524 1 reflector.go:201] k8s.io/dns/pkg/dns/dns.go:189: Failed to list *v1.Endpoints: Get https://10.254.0.1:443/api/v1/endpoints?resourceVersion=0: x509: certificate is valid for 172.16.0.1, 192.168.0.1, not 10.254.0.1
...(省略)

以上のエラーログより、kube-apiserverの持つ証明書のSANsに10.254.0.1が存在しないことがわかります。

サーバ証明書に対応する秘密鍵である /etc/pki/tls/kube01/server.key を用いてCSRファイルを再生成します。以下はopensslを用いた例です。

# cat << 'EOF' > /etc/pki/tls/kube01/csr.conf
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[ dn ]
C = JP
ST = dummy
L = dummy
O = dummy
OU = dummy
CN = dummy

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster
DNS.5 = kubernetes.default.svc.cluster.local
DNS.6 = kube01
IP.1 = 192.168.0.1
IP.2 = 10.254.0.1

[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectAltName=@alt_names
EOF
# openssl req -new -key server.key -out server.csr -config csr.conf

CSRファイルに対し、CA証明書である/etc/pki/tls/kube01/ca.crt にて署名を行うことでCRTファイルを生成します。

# openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out server.crt -days 10000 \
-extensions v3_ext -extfile csr.conf

kube-apiserver.service を再起動します。

# systemctl restart kube-apiserver.service

Pod を明示的に再起動させるため、Pod を再作成します。

# kubectl delete -f /root/manifests/kube-dns/kube-dns.yml &amp;amp;amp;&amp;amp;amp; kubectl create -f /root/manifests/kube-dns/kube-dns.yml
# kubectl delete -f /root/manifests/wordpress/wordpress.yaml &amp;amp;amp;&amp;amp;amp; kubectl create -f /root/manifests/wordpress/wordpress.yaml

講評

Kubernetesは利用者が簡単にコンテナのオーケストレーションを行える反面、内部の仕組みは複雑なものになっています。そのためKubernetesについて学ぶ際は、GCP などのクラウドサービスにてKuberntesを利用する他、Kubernetesを実際に構築してみることに是非チャレンジすると良いと思います!

 /

問題文

Router1とRouter2は最近、EBGPピアを張ることを決定しました。Router1に設定を行い、Router2とEBGPピアを張ってください。EBGPピアを張ることができたかどうかは、「show ip bgp summary」で確認できます。
なお、以下の注意事項に沿って設定してください。
・ 設定できるルータはRouter1のみです。
・ Router1のAS番号は「1」で設定してください。
・ Router1のebgp neighborを張る宛先はRouter2のLoopbackを指定してください。

情報

この問題のトポロジー図は以下になります。

「sh ip bgp summary」の結果の一番下の行の右端が「0」になっていれば、ピアを張ることができています。

実行例を以下に記載します。この結果では下の行の右端が「0」になっています。

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 2 6 8 1 0 0 00:03:39 0

スタート

Router1とRouter2間のEBGPピアの設定を行なっていない状態。

ゴール

Router1とRouter2間でEBGPピアが張ることが出来ている。

トラブルの概要

neighborやremote-asの設定だけでLoopback間のEBGPピアを張ることができない。

解説

Router1からRouter2にEBGPピアを張るには、BGP Neighborの設定が必要です。
今回の問題ではCisco機材を使用しているため、Cisco用のコマンドによる設定になります。
具体的には以下のような設定が必要になります。

enable
configure terminal
router bgp 1
neighbor 2.2.2.2 remote-as 2

ですが、これだけではEBGPピアを確立させることはできません。
本来、EBGPピアは、実際に接続されているインターフェース間で行われることが一般的で、
追加の設定をしない限りは、それを前提にピアを張ろうとします。

しかし、今回の問題では、Loopbackインターフェース同士でピアを張る必要があるため、
追加の設定が必要になります。具体的な設定は以下になります。

ip route 2.2.2.2 255.255.255.255 192.168.1.2
neighbor 2.2.2.2 update-source loopback 0
neighbor 2.2.2.2 ebgp-multihop

3つの設定をBGPの設定に加えることで、Loopbackインターフェース間でEBGPピアを張ることができるようになります。

上から、説明していきます。

ip route 2.2.2.2 255.255.255.255 192.168.1.2

これは、Router1がRouter2のLoopbackのアドレスを知らないから疎通性がないことを解消するための設定です。ピアを張る際は、そのインターフェースと疎通性が取れないと張ることができないからです。

neighbor 2.2.2.2 update-source loopback 0

BGPメッセージを送る際の送信元をRouter1 のLoopback 0に指定します。デフォルトでは、送信元はRouter1の物理インターフェースに指定されているため、送信元を変える必要があります。

neighbor 2.2.2.2 ebgp-multihop

EBGPでピアを張る際のBGPのメッセージのTTL(Time to live)の数を増やすために設定します。
EBGPピアを張る際のBGPメッセージのTTLはデフォルトで「1」に設定されているため、Loopbackインターフェース間だとTTLが足りなくパケットロスが起きてしまいます。なお、「ebgp-multihop」の後に引数を指定しないと「255」になります。

以上の設定を踏まえて、最終的な解答コンフィグを以下に記載します。

解答例

!Router-A
!
enable
!
configure terminal
!
ip route 2.2.2.2 255.255.255.255 192.168.1.2
!
router bgp 1
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 update-source loopback 0
neighbor 2.2.2.2 ebgp-multihop
!

採点基準

  • Router2のASに向けて、neighborやremote-asのコマンドが正しく設定できている(10%)
  • Router2のLoopbackに向けて静的ルートを追加されている(30%)
  • update-sourceコマンドでLoopbackを指定することでアドレスが一致している(30%)
  • ebgp-multihopコマンドでTTLの値を「1」より大きな値に変更できている(30%)

講評

この問題はBGPでルーティングを行う際に、最初に行うEBGPピアを張ってもらう問題でした。
Loopbackインターフェースを用いることを前提に設定を組んでいたチームが半分を超えていて、出題してよかったと思います。
EBPGピアを張る際に、Loopbackを用いることもできることを知っていただけたら幸いです。

 /

問題文

toporogy.png
この問題の世界では172.20.0.0/16はインターネットで使われるアドレスで、ISPから割り当てられるものとする。192.168.0.0/16はプライベートIPアドレスである。
ある企業に東京本部と大阪支部があり、大阪支部はISPから172.20.1.1、東京本部には172.20.2.1がそれぞれISPから割り当てられている。またどちらもそれぞれルータ osaka , tokyo でNAPTして使用している。

事前準備

VNCサーバにSSHしたら、そこからPCfumidaiにSSHしてください。アクセス情報は以下の通り。
・IPアドレス:192.168.0.10
・ユーザー名:admin
・パスワード:password

このPCfumidaiはルータosaka配下に設置されたPCで、もう一つのIPアドレス192.168.10.1が割り当てられている。
まず疎通確認として、CloudflareのPublicDNS1.1.1.1にtracerouteして下さい。大体以下のようになればOK。

[admin@fumidai:~]%traceroute 1.1.1.1

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 gateway (192.168.10.254) 1.220 ms 1.138 ms 1.110 ms
2 172.20.1.254 (172.20.1.254) 1.299 ms 1.290 ms 1.298 ms
以下省略

STEP1. GREトンネル開通

現時点では、大阪支部と東京本部では別々にNATしているため、大阪支部から東京にあるサーバにアクセスすることはできない。
これを解決するため、各ルータで拠点間VPNを張る必要がある。(上図紫の部分)
今回は、拠点間VPNの一つであるGRE TunnelをルータosakaにSSHして設定してください。(ルータtokyoの設定は不要)

アクセス情報、および設定要件は以下の通り。
・IPアドレス:192.168.10.254
・ユーザー名:gre
・パスワード:tunnel
・enableパスワード:tunnel

要件
・プロトコル:GRE
・IPアドレス:192.168.100.1/24
・tunnel送信元アドレス:172.20.1.1
・tunnel宛先アドレス:172.20.2.1
・MTU:1400byte

STEP2. default route切替

GRE Tunnelの設定ができましたら、次は、大阪支部から外部へのパケットがすべて東京本部を経由するようにルータosakaに設定してください。

回答項目

以下の内容を回答してください。
・ STEP1で入力したコンフィグ
・ PCfumidaiから東京本部のサーバ192.168.20.1へのtracerouteの結果のコピペ
・ STEP2で入力したコンフィグ
・ 1.1.1.1へtracerouteした結果のコピペ
show running-configのコピペ

ゴール

ゴール (STEP1)

拠点間VPNの一つであるGRE Tunnelをルーターosaka側に設定する

ゴール (STEP2)

大阪支部から外部へのパケットがすべて東京本部を経由するようにルーターosakaに設定する

トラブルの概要

GREトンネルの構築とデフォルトルートの切り替え

解説

GRE(Generic Routing Encapsulation)は、トンネルプロトコルの1つです。トンネルプロトコルにはLayer2トンネリングのL2F、PPTP、L2TPと、Layer3トンネリングのGRE、IPsecなどがあります。このトンネリングとは、あるトラフィックを別のプロトコルでカプセル化して伝送する技術のことです。パケットのカプセル化とその解除はトンネルの両端の機器で行うため、両端の機器が直結しているように見えます。GREトンネリングでは、任意のプロトコルのパケットをIPトンネル内でカプセル化しています。GREトンネリングを行なう両端のルータで、あるトラフィックに対するカプセル化とその解除を行います。
(ネットワークエンジニアとして(https://www.infraexpert.com/study/rp8gre.htm)より)

今回はCiscoのルータでGREトンネルを一から張ってもらい、デフォルトルートを切り替える問題でした。
STEP1はトンネルインターフェースのIPアドレス、GREトンネルの送信元・送信先アドレス、プロトコルとMTUを要件に従って設定するだけで完了します。
STEP2はデフォルトルートの切り替えですが、それだけではGREトンネルでカプセル化されたパケットの経路情報がなくなるため、そのためのスタティックルートを別途設定する必要があります。

解答例

STEP1.

interface Tunnel0
ip address 192.168.100.1 255.255.255.0
tunnel source 172.20.1.1
tunnel destination 172.20.2.1
ip mtu 1400
tunnel mode gre ip
[admin@fumidai:~]%traceroute 192.168.20.1
traceroute to 192.168.20.1 (192.168.20.1), 30 hops max, 60 byte packets
 1  gateway (192.168.10.254)  1.766 ms  1.706 ms  1.706 ms
 2  192.168.100.2 (192.168.100.2)  2.638 ms  2.633 ms  2.640 ms
 3  192.168.20.1 (192.168.20.1)  2.875 ms  2.845 ms  2.793 ms
[admin@fumidai:~]%

STEP2.

no ip route 0.0.0.0 0.0.0.0 172.20.1.254
ip route 0.0.0.0 0.0.0.0 192.168.100.2
ip route 172.20.2.1 255.255.255.255 172.20.1.254
[admin@fumidai:~]%traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  gateway (192.168.10.254)  0.753 ms  0.722 ms  0.704 ms
 2  192.168.100.2 (192.168.100.2)  0.891 ms  0.875 ms  0.817 ms
 3  172.20.2.254 (172.20.2.254)  1.389 ms  1.365 ms  1.338 ms
以下省略

送られてきた解答の中にこれかこれに準ずる内容が含まれていたら得点としています。

講評

今回は1次予選ということで、競技ではあるもののどちらかというとハンズオンセミナーのようなイベントで出されそうな問題を意識して作りました。
その中でSTEP1はそこそこのレベル、STEP2は発展レベルの問題という感覚だったのですが、STEP1まで解けたチームがおよそ6割、STEP2まで完答したチームがおよそ3割程度だったので、思ったよりも解けていた印象でした。
今回はすべてIPv4を用いての問題でしたが、このようなトンネリング技術はIPv6移行技術としてもよく用いられる技術であるためこの機会にぜひ勉強してみてください。

 /

1問目

問題文

IPv6問題 No.1 ステートレスアドレス自動設定(SLAAC)

以下の選択肢のうち、ノード起動時におけるSLAACの順序として正しいものを選択してください。
a. ノードはリンクローカルユニキャストアドレスを生成する
b. ノードはユニークローカルユニキャストアドレスを生成する
c. ノードはグローバルユニキャストアドレスを生成する
d. ノードはマルチキャストでRSパケットを送信する
e. ノードはエニーキャストでRSパケットを送信する
f. ルータはRSパケットを受け取ったらRAパケットを返信する
g. ルータはRSパケットを受け取ったらDHCPv6でアドレスを作りRAパケットで返信する

選択肢

  • b → e → f → c
  • a → e → f → b
  • a → d → f → b
  • a → d → g → c
  • a → d → f → c
  • a → e → g → b

解説

IPv6ではDHCPがなくてもIPアドレスとデフォルトゲートウェイが設定できるようになりました。
この問題はそのステートレスアドレス自動設定(SLAAC)の手順に関するものです。
選択肢がやたらと多いのは勘や順序の傾向から適当に解くのを防ぐためです。
その結果としてですが正解が2つできてしまいました、採点中に気がついたのでどちらでも得点が入っていますが、競技中に悩んだ方は無駄に時間を取らせてしまい申し訳ないです。

さて正解ですが、以下の2つです。

  • a → d → f → c
  • a → d → f → b

文章にすると以下になります。
1. ノードはまず、リンクローカルユニキャストアドレスを生成する
2. リンクローカル全ルータマルチキャストでRS(ルータ要請)パケットを送信する
3. ルータがRSパケットを受け取るとリンクローカルユニキャストでRA(ルータ応答)パケットを返信する
4. ノードはRAからグローバル(or ユニーク)ユニキャストアドレスを生成する

講評

調べれば簡単に分かる問題なので正答率は高かったです。

2問目

問題文

IPv6問題 No.2 EUI-64

以下のMACアドレスからユニキャストアドレスのインターフェースIDを自動生成した場合に適切なものを選択肢から選んでください。

94:de:80:6c:8e:4d

選択肢

  • fe80::94de:80ff:ff6c:8e4d
  • 94de:80ff:fe6c:8e4d
  • ffff:94de:806c:8e4d
  • 96de:80ff:fe6c:8e4d
  • 94de:80ff:ff6c:8e4d

解説

IPv6のSLAACではEUI-64でMACアドレスを変換し使用することによってユニークなアドレスを生成できます。
IPv6のアドレスはプレフィックスとインターフェースIDからなり、これはIPv4のネットワークアドレスとホストアドレスに対応します。
この問題はEUI-64でMACアドレスからインターフェースIDを生成した場合どうなるかを答えるものです。

変換の手順は以下です。
1. MACアドレスを24ビットずつに分割(半分)
2. 分割した間に0xfffeを挿入
3. 7ビット目を反転

正解は 96de:80ff:fe6c:8e4d です。

講評

不正解の解答ではステップ3を忘れているケースや、ステップ2で0xfffeではなく0xffffを挿入しているケースが多く見られました。
ちなみに検索するとEUI-64コンバーターが出てきます。
http://silmor.de/ipaddrcalc.html#ip6

この手の計算問題は自分でやると間違えるのでコンバータに任せましょう。

3問目

問題文

IPv6問題 No.3 IPv6豆知識

以下のIPv6に関する文章の中から最も正しいものを選んでください。

選択肢

  • IPv6ではアドレス解決にARPv6を使う
  • RA(Router Advertisement)パケットではDNSアドレスを通知することができない
  • ICMPv6はDos攻撃に利用されるため常にフィルタしたほうが良い
  • ユニークローカルアドレスはルータを超えられる
  • IPv6にはIPv4射影アドレスがあるので、宛先ノードがIPv6非対応でもIPv6で通信することができる

解説

IPv6について雑多に知識を付けてもらおうと思い出題しました。
選択肢の中で最も正しいのは ユニークローカルアドレスはルータを超えられる です。

それぞれの選択肢を解説していきます。

IPv6ではアドレス解決にARPv6を使う

IPv6ではL2でのアドレス解決にARPではなくICMPv6を使います。

RA(Router Advertisement)パケットではDNSアドレスを通知することができない

策定当初はRAでDNSアドレスを配布することはできませんでしたが現在は可能です。
ただし実装されているとは限りません。
不幸なことに、DNSアドレス配布周りでは幾つかの規格があり、端末とルータによって実装がバラバラです。

ICMPv6はDos攻撃に利用されるため常にフィルタしたほうが良い

上にも書いてありますが、ICMPv6をフィルタするとL2でのアドレス解決ができない、SLAACが使えないなどの問題があります。

ユニークローカルアドレスはルータを超えられる

リンクローカルアドレスはルータ超えできませんが、ユニークローカルアドレスはルータを超えられます。
これが正解です。

IPv6にはIPv4射影アドレスがあるので、宛先ノードがIPv6非対応でもIPv6で通信することができる

IPv4射影アドレスを使うとアプリケーションはIPv4アドレスをIPv6アドレスとして処理できますが、実際の通信ではIPv4を使います。
そのため、宛先ノードがIPv6非対応でもIPv6通信ができるというのは厳密には間違いです。

講評

おおよその正否は調べれば分りますが、「射影アドレス」と「ルータ越え」のどちらにするかで悩んだチームが多いようです。
この場合、問題文に「最も正しい」とあるので少し悩みどころのある前者ではなく、後者が正解となります。

 /

問題文

背景

あなたは今、とあるネットワークに参加しています。
このネットワークはIPv6で構成されていて、あなた以外にも不特定多数のユーザーが参加しています。
このネットワークには管理者によって1台のルーターが設置されていて、ユーザーはネットワークに参加すると自動でIPアドレスが設定されるようになっています。
このルーターは別のIPv6ネットワークにも繋がっていて、そこには1台のサーバーが動いていて、ルーターは2つのセグメント間を繋げています。
本来なら、あなたはルーターを経由して別セグメントにあるサーバーにアクセスできるのですが、なぜかできません。

※ この世は性善説で成り立っているわけではありません

問題

このネットワークは下記の画像の用になっています。
あなたはクライアント1です。
IPv6セグメント1には複数の端末が繋がっていますが、あなたが操作できるのはクライアント1とルーターのみです。
踏台サーバーはマネジメントセグメントでルーターとクライアント1に繋がっていてIPv4でsshできます。
IPv6セグメントに繋がっている端末は自動でIPv6アドレスが設定されます。
クライアント1とルーターは設定変更や再起動など自由にして構いません。

クライアント1からサーバーにpingが通らない原因を調査し、報告してください。
正常に通信できるようにする必要はありません。

情報

ssh用のIPv4アドレスは図にある通り

  • ルーター: 192.168.0.1/24
  • クライアント1: 192.168.0.2/24

ルーターとクライアント1のユーザー名とパスワード(共通)

  • ユーザー名: admin
  • パスワード: ipvvvvvv

サーバーのIP確認方法

  • ルーターにログインし、運営が予め用意したtargetコマンドを実行する
  • 注) コマンド実行時に補完しようとするとエラーがでますが実行はできます

例)
admin@vyos:~$ target
fd00:2::9999:8888:7777:6666

捕捉、注意等

環境破壊やシャットダウンしてしまった場合

  • メールで知らせてください
  • 減点はありませんが、復旧に時間がかかる場合があります

ゴール

この問題のゴールはクライアント1からサーバーに疎通が取れない原因を調査し報告することです。

トラブルの概要

IPv6ネットワークが用意されていて、そこでクライアントからサーバーに通信したいがなぜか疎通が取れない。
その原因を調べるという問題でした。

解説

この問題はざっくり言うとDHCP snoopingのRA版です。
実際には以下の図のように競技者が操作するクライアント1の他にもう一台、クライアント2(仮称)があります。
実はこのクライアント2がただのクライアントではなく悪意のあるルーターになっていて、ルーターと同じようにRouter Advertisement(以下RA)を流しています。
ただし、悪意のあるルーターが流すRAは正規のルーターのRAより優先度が高くなっています。
そのため、クライアント1がマルチキャストでRouter Solicitation(以下RS)を送り、両方のルーターからRAが帰って気た場合、優先度の高い悪意のあるルーターのRAが使われてしまい、IPv6のデフォルトゲートウェイが悪意のあるルーターになります。
クライアント1がサーバーと通信するために、正規のルーターにパケットを送ったつもりが、悪意のあるルーターにパケットが行ってしまうためサーバーとの疎通が取れないというわけです。

解答例

原因の調査手順としては以下です。

  1. pingを送る -> 通らない
  2. tracerouteのネクストホップとルーターのアドレスが違うことに気づく

  3. IPv6セグメント1で ip neigh を確認しルーターとクライアント1以外にも端末(クライアント2)があることに気づく
  4. tracerouteのネクストホップがクライアント2なことに気づく
  5. クライアント1のルーティングを確認する -> デフォルトゲートウェイがRAになっている

上記の1~6をまとめて「ルーターでは無いところにパケットを飛ばしてる」ことが明記されていれば50%です。
その後パケットを見るなどしてLAN内にクライアント2が存在することと、RAを流していることを明記すると50%です。

採点基準

大まかな採点基準は以下です。
1. tracerouteでパケットがルーターでは無いところに送られていることを明記する 50%
2. パケットキャプチャし、LAN内に悪意のあるルーターがありRAが流れてきていることを明記する 50%

惜しい所まで書かかれている解答には適宜、部分点を付けました。
問題文に「原因を調査し、報告してください」と書いてあるので原因について明記されていない場合は減点しました。

講評

この問題はIPv6をちょっと触って欲しい、RAによるステートレスアドレス自動設定(SLAAC)を知って欲しいという意図で出しました。
その上でIPv6のRA関連のトラブルってなんだろうなー と考えたとき思いついたのが偽RAです。
問題の性質上、後半でどうしてもエスパー感が出てしまうのでLAN内に悪意のある端末があるヒントとして問題文に「この世は性善説で成り立っているわけではありません」と記述しました。

最高得点は70%(245点)で、残念ながら満点はいませんでした。
50%のボーダーを超えたのは3チームです。
大半の解答が0点となりましたが、その理由の多くは「問題文を読んでない」、「出力の勘違い」、「明記してない」です。
普段使うツールでもIPv6の表記に慣れていないため、コマンドの出力結果を読み間違えたような解答がちらほらと見受けられました。

 /

1問目

問題文

SNMPが使うポート番号は次のうちどれでしょうか。
– 160/TCP
– 160/UDP
– 161/TCP
– 161/UDP

解説

161/UDPはSNMPエージェント(監視されるもの)が使用し、
162/UDPをSNMP TRAPで使用します。
TCP/IP – SNMP

解答例

  • 161/UDP

講評

調べれば誰でも解ける問題ということもあり全チームが正解してました。

2問目

問題文

対象機器のホスト名(sysName)を取得するOIDは次のうちどれでしょうか。
– .1.3.6.1.2.1.1.5
– .1.3.6.1.2.1.1.4
– .1.3.6.1.2.1.2.1
– .1.3.6.1.2.1.2.5
– .1.3.6.1.2.2.2.5
– .1.3.6.1.2.1.1.3

解説

OIDとはオブジェクトIDのことです。SNMPで監視する際はOIDを指定して監視したいデータを選択し取得します。

解答例

  • .1.3.6.1.2.1.1.5

講評

こちらの問題も調べれば誰でも解ける問題ということもあり、全チームが正解していました。

問題文

[トラブル1] ZabbixからSNMPで監視ができない。。。

自宅の検証環境でZabbixからVyosをSNMPで監視したいのだがSNMPのホストをZabbixに登録しても監視ができない。原因を突き止めトラブル対応をし、ZabbixからVyosを監視できるようにしてください。
踏み台サーバにログインをして以下のアクセス情報を使ってトラブルシュートすることができる。

情報

接続情報

  • Zabbix
    IPアドレス: 192.168.0.5
    SSH-ID: admin
    SSH-パスワード: fG9bycDJ
    ZabbixコントロールパネルURL: https://192.168.0.5:8080 (VNCサーバからFirefoxを使ってアクセスすることができます)
    ZabbixログインID: admin
    Zabbixパスワード: zabbix

  • Vyos
    IPアドレス:192.168.0.10
    SSH-ID: admin
    SSH-パスワード: fG9bycDJ
    SNMPのcommunity: ictsc2018-pre1

ゴール

Zabbixのコントロールのパネルホスト一覧からVyosのSNMPの監視のところが赤色から緑色なればゴールです

[トラブル2] Grafanaが起動できない。。。

自宅の検証環境をZabbixではグラフの可視化がいけてないのでGrafanaというOSSをdocker-composeで構築・可視化をしていたのだがGrafanaのアップデートが来ていたのでアップデートしたら起動できなくなってしまった。原因をつきとめてGrafanaのコントロールパネルを見れるようにしてください。

情報

- docker-compose.ymlはadminユーザのホームディレクトリにあるdocker-composeフォルダにあります
- バージョンアップ前はdocker-compose.yml.old、バージョンアップ後はdocker-compose.ymlです
- docker-compose up -dするとエラーが吐かれて起動できません。
- バージョンアップ前のdocker-compose.ymlを試しに使うと起動できます
- ~/docker-compose/.volume/ にGrafanaコンテナで使うデータが入っています。このデータは必ずアップデート後も引き継いでください

接続情報

  • Grafanaサーバ
    IPアドレス:192.168.0.6
    SSH-ID: admin
    SSH-PW: fG9bycDJ
    GrafanaのコントロールパネルURL: 192.168.0.6 (VNCサーバからFirefoxを使ってアクセスすることができます)
    GrafanaID: admin
    GrafanaPW: grafana

ゴール

Grafanaが無事起動ができ踏み台のVNCサーバのWebブラウザからGrafanaのコントロールパネルのログイン画面が見れればゴールです。

禁止事項

- ~/docker-compose/.volumeを削除する・アップデート後のコンテナで使わないというのは禁止です。
  必ずGrafanaコンテナにマウントしてデータを引き継いでください。

トラブルの概要

[トラブル1]

これはVyos側の snmp communitysnmp portが間違っている単純な設定ミスのトラブルでした。

[トラブル2]

このトラブルはこのGrafanaというOSSの特有のトラブルとなっております。トラブル自体はとても簡単でGrafanaの公式ドキュメントの Installing using Docker を読まれた方はすぐに解けたのではないでしょうか。
公式ドキュメント

解説

[トラブル1]

よくみるとVyos側のcommunity側の文字が ictc2018-pre1 でとなっており問題文で指定されたcommunity名と違います。ちなみにZabbix側の設定は ictsc2018-pre1 となっており正しいものとなっています。
またVyosのSNMPのportの設定が 162 と指定されおり、これも修正する必要があります。

[トラブル2]

このトラブルはGrafanaのバージョン5.1以降からはUIDが変更されております。ですので5.1以前に作成されたファイルはそれ以降のバージョンでは正しいアクセス権を持たないので使えません。
これを解決するには新しいコンテナ作成時にUIDを変えてしまうという手段があります。
user-id-changes

解答例

[トラブル1]

admin@vyos# delete  service snmp community ictc2018-pre1
admin@vyos# set service snmp community ictsc2018-pre1 authorization ro
admin@vyos# delete service snmp listen-address
admin@vyos# set service snmp listen-address 192.168.0.10 port 161
admin@vyos# commit
admin@vyos# save

[トラブル2]

docker-compose.ymlのGrafanaのサービスのところに以下を追記する

    user: &quot;104&quot;

講評

全49チーム中
トラブル1だけ解けたチーム: 5チーム
トラブル2だけ解けたチーム: 0チーム
トラブル1,2両方解けたチーム: 9チーム

トラブル1はVyosを使ったことある人なら簡単に解けたかと思います。
SNMP?Vyos?Zabbix?なにそれ思った方は是非一度自分で調べて自分で構築することをおすすめします。
どんどん自分だけの検証環境を作って試してみるといいかもしれません。
トラブル自体はとてもとても簡単なので解けなかったチームはしっかり復習しましょう。

トラブル2を解けたチームはログを見る・ドキュメントを調べる・ぐぐるという基本的なことがしっかりできていた印象が解答から感じられました。
解けたチームはしっかりとエビデンスやドキュメントのURLを貼って報告してくれてました。
またあるチームはGithubのissueまで調べたというのもありました。

最近のコメント