ICTトラブルシューティングコンテスト2022（ICTSC2022）に参加しました

はじめに

2023/03/05 から 2 日間に渡って開催されていた ICT トラブルシューティングコンテストに参加しました。

ICT トラブルシューティングコンテストとは

ICT トラブルシューティングコンテスト（略称 ICTSC）は、任意団体であるようです*1。それと同時に、仲間とトラブルシューティング力を合わせることで様々な情報通信技術に関する問題を解決し、その回答の正確さや速さを競うコンテストだと思われます。

一緒に参加した人々

チームメンバーは以下の通りでした。

• coord-e
  • https://github.com/coord-e
• tosuke
  • https://github.com/tosuke
• azarashi2931
  • https://github.com/azarashi2931
• cyanolupus
  • https://github.com/cyanolupus
• public_yusuke
  • https://github.com/private-yusuke

この 5 人でチーム word-unknown-tsukuba-otaku として参加しました。

解いた問題

私が解いたのは以下の問題です。この順番に解きました。提出した回答もセットでどうぞ。

• 奴の名は（qvf）
  • https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-qvf-md
• 盲点の窓（rct）
  • https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-rct-md
• pingが飛ばない（vzx）
  • https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-vzx-md
• 俺自身がDHCPサーバーとなることだ（wsm）
  • https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-wsm-md
• Beer (sjq)
  • https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-sjq-md

それぞれどのような方針で解いたのかを簡易的に説明します。

奴の名は（qvf）

ユーザー alice で Linux のパスワード認証をしようとしても弾かれてしまうのでどうにかして直してほしい、という問題でした。/var/log/auth.log を見てみると、pam_ldap が LDAP サーバーに情報を見に行こうとしたときにうまくいっていなさそうだな、ということがわかりました。

私は LDAP まわりの知識がほとんど無いため、Linux のユーザー認証時に LDAP からの情報を参照する際に記述する必要のある設定ファイルを見てみることにしました。すると、どうやら /etc/nsswitch.conf 内で LDAP 用の記述が少し足りていないことがわかったので、これを追記することで「ログインできてシェルを得る」ことが実現できました。あとは報告書を書きました。

感想：研究室で今度 LDAP まわりを触る機会がありそうなので、その練習になった気がします。
提出回答：https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-qvf-md

盲点の窓（rct）

host01 で nginx.service の様子を確認すると起動に失敗していることがわかります。nginx.conf からは blog.example.jp のための nginx の設定ファイルを参照しているのですが、このファイルはシンボリックリンクを間違えて自分自身に貼っているものになっており、その旨を伝えるエラーメッセージが出ていることもわかりました。

sites-available/blog.example.jp にあるものを sites-enabled/blog.example.jp に貼り直してあげて nginx.service を restart すると、これは正常に起動するようになりました。しかし、この段階では bastion から curl -H 'Host:blog.example.jp' 192.168.255.9 を叩いても 502 が帰ってきてしまいます。そのため、リバプロまわりがおかしそうだなと思い blog.service のファイルと sites-available/blog.example.jp を見比べてみると、前者を起動するときに listen する host は 192.168.255.9 になっているのに対し、後者で nginx がアクセスする際に指定しているのは localhost すなわち 127.0.0.1 になっており、リクエストが blog.service に届いていませんでした。このため blog.service が listen する host を localhost に変更し、これを restart して問題を解決することができました。あとは報告書を書きました。

感想：エラーログと systemd service のファイルを読むと流れに沿って解けるようになっていてよかったです。nginx の設定ファイル側を解決するだけではダメ、というように問題が二段重ねになっているところにリアルさが感じられて楽しかったです。
提出回答：https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-rct-md

pingが飛ばない（vzx）

Host01 で ip route get 172.17.0.1 をしてみると Network is unreachable と言われてしまうので、経路情報が足りていないことがわかりました。そこでデフォルトゲートウェイの設定を流し込みました。しかし、それでも ICMP Echo Reply は帰ってきません（おおきなかぶ）。ルーター 172.16.255.254 で tcpdump をしてみると ICMP Echo Request までは届いているけれど、ICMP Echo Reply はキャプチャできなかったことがわかりました。ここでウーンと唸っていたらチームメイトに firewall の設定見た？と言われ、アッと思いすぐさま firewall の設定を見てみると TCP のものはすべて通す設定がありますが ICMP については特別 accept してる訳でもなく drop されていたことがわかりました。このため、ICMP は accept するようなルールを追加してあげることで問題を解決することができました。あとは報告書を書きました。

