ICTSC8の問題解説 [ストーム制御とVSRX]
ICTSC8の問題解説
ICTSC8から1週間以上が経ちました。皆さんお元気ですか？
今回のブログでは自分が作成した問題の解説と反省をしていきたいと思います。2問作成したので1問ずつ解説します。
伝統の国 第一のトラブル
旅の途中、酒場に訪れた。
ドワーフ「お客さん、見ない顔だね。どこから来たんだい？」
エイト「私は始まりの国のはずれよ。この人たちは私が異世界から呼んできたの」
ドワーフ「ほーう。ここに壊れたスイッチがあって修理する当てを探しているんだが……。まぁおまえらじゃあ解決できないだろうな、ほら帰ってくれ」
そう言い残すとドワーフは、店の奥に消えていった。
エイト「キー！ 悔しい。あんたたち絶対直してみせなさい！！ 解決して見返してやりましょう」
## 注意事項
- 2960B を再起動してはいけない。
## 達成すべき事項
- 7 番ポートをリンクアップをさせ、原因を特定する
- パスワードを `broken_port?` に変更する。という問題です。まずどういう物理トポロジー図であったかというと以下のようになっています。
2960BのFE0/7でトラブルが発生しました。
トラブルの内容を簡単に説明すると脆弱なパスワード(cisco)を設定していたが、突破されて7番ポートに変えられてしまったという感じです。では解説します。
コアの技術
ストーム制御
ストーム制御は、物理NICの不良、ネットワーク構成のミス、DoS攻撃などにより発生するトラフィックストームの影響を制限して制御できる技術です。ストーム制御では、ポートからスイッチングバスを通過するトラフィックをモニターして、パケットがユニキャスト、マルチキャスト、ブロードキャストなのか判別します。次に、スイッチは1秒間に受信した特定のタイプのパケット数をカウントして、事前に定義されたストーム制御レベルのしきい値と、その測定結果を比較します。以下のいずれかを測定方法に使用。
この技術を用いてある程度のパケットが通ればshutdownになるように設定しました。
では具体的なconfigを見てみましょう。
| ena | |
| terminal history size 0 | |
| conf t | |
| hostname 2960-B | |
| !KAT | |
| enable sec cisco | |
| vtp mode tran | |
| !KAT | |
| vlan 143 | |
| int fa0/7 | |
| switch access vlan 143 | |
| storm-control unicast level 0.0 | |
| storm-control action shutdown | |
| exit | |
| !internet | |
| vlan 199 | |
| int range fa0/13 - 24 | |
| switch access vlan 199 | |
| exit | |
| int fa0/15 | |
| switchport access vlan 199 | |
| !892J | |
| vlan 199 | |
| int range fa0/8 | |
| switch access vlan 199 | |
| exit | |
| int fa0/8 | |
| switch access vlan 199 | |
| exit | |
| exit | |
| write memo | |
| conf t | |
| int fa0/7 | |
| no storm-control unicast level 0.0 | |
| no storm-control action shutdown | |
| exit | |
| exit |
赤文字になっているところが今回のポイントになっているところです。ストーム制御が原因だとすぐにわからないようにnoでコマンドを消しています。またactionをshutdownに変えているのでポートが上がらないようになっています。ポイントとしてはそれぐらいでしょうか？何か質問があれば対応します。
そしてこの問題にはもう一つポイントがあります。それがパスワードを変更することです。`broken_port?`に変更するという指示です。通常ciscoでは `?` を
うつと現在うてるコマンドの候補が出てきます。これを無効化しないとパスワードが設定出来ません。無効化する方法は Ctrl + V です。
解説は以上です。次に講評です。
講評
結果としましては、15チーム中14チームが基準点突破でした。基本的にはパスワードを変更したということ(？を無効化する記述が書かれていること)とポート7が上がっていれば基準点としていました。皆さんがちゃんと解いてくれたみたいでよかったです。
荒廃の国 第三のトラブル
トラフィックの問題を解決し、無事に服屋にたどり着くことができた。
エイト「さっそく服を買うわよ……ってお店が開いてないじゃない！」
店の前で大声を出したせいか、中からやつれた顔のエルフが出てきた。
エルフ「すいません。最近盗賊に魔法陣を乗っ取られて、お店のシステムが動かなくなったんです。今は盗賊の対策の真っ最中で、これが終わるまでお店は開けられません。魔法陣を安全に設定したいんですけど……」
エイト「かわいそうに！ 私たちが何とかしてあげましょう。安全にsshができればいいのかしらね？」
## 注意事項
- ブラウザはfirefoxを推奨する。
- 指定のURLにアクセスしてクエストを解かなければいけない。
## その他
サーバにデフォルトゲートウェイを設定する際には192.168.16.254/24を使用すること
## 達成するべき事項
- 管理者ポートとそれ以外のポートの2つへsshができる。
- どのようにしてsshを可能にしたのか詳細に記載する。juniperの問題です。今回vsrxとお借りすることができたため出題することができるようになりました。問題解説を見る前に以下の資料に目を通すことをお勧めします。
コアの技術
Flow-based forwardingモード
packet-based forwardingモード
以上のモード切り替えをするという問題でした。具体的なコマンドは以下の通りです。Flow-based forwardingモードでは、vsrxは元々ファイアウォールのためpingの疎通性の確保が難しいモードです。なのでvsrxをルーターとして扱うためにモードをpacket-based forwardingモードに変えるという問題です。正解するためにはfxp0という管理者ポートとそれ以外のどこかのポートからsshできれば完了です。
delete security
set security forwarding-options family mpls mode packet-based
set security forwarding-options family inet6 mode packet-based
commit
exit
request system reboot
確認するコマンド
show security flow status
1つだけ言わないといけないことがあります。この解答方法はベストアンサーではありません。(大人の方からもできるけどベストアンサーではないよねって言われました。)
これに関しては完全に自分の勉強不足でした。申し訳ないです。
問題解説
具体的にしなければならないことは主に2つです。
- インターフェースにアドレスの設定とsshを許可するコマンドをうつ。
- モードを変えてリブートする。
以上です。
以下はvsrxを構築していく具体的なコマンドです。問題を解くにあたって必要はないがよく使いそうなコマンドも同時に載せています。
今回はopenstack上にvsrxが乗っている状況になっています。openstackでvsrxをちゃんと使用するためにはいくつかポイントがあります。
モードの移行
cli (junosのコマンド打てるモードへ)
conf (cisco のconf tと同類)
- pingの疎通性の確保
コマンド
conf
set interfaces fxp0 unit 0 family inet address 10.0.0.13/24
set system root-authentication plain-text-password
set routing-options static route 0.0.0.0/0 next-hop 10.0.0.254
commit
exit
ping 8.8.8.8
（注意 commitは必ずうつ。コマンドの有効化）
address 10.0.0.13のところは該当するアドレスで(openstackのやつ)
アドレスはopenstackで使用していたものなので気にしないでください。
上記のコマンドでは管理者ポートにアドレスを付与し、rootでログインするときにパスワードを付与するもので付与しなければcommitするときに注意を受けるのでご注意ください。またstaticでサーバーまでルーティングしています。rootのパスワード設定はこちらでしていたので問題を解くにあたって行う必要はなかったです。
次にsshの許可の設定と新しいユーザーの作成
set system login user katu class super-user
set system login user katu authentication plain-text-password
set system services ssh sshの有効化のコマンド
set system services ssh root-login allow
これでkatuというユーザーを作り、またsshの許可をしています。
次にvsrxをルーターとして使用するためのコマンド
delete security
set security forwarding-options family mpls mode packet-based
set security forwarding-options family inet6 mode packet-based
commit
exit
request system reboot
確認するコマンド
show security flow status
ホスト名の設定
set system host-name vSRX-1
管理者ポート以外のポートからsshする方法
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.13/24
だいたいこんな感じです。問題講評をしたいところでしたが、解答数が0だったので代わりに構築中に起きた様々なトラブルについて書きます。
構築中のトラブル
まずopenstackの上にvsrxをのせることになったのですがopenstackもvsrxも触ったことがなかったので、1からの構築になりました。
インスタンス作成をすると上の画像のような感じになりました。
カーネルパニックが起きている状態です。理由としましてはメモリを4GB未満でインスタンス作成をしていたからです。必ず4GB以上でやりましょう。
次にsshで疎通できるようにしようと思いました。しかしvsrxでどう設定してもできませんでした。状態としてはpingは通るがsshできないという感じです。これは別の運営委員の方が原因を特定してくれました。
SSHの接続は確立してたけど鍵交換のところで止まっていたので，おそらく原因はMTU
vSRXのFloating IPに 1500byteでpingうつと落ちる．1472byteが限界
VXLANのオーバーヘッド分だと思うんだけど，MTUを調整しないといけない
という返事をいただきました。というわけでMTUを調整しようと思い管理者ポートのMTUを1450にしようとしましたが管理者ポートはMTUを変えることはできないので他のポートからsshしようとして2つのFlow-based forwardingモードpacket-based forwardingモードを知りました。そしてge-0/0/0からsshできるようにして無事に出来ました。よって検証環境では管理者ポートではsshできずに他のポートからしかsshできないという謎の環境が出来上がりました。
次にopenstackがvsrxの新しく作成したポートを認識しないという問題が発生しました。結果から言えばおそらくですが原因はopenstackのポートフィルターが働いていたのが原因です。これらを考慮して次のような手順で構築しました。
- openstackのインスタンスを建てる
- インターフェースは2つ以上必ず追加する。
- 2つ目は外部に疎通性があるようにする(sshするため)
- Floating IPの付与
- インスタンス起動
- ge-0/0/0にアドレスを追加
- 外部への疎通性の確認
- sshの許可のコマンド
- ge-0/0/0 のmtuを1450にする
- sshできる
注意点 この手順通りでなければならない。また1つ目のインターフェースは管理インターフェースfxp0に付与されるので必ず2つめのインターフェースに疎通性の確保できるアドレスを付与すること。そしてopenstack側にNICを追加を認識させたいときはインスタンスを停止させてから起動させる。
vsrxにはアドレスを付与する順序があるらしくこの手順でなければできませんでした。
このあたりで時間がなくなり、検証は終了しました。この構築過程を問題にしようと思い今回のような問題になりました。
感想
今回出題出来なかったですがciscoとvsrxでIPsecを貼る問題を出そうとあがいていたのですが時間がなく出題できませんでした。マルチベンダー問題を期待していた方申し訳ないです。
全体の感想です。今回ネットワーク系の問題の数が少ないと感じた方がいたと思います。その点に関しては申し訳ないです。運営委員にネットワーク系の問題を作成する人が減っており、問題数が減ってしまいました。
問題の質問やもっといい解答を知っているという方は自分のツイッターまでご連絡いただけるとありがたいです。
また10/7にネットワーク系の問題を中心に問題解説をするLT大会を開催します。よければご参加ください。
以上です。ありがとうございました。
運営委員体験日記 ～小説家になりました
ICTSC8 運営委員としての感想
皆さんお元気ですか？
ICTSC8の運営委員をやらせていただいた嶋です。
もっとはやく書きたいという気持ちがありましたが体調不良のため延期に延期を重ねておりました。
ではさっそく今回の振り返りをしていきたいと思います。注意事項として自分の作成した問題については別に書くのでここでは書きません。あくまでも運営委員としての振り返りを書くだけです。
今回の自分の役割
今回は初めての役職をもってやりました。副リーダーというICTSCで1番何しているのかよくわかってない役職をしました。結果どんな仕事をしたかというとすべての仕事に少しずつ関わって少しずつ仕事をしました。ICTSCの運営委員というのはできる人ができることをするだけの組織なので誰かが全体の状況を把握しなければなりません。そこは把握していけたらな～という気持ちがありました。その結果今回は小説家になりました。よくわからないですね。そんな感じで今回自分が担当した仕事は以下の通りです。
- 手元ネットワークの設計やconfigを流し込むこと
- 問題文のシナリオの土台の作成
- 司会
- 自分の問題作成 (今回は2問)
今大会の感想
私はICTSC7から運営委員をやらせていただいていますが、前回大会は仕事量も少なく楽しい大会でした。今回は準備期間が短いこともあり前回と比べると睡眠時間が半分以下になり仕事量も倍でした。洗濯する時間を見つけ出すのが1番苦労した点ですね。
さて今大会の問題の難易度はいかがだったでしょうか？ネットワーク系の問題の難易度は前回より上げたつもりです。前回大会でネットワーク系の問題で点数を稼いでいるチームが多かったため難易度をあげました。またjunosの問題も出ました。ICTSCにもマルチベンダーの時代が到来しつつありますね。よいことだと思います。私自身参加者側になって今回のネットワーク系の問題を全て解けたかと言われれば少し怪しいです。しかし良問をそろえたつもりなので皆さんの勉強になれば幸いです。
小説(シナリオの話)
今回のICTSCの世界観どうだったでしょうか？シナリオの詳細は後日(9月中)に公開出来ると思います。OPとEDの動画セットで公開出来ると思います。シナリオの完成度はそこまで高いものではないですが是非読んでみてください。
今後のICTSC
今後ICTSCがこうなっていけばいいな～という個人的見解です。個人的に感じていることが本大会は問題を解くだけとかして解説がブログだけなのでいつか問題作成者が問題解説をする勉強会を開けばいいのにな～と感じています。そうすれば参加者の皆さんも、もっと具体的にこう勉強しようとか運営委員と参加者の間で繋がりも出来ますしいいんじゃないかな～と思います。宣伝にはなりますがとりあえず大阪で問題解説を含めたLT大会をやります。是非ご参加ください。
次回大会について
次回は参加者側で参加しようかな？と考えています(何かあれば運営委員やるかもしれないけど)。優勝したら副賞もついてくるらしいので頑張りたいですね。違う大学の人と組みたいのですが誰に言えば許可でますかね？偉い人許可ください。お願いします。
第二回大阪工業大学LT大会の報告
本日7/8に大阪工業大学梅田キャンパスにて第二回大阪工業大学LT大会を開催しました。
学内生を中心に大学の先生や外部の社会人の方にもライトニングトークしていただきました。その様子をブログにしていきます。
まずはLT中の写真です。
かなり写真が多いですがこれでもかなり厳選して選びました。皆さん面白い話ばかりで常に笑いが発生しました。個人的にも前回大会よりよかったと感じています。続いては懇親会の写真です。
懇親会はハンバーガー50個と大量のお菓子でやりました。皆さん懇親会中は本当にいい笑顔でやっていたと思います。ここから新しい何かが生まれるといいですね
是非次回もご参加ください。
次回は学内で40人目指して広報頑張ります。
よろしくお願いします。
以下大会のまとめです。
OIT LTでのスピーカーのルールについて
次回大会7/8まであと2週間を切りました。
スピーカーの皆さんに必ず守って欲しいルールを作成しました。
スピーカーの皆さんは必ず読んでください。
以下の通りです。
- いかなる形であれ、いやがらせは禁止です。
- 聞き手が嫌な思いをするような発言はしない。
- 過度な宣伝
以上です。
1.の嫌がらせとは以下のようなことに該当します。
・攻撃的な発言をすること
・脅迫
・ストーキング
・つきまとい
・不適切な接触
・性的な画像の掲示などを含む望まれない性的なアトラクション
これらのルールはOIT LTを継続的な大会にするためのルールです。
よろしくお願いします。
参考ページ
OIT LT (第一回大阪工業大学LT大会)について
2017年5月27日に第一回大阪工業大学LT大会
を主催し開催しました。
この大会について以下の3つのことをまとめていきます。
- 大会中の様子
- 大会の感想
- 大会のコンセプトと今後
まず大会当日までに申請頂いているプログラム一覧です。
（当日に参加申し込みまたはタイトルが当日まで不明だったものは除く）
「Openconfigの可能性」
「うまい棒はいつ食べたらおいしいのか」
「なんちゃってトラブルシューターになるために」
「アメリカでテラスハウスした話」
「楽しいエンジニアライフの過ごし方」
「哲学のイロハのイ」
「Amazonプライム」
「不明」
「おパンツ」
「気になるOS」
「ネットワーク学科で大流行！あのアニメのダイレクトマーケティング」
「FAIV計画」
「理系はみな社蓄になる」
「季節の果実」
「難読化シェル芸」
「情報通信分野の法令をめぐる最近の動向」
- 大会中の様子
当日は飛び入り参加者も含めて20名近くが登壇してくれました。その様子を写真で掲載します。
このような感じです。個人的に予想していた規模より大きくなり、雰囲気も非常に盛り上がる内容となりました。
またスライドを共有してもよいという方がいたのでここに載させていただきます。
2. 大会の感想
感想としては反省点はいくつかありますが概ね成功したと考えています。この大会のコンセプトは「内部の人と外部の人を繋げるイベント」というものなのでその点は成功したかなという感じです。また皆さん楽しそうにしてくれてたのでよかったです。（楽しいが1番）
3. 大会のコンセプトと今後
大会のコンセプトとしましては「内部の人と外部の人を繋げるイベント」なので今後も宣伝活動を続けていきたいです。また今後このイベントを継続的なものにするためにスピーカー側にいくつかのルールをつけようかなと考えています。これは大会にルールとモラルがなければ大会で誰かを不快にさせてしまう可能性があるからです。よろしくお願いします。
次回は7/8で梅田キャンパスの予定です。
是非よろしくお願いします。
KATの解説 [ICTSC7]
そう言えば1カ月前にICTSC7が開催されていました。
その中で私はG社の1問目のKATを出題させていただきました。
今さらではありますが問題の解説をさせていただきます。
問題を解説する前にまずは皆さん今回の手元ネットワークはどうだったでしょうか？
今回の手元ネットワークの設計は別の運営委員ですが、それ以外の構築・運用・保守は私がメインで担当させていただきました。皆さんができるだけ理解しやすくなるように
様々な工夫はしたのですが感想をくれると次回以降にも考慮していきます。
手元ネットワーク関係の問題を解決するためには必ずどういう構成でネットワークを構築されているのかを知ることはとても重要です。例え図や表が配布されていても必ず自分で確認するということは問題を解決するためには重要です。
ぜひ次回やっていなかったチームはやってみてはいかかでしょうか？
では、本格的に自分の問題の解説をしていきます。
問題のコアの技術
・Times-Based-ACLs Time-Based ACLs（時間ベースACL）とは 時間ベースACLは、曜日や時刻に基づいて拡張ACLを動的に適用することができます。時間ベースACLで 使用される時間はCisco
簡単なトポロジ
1941b(KAT) → 1941a(KUB) → 疎通先
採点基準
・正しい時間に設定(TimeZoneも日本に設定しないと加点なし)
・Times-Based-ACLsに気付き正しく直す
・正しいACLに設定をして疎通性がとれる
講評
KATは15チーム中13チームが基準点を満たしていました。これに関しては大方予想通りです。基本は報告書を提出してもらう方法で解答していただきました。その中でも何チームかは芸術点をあげたくなるほど美しい報告書を提出してくれたのでとても嬉しかったです。さて実際の中身は海外から輸入したルーターという斬新な問題でした。トリニダード・トバゴという国(陸上が強いらしい)から輸入したという設定です。何故この国かというとそんなに深い理由はありませんが日本のタイムゾーンのJSTに似ているASTだったというだけです。この問題の採点をしていて思ったことは、間違えている解答でよくあったのはACLのINとOUTを変えただけという解答が1日目多かったです。INとOUTだけを変えても問題の本質には何も近づいていないので、基準点はあげれなかったです。
問題の解説としては、これで以上です。
質問があれば↓
ここに何らかアクションくれたら反応します。
次回も運営委員として参加します。また会場でお会い出来ることをお待ちしております。
