ICTSC, イベント, コラム, ネットワーク

こんにちは、saiです。
「NTT西日本杯」第6回 ICTトラブルシューティングコンテスト(以下、トラコン)にて運営委員を務めさせて頂きました。

第6回トラコンでは15問の問題が学生の手によって出題されました！

今回は、私が担当した問題の内一つを紹介していきます。

タイトル：調子が悪いんでしょうか？

問題文

ある日、AWS内で弊社のWebサーバを稼動させることになりました。
ただしネットワークに割ける予算が少なかったために古いネットワーク機材を使用しています。
先日、本格稼動をする前に複数人で確認したところ、どうにも「見れるページ」と「見れないページ」が存在するようです。
また、状況によっては「見れないページ」も「見れる」場合があるそうです。
早急に原因を解明し、誤った設定内容を修正してください。修正後、報告もお願いします。
尚、変更するのはサーバのみでお願い致します。

見れないページ : URL

ServerIPaddress : ****
認証情報 【ID】: ****
【Password】: ****

FirewallIPaddress : ****
認証情報 【ID】: ****
【Password】：****


** 補足
問題を起こしている箇所を修正し、原因と修正内容を報告できれば対策を行えたものとします。*1

　*1  どういう状態になるとゴールなのかを記載していなかった為。又、全ての環境でMTUキャッシュクリアの方法をMTUというワードを出さずに周知できなかった為、補足させていただきました。

 

問題解説

この問題は、問題文と各種設定から原因を見つけていく問題でした。
AWS関連の情報やMTUについて詳しく知っていればピンとくるかもしれない問題ですが、そうでない場合難しい問題となったかもしれません。
また、解く際にWiresharkを用いたりすれば、MSS値周りの情報からヒントを見つける事が可能でした。

 

キーポイント

  • AWSのデフォルトMTU値が9001である
  • FW(vyosA)でicmpが全て拒否されている為、PathMTUDiscoveryまで拒否されている(PathMTUDiscoveryBlackhole問題)
  • 経路上のルータ(vyosB)のMTU値が800になっている
  • 結果、サイズが800byte*2を越えるWebページだけが見れなくなってしまう

　　*2 実際には約600byte〜700byteくらい

 

解説

この問題では、一部Webページが見れない状況にありました。
その原因は、PathMTUDiscoveryが拒否されている事(PathMTUDiscoveryBlackhole)とMTUによってパケットがドロップしてしまう事でした。

まず前者についてですが、PathMTUDiscoveryはICMP type3 code4を用いMTUの低いルータ側から送信されます。
しかし、その先にあるファイアウォールがICMP全てをドロップしてしまう為、PathMTUDiscoveryが届かずデータの再送信が行われません。
その為、PCとAWS間のMSSが設定されたままパケットが送信され、途中経路のルータでパケットがドロップしてしまう状況が生まれます。

また、sshをすると通信の始めにクライアント側が大きいパケットを流すため、PathMTUDiscoveryがクライアント側に流れます。
そうすると、一時的にクライアント側のMTU値が800になるため、Webページを見れる状態になります。
しかし、これは恒久的な対策ではないため、これだけを解決策として報告した場合は間違いとなります。

今回、ファイアーウォールではなくサーバの設定を変更する問題となっているので、
サーバのMTU値を恒久的に800にあわせる設定を入れた事と、PathMTUDiscoveryBlackHoleについて触れていれば正解となります。
ただし、今回の状況から800というMTU値を推察するのは難しいだろうという事から、サーバのMTU値の設定はどの値にしていても間違いはないものとし、修正箇所と原因に気づければ正解としました。

 

解法

上記で大まかな解説は行っていますが、詳しい解き方については以下をご参照ください。

問題文からヒントを探す

この問題では、「一部見れないページがある」という現象が発生していました。
しかし、そのままではMTUが原因だとなかなか見つけられないかと思います。
なので、「AWS」や「古いネットワーク機材を使っている」というワードを文面に盛り込む事で、環境の違いを強調していました。
この文面から、環境によって引き起こされているトラブルではないか？と考えると解きやすかったかもしれません。

 

手元にある情報から探す

では、本当にページが見れないのか実行してみましょう。
(ブラウザでも確認はできますが、今回はcurlで実行してみました)

