/

問題文

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: "104"

講評

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

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

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