感想：やりたいことをまとめると複雑なものでは無かったのですが、VyOS 筋が一切なかったので入門しながら解くことになりました。良い体験でした。
提出回答：https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-vzx-md

俺自身がDHCPサーバーとなることだ（wsm）

他のチームメイト 2 人がわからないまま残していたため心してかかりました。一見して dhcpd.conf 自体は問題なさそうだったので割と悩んでしまいました。また、初期状態のまま DHCP サーバーを起動すると SSH 接続が切れてしまい、何回か再展開を実施することになりました。

ip a で 10.0.0.1 が自分のマシンの network interface のうちどれかに割り振られていることは確認したのですが、ではこれが netplan の設定ファイルで本当にそうなるように書かれているのかと気になって確認してみたところ、なんと書いてありませんでした。これが原因なのかと思い、IP アドレスの固定の設定を netplan の yaml に入れて apply した状態で DHCP サーバーを起動したところ、SSH セッションが切れることなくうまく動いてくれました。おそらく DHCP で配ることを指定した範囲の最初の IP アドレスが machine-x に割り当てられるだろうと考えたので ping したり ssh してみたところ接続できたのでビンゴでした。あとは報告書を書きました。

感想：再展開キューに何度も積んでしまった。すみません！🙇‍♂️
提出回答：https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-wsm-md

Beer (sjq)

BGP ルーターに限らず、ソフトウェアルーターはそもそも BIRD*2 しか使ったことがなかったので、最初は苦戦しながら FRRouting のコンフィグを書きました。

素直に AS65002 から広報される prefix を FIB*3 に入れるようにすればよいです。1 回目の提出では広報されていることのみを確認し、対向の BGP ルーターを経由することなく 192.168.17.102 と繋がるような経路で疎通確認をしてしまったため 0 点でした。

チームメイトの中に趣味で iBGP をやっている人がいて、その方に 2 日目の最初にこの問題を一度任せましたが、途中でまた問題が手元に戻ってきました。その間にコンフィグには no bgp ebgp-requires-policy という設定が新たに入れられていました。これを調べてみたところ、no bgp ebgp-requires-policy という設定を router bgp 65001 内に入れることで filter 等を定義することなく FIB に経路情報を入れることができるものということでした*4。ただ、これだけでは足りてなかったようで、network interface の設定も FFRouting のコンフィグに入れてあげることで FIB に経路情報を登録させることができました。

感想：趣味では BIRD でしか BGP を扱ったことがなかったので刺激的でした。
提出回答：https://gist.github.com/private-yusuke/8121662d08758646cebd27b9e271d1c0#file-sjq-md

おわりに

ソフトウェアルーターらしきものは今まで BIRD しか触ったことがなく、今回 VyOS や FFRouting に触れたときに「これって R○X1200 とか Cisc○ みたいな書き味でコンフィグ書けるのか！便利だ〜」となりました。

コンテスト中の私は、高得点で専門性を要するような問題は他の方に任せて、あまり高くない点数のものを率先して解くようにしていました。SRE っぽいことはあんまりわからないのですが、BGP に関する問題は趣味でグローバル IPv6 アドレスを広報していたおかげでなんとかなりました。自分が LIR に払った 5 万円ぐらいのお金は今回だけでも回収できた気になれました。

両日とも 12:00 頃までは家で集中して各自が問題を解き、13:00 頃に大学に集合してからはアドバイスや相談をしあいながら黙々と解いていました。たまたま各領域に詳しい人が集まったので、うまく並列しながら問題の消化を進められたものと思います。

初めて参加したのですが、まさにこのようなコンテストがあると解きがいがあるなと思い、心から楽しめました。

そして、なんと優勝することができました！チームメイトには大変感謝しています！！運営の方々も魅力的なコンテストを開催して頂きまして本当にありがとうございました。

word-unknown-tsukuba-otaku が 1 位であることを発表するスライド

おまけに

4 人友達がいてよかった図

*1:https://icttoracon.net/about-ictsc

*2:https://bird.network.cz/

*3:Forwarding Information Base

*4:https://docs.frrouting.org/en/latest/bgp.html#clicmd-bgp-ebgp-requires-policy 参照