# curl -v http://hogehoge/
* About to connect() to hogehoge port 80 (#0)
*      Trying hogehoge ... connected
* Connected to hogehoge ( hogehoge ) port 80 (#0)
> GET / HTTP/1.1
> User-Agent : curl/~~~
> Host :  ipaddress
> Accept :  */*
>

上の結果から、コネクションは張れるけれどページが見れないという状態を確認できます。
また、この時のパケットをwireshark等で確認すると、3WAYHandshake時にMSSで9001という値が交換されています。
（これはWebServerへsshしifconfigする事でもわかります。）
そして、ssh時に帰ってきているパケットを見ると

「ネクストホップのmtuは800だよ」

というicmpパケット(PathMTUDiscovery)が来ているため経路上のMTU値も判断できるのです。
ここまで来ると、なんだかMTU怪しいなと感じませんか？

 

原因を特定する

さて、経路上のMTU値が低い事がわかりましたが、果たしてそれが原因なのでしょうか？
それを特定するためにはFWのコンフィグを見る必要があります。
FWには以下のような設定が入っていました。

・firewallをeth0にセット
・デフォルトアクションはドロップ
・許可するポート番号は80番と22番

つまり、HTTP(80/tcp)とssh(22/tcp)以外は通過できない状態にあったのです。
では整理も兼ねて、現状分かっている情報でトポロジ図を作ってみましょう。

このようになりますね。
それでは、これによってどのような事が起きるのでしょうか？
名前から先にお伝えすると、PathMTUDiscoveryBlackholeという現象が起きています。

PathMTUDiscoveryBlackholeとは・・・
経路上に異なるMTU値が存在していても、 Path MTU Discovery によって通信することができるようになりますが、適正なMTU値を伝達するためのICMP（type3 code4）パケットを送信元に送信しない設定や、途中の経路でICMPがフィルタリングされている場合には、以下のような問題が発生します。以下のような状態の事をPath MTU Discovery Black Holeといいます。

詳しくは以下のリンクへ
引用元 : http://www.infraexpert.com/info/5.2adsl.htm – ネットワークエンジニアとして

 

では以上の事を踏まえ、Webページを参照しようとした場合の流れを考えていきましょう。

Webページを参照する時の流れ

1.ユーザがWebページをサーバにリクエスト
2.3WAYHandshake時に交換したMSSに合わせてサーバがWebページを送信
3.通信経路上にあるネットワーク機器のMTU値が低いため、Webページを受け取れない
4.通信経路上のネットワーク機器(MTU800)がPathMTUDiscoveryをサーバに向かって送信する
5.FWによってPathMTUDiscoveryが拒否される
6.PathMTUDiscoveryBlackholeが発生し、Webページが読み込まれない

通信の流れを文章で書くと、このような形になっていたわけですね。
つまりここを解決できればなんとかなりそうですね！

対処する

そうなると、対処方法としては以下の二つが挙げられます。

・FWでicmpを通すように設定変更を行う (PathMTUDiscoveryのみ許可する場合はtype3code4のみ指定)
・サーバ側のMTUを経路上の最小MTU値に合わせる

このどっちかを行えば、今回の現象を回避できそうです。
ただし、問題文には以下のような記述があります。

尚、変更するのはサーバのみでお願い致します。

ということは、今回はサーバ側のMTUを変更すればよさそうですね。
それではサーバのMTU値ですが

今回の環境だと、このファイルに追加記述する事で変更できます。
追加する内容は以下になります。

これで保存した後に、インタフェースをアップし治す事でMTU値が反映されます。

以上で、対応完了となります。

尚、以上のMTU設定に加え、PathMTUDiscoveryBlackholeについて触れていると完答となっていました。

 

 

まとめ

「PathMTUDiscovery問題」如何だったでしょうか？
序盤の方では「よく見る事」と「気づき」が重要になっていたので、難しい問題になったかもしれません。
そもそもこの問題自体、問題作成や検証にものすごく時間がかかった問題なので、私自体苦労して作っていました。
「MTUは暗黒大陸」なんて言われる事もあるようなので、この問題を通じてMTUの重要さとめんどくささが伝わればと思います！

ICTSC, イベント, 雑談

8月末に大阪で行なわれた、第6回ICT トラブルシューティングコンテストに今回もお邪魔してきました。

ICTSC – ICTトラブルシューティングコンテスト
http://icttoracon.net/

2日間の戦いの後は、運営側の採点が行なわれるのですが、その採点時間の間、参加者の学生達にイイ話をして場を繋がなければいけません。
学生も大変ですが、大人も意外と大変です。
前回のICTSC5のときは、大人っぽくお金の話をしたのですが、2回続けてお金の話はヤらしいよなあ、と思って数学の話をしてみましたよ。

発表前に、数学好きな人ー？、と聴衆の学生さんに聞いたところ、挙手は皆無。
お金の話のほうが聞きたかった人ー？、と聞いたら、挙手がちらほら。
ありゃあ、はずしちゃったかあ、と思ったけど、発表後に、数学を勉強してみたいと思った人ー？、にちらほらと手が挙がったので、まあ喋って良かったかのなあ。
でも最近の若者は気を使ってくれるんだよねえ。ありがとう。
前回のICTSC5のときに喋った資料もついでに吊っておきます。出すのを忘れてました。

ICTSC, イベント

お久しぶりです。 2年間の学生延長オプションを申請したツチノコ、@whywaitaです。

1年ぶりにツチノコブログにお邪魔させて頂きますが、今回もICTトラブルシューティングコンテスト(以下、トラコン)のお話をさせて頂きたいと思います。 トラコンそのものにつきましては、過去に何名かが記事を投稿しておりますので、そちらも確認頂ければと思います。

第4回、第5回と運営側として参加してきた私ですが、今回は”運営OB枠”、チーム「traITors」として、参加者側で大会に加わりました。 今回は先日行われた”NTT西日本杯 第6回 ICTトラブルシューティングコンテスト”の 参加 レポートとなります。

到着まで

前日(8/26)の朝、私とメンバーの1人は東京を発ちました。学生にはお金はありませんが体力があります。 ここまで言えば分かる方には分かるかもしれません。青春18きっぷを使った12時間の旅が始まったのです。 我々が通ったルートを地図に書き出してみるとこのようになります。

12時間旅行

道中は浜松で鰻を食べました。特急を乗らずに浮いたお金で美味しい鰻を食べるライフハックとなります。

そんな楽しい(厳しい)旅を乗り越え、我々は大阪に到着し、トラコンに参加しました。

訪れた危機

大会の1日目(8/27)の朝に、チームメンバーが集まりました。チームメンバーが大阪と東京に居た関係で顔を合わせるのは前回大会ぶりでした。運営委員も疲れているだろうという事で、翼を授けるドリンクを差し入れ用に購入しました。

Redbull15本

会場に到着すると慌ただしく最後の詰めの作業をしている運営委員や、昨日遅くまで作業していたのかゆっくりと体を休めながら会場に到着する運営委員が居ました。前々回や前回の我々はあのように見えていたのか、という話をチームメイトとしていると、開場時間になったので我々も会場入り。そんな我々に用意されたテーブルには、他のチームのテーブルには置いてあるLANケーブルが無く、あったのはLANケーブルを作る為の工具類でした。

工具

するとにやけた顔の運営委員がやってきて、「皆さんはL1からお願いしますｗｗ」と言って去って行きました。ちくしょう。

まあ仕方が無いとメンバーでLANケーブルを作成します。こういう時に限って大人達は楽しそう写真を撮りにくるのです。ちくしょう。

さて、ようやくLANケーブルが出来上がってルータやスイッチに結線したら、ようやく競技を開始出来ます。

まず、スコアサーバにユーザ登録します。前回まで問題の出題や質問の窓口としてRedmineを用いていたのですが、今回は運営陣が開発したスコアサーバを用いて行いました。

kyontan/ictsc-score-server

個人アカウントの登録には「自分の名前」「自分で決めたパスワード」「運営から渡された登録コード」を用いるようです。登録コードは8文字程とのこと。 じゃあユーザー登録、を…

登録コード

運営委員によると128文字あるとのことでした。

な…何を言っているのかわからねーと思うが、俺も何をされたのかわからなかった…
ジャン＝ピエール・ポルナレフ

運営委員からの愛のプレゼント(単に嫌がらせとも呼びます)は問題にも現れます。

各チームにはそれぞれIP Phoneを渡されていました。 Cisco社から提供されたモデルはPoEによって運用されており、LANケーブル1本で電力とデータを供給出来ます。 しかし我々のチームのIP Phoneはそもそも色々な情報が来ていないようでした。 色々試してみたのですが問題が解決出来ず、ふと使われていた(これは運営陣が用意したLANケーブルです)ものを見てみると…

データ線無しLANケーブル

上が正常なLANケーブル、下がIP Phoneに刺さっていたLANケーブルです。 少し見づらいですが、下のLANケーブルには中の線が少し足りない事にお気づきでしょうか？

なんと運営委員は、PoEの中で電源給電部のみを残したLANケーブルを専用で作成していたのです。 ここまで手の込んだ悪戯をする為には、少なくない労力が必要でしょう。我々は逆に少し感心してしまいました。

さて、結果は…？

多くの運営委員からの嫌がらせ愛を感じながら、競技は終了しました。

結果としては2位相当(我々は招聘チームのため、表彰対象外となっています)で、あと8点足りず1位にはなれなかったようです。 うーん、残念。

前回のDMM.com Laboさんの言葉をお借りして、

『まあ結果はいいじゃないか』

という事で。

大会の翌日(8/29)、我々チームメンバーは会場に再度訪れていました。

大会は2日間で終わりですが、最後に会場からの撤収作業が必要となります。 お借りしたルータ、スイッチ、サーバ、ラックを1つ1つ梱包しながら片付けていきます。 勿論会場もお借りした時の状態に戻します。大会で利用したホワイトボードや机なども元の形に戻します。

東京へ送る荷物全ての発送が終われば、現地での作業は終了です。

まとめ

4日間の参加レポートをお届けしました。

参加者側からの視点で見るトラコンはまた運営側から見る物とは別の物です。 今までもそれは若干感じていたのですが、実際に運営側と参加者側両方を経験してみると、また色々な物が見えて興味深い感想を持ちました。 どういうような感想を抱いたのかなどは、今回の運営委員にフィードバックしていき、よりよい大会運営に役立てていきたいと考えています。

一緒に大会に参加してくださった参加者の皆様、この大会の為に尽力してくださった社会人の皆様、 そしてなにより、今回のトラコン開催にこぎつけた運営委員に感謝申し上げます。

次回大会をお楽しみに。

どのような形で関わるかは、この記事を読んでくださった貴方次第です。

ICTSC, ツール, 運用管理

はじめまして。
ICTトラブルシューティングコンテストの実行委員をやっている黒崎 (@kuro_m88) です。
学生時代に第3回の運営をやり、社会人になってからは運営学生のサポートをしています。

ICTトラブルシューティングコンテスト(以下ICTSC)とは、学生による、学生のためのインフラ技術コンテストです。
来月の2016年8月27日 にNTT西日本杯 第6回 ICTトラブルシューティングコンテストが大阪で開催されます。
トラコンに関する過去のツチノコエントリーは以下をご参照ください。

ツチノコブログICTSCエントリ集

TerraformでGitHubのチーム管理を自動化してみた

ICTSCでは出題に利用するコードや出題する問題案の管理をGitHubを利用して行っています。
https://github.com/ictsc

ICTSCに携わる学生や社会人は基本的にこのGitHub Organizationに入っているのですが、回によって運営に携わる学生も違います。
第4回だけ運営だった人もいれば、第4回, 第5回は運営だったけど、第6回は競技者として参加するといったケースもあります。

ICTSCのGitHub Organizationに入っている人は今回で50人くらいになるので、誰が第何回の運営だったかぱっと把握するのが難しくなってきました。

一番簡単なのはその回の運営に関係ない人をOrganizationからはずすことなのですが、せっかく運営に関わってくれたのにはずすのも寂しいなと思い、ユーザ管理をある程度自動化できないかなと思い立った訳です。(課金体系が変わったら運用方法を考えないといけませんが…)

Terraform GitHub Provider

その頃会社でTerraformを使い始めたので、GitHubも同じような感じで管理できないかなー？と調べてみると…！

なんと、Terraform GitHub Providerがあるではないですか…！?
https://www.terraform.io/docs/providers/github/index.html

これを使えばGitHubのOrganizationの

  • メンバー管理
  • チーム管理
  • チームのメンバー管理
  • リポジトリの権限管理

ができるようです。やりたい操作が全部用意されていました！！

ドキュメントを読みながら、こんな感じのものを作ってみました。
https://github.com/ictsc/ictsc-github-member

簡単に説明しますと、まずICTSCのGitHub Organizationのメンバーをここで定義します。
ictsc-github-member/members.tf

次に、チームを作ります。例えば第6回の運営参加メンバーはICTSC6というチームに所属させます。
また、そのチームが読み書きできるリポジトリも定義しています。
ictsc-github-member/team-ictsc6.tf

過去の運営チーム(ICTSC5等)のチームはプライベートリポジトリを見られないようにしています。
ictsc-github-member/team-ictsc5.tf

最後にこれらの操作をCircle CIで自動化できるようにします。
こんな感じの設定ファイルを書きました。
ictsc-github-member/circle.yml

運用方法

ICTSCのチームメンバに追加して欲しい人はプルリクエストを投げます。
https://github.com/ictsc/ictsc-github-member/pull/40

(ちなみに、彼は第5回の運営委員で、第6回は運営ではなく競技者として参加するのでこのプルリクエストは拒否します)

このリポジトリはpublicですが、マージする権限があるのは実行委員(社会人サポートチーム)の人だけなので、レビューののち production ブランチにマージするとCircleCI上でterraform applyが走り記述したとおりの権限がメンバーに与えられます?

いい感じですね！?

事故は突然に

github_membership.membership_for_kurochanという名前が冗長に感じたのでmembership_for_を取り払ってgithub_membership.kurochanのような書き方に統一したくなったので統一しました。

terraform planで変更内容を確認して、terraform applyしてみました。以下がその時のログです。

$ ~/terraform/terraform apply --var-file=conf/github.tfvars
github_membership.membership_for_kurochan: Refreshing state... (ID: ictsc:kurochan)
github_membership.membership_for_kurochan: Destroying...
github_membership.netmarkjp: Creating...
role: "" → "admin"
username: "" → "netmarkjp"
github_membership.kurochan: Creating...
role: "" → "admin"
username: "" → "kurochan"
github_membership.membership_for_kyontan: Destruction complete
github_membership.membership_for_kurochan: Destruction complete
github_membership.netmarkjp: Creation complete
github_membership.kurochan: Creation complete

コマンドの実行も成功し、当時管理者権限を持っていた僕ともう一名のアカウント設定の名前が、変更されています。
うんうん、ちゃんとうまく行ったようです。

ひととおり仕組みを作ったので学生に自慢しようと思った矢先、GitHubから一通の不穏なメールが…?

！？！？

誰かに僕のアカウントの管理者権限が外されたようです。

せっかくterraformで管理しているのでもう一度terraform applyしてみましょう。

2 error(s) occurred:

* github_membership.netmarkjp: PUT https://api.github.com/orgs/ictsc/memberships/netmarkjp: 403 You must be an admin to add or update an organization membership. []
* github_membership.kurochan: PUT https://api.github.com/orgs/ictsc/memberships/kurochan: 403 You must be an admin to add or update an organization membership. []

Terraform does not automatically rollback in the face of errors.

403 You must be an admin to add or update an organization membership.

??なんかやばそう！！??

とりあえずもう一人の管理者権限を持っている方に僕を管理者に戻すようにお願いしました。

えっ、もうこれはどうしようもないのでは…?

そしてだれもいなくなった…

管理者権限のあるユーザ全員(自分含め)から権限を剥奪してしまったようです。
誰一人管理者がいない状態なので、復旧のしようがありません。
学生にドヤ顔するつもりがなんと説明すればいいのか分からない状態になりました…。こんなことってあるのか…?

困ったときの神頼み

どうしようもなくなったので神様(サポート)に連絡するしかありません。
自分の英語力で通じるのか自信なかったですがとりあえず連絡…

すると

よかった…回復してもらえそうです。

どうしてこうなったのか

最初のログを見ると一見成功したように見えます。
ただ、2度目実行した時には権限がなくなっていてエラーになっていたので、APIコールした瞬間はすくなくとも権限を持っていたようです。

ここからは僕の想像なので本当にこうなっていたのか分かりませんが、例えばGitHub側が

こんな感じの権限の更新の処理が非同期に行われる仕組みになっていたとしたらTerraformのように高速でAPIを叩くアプリケーションを実行した場合、今回ような事故が起きそうです。。

対策

Terraformを実行する用のユーザを作成しました。
このユーザに管理者権限をもたせ、このユーザのアカウントに関してはTerraformの管理外としました。
これで自分で自分の権限を剥奪するような事故は起きないはずです。

教訓

terraform planはあくまでも実行計画を表示するだけであって、実際に適用したら成功するかどうかは別の話で保証されないということを身を持って経験しました…。
実行される内容が問題ないかしっかり確認してから適用しましょう。。(以後気をつけます)

さいごに

ICTトラブルシューティングコンテストではこのような実際の経験を元にしたトラブルの問題を運営学生がたくさん作っています！
次回コンテストも面白い(つらい？)トラブルが出題されると思いますのでご期待ください！！

ICTSC, イベント, 勉強会

こんにちは！

学生ツチノコのsaiです！

 

今回、第31回さくらの夕べ in 仙台で発表させていただいたスライドを公開しました！
（都合上、一部ページを削除してあります）

この度は、貴重な機会ありがとうございました！

 

また、スライドにもありますが、ICTSCは高校生から参加可能なので参加募集が開始されたら是非応募してみてください！！

（今回は大人チームでるのかな・・・？（チラ）

因みに、さくらの夕べは今回初の東北開催だったようですよ！（もっと東北のイベント増えてほしい・・・！）

 

PAGE TOP