ICTSC Tech Blog

ICTSC2025 一次予選 問題解説: 問27 - 問30

ICTSC2025 問題解説

問27

Keepalived を用いた VRRP 構成を採用した新規システムを構築している。Keepalived の vrrp_script で使用する以下のようなヘルスチェックスクリプト chk_web.sh を作成した。

chk_web.sh
#!/usr/bin/env bash

curl -sSf http://localhost:8080/health > /dev/null
echo "Web service is healthy"
exit 0

ところが、アプリケーション群をすべて起動し VIP をもつサーバの電源喪失させる検証を行うと、想定していた副系へのフェイルオーバは発生しなかった。このトラブルを解決する方法として最も適当なものを1つ選べ。

選択肢（択一選択）

  1. curl コマンドから -s (silent mode) オプションを外す
  2. curl の出力を > /dev/null しないよう修正する
  3. bash のプロパティ set -e を設定するよう修正する
  4. スクリプトの最後に sleep をつける
  5. 明示的に書いている exit 0 を消す
  6. スクリプトの実行ユーザが root になるよう修正する
  7. echo によって標準出力をしないよう修正する

正解

  1. bash のプロパティ set -e を設定するよう修正する

解説

Keepaliaved の問題に見せかけて、実際はシェルスクリプト ( bash ) の挙動に関する問題。
bash の set -e プロパティを付け忘れて、コマンドエラー時でもスクリプト全体は正常終了してしまうという典型的なミスによるもの。選択肢３の修正を、例えば以下のように加えることでトラブルは解消できる。

#!/usr/bin/env bash
set -e

curl -sSf http://localhost:8080/health > /dev/null
echo "Web service is healthy"
exit 0

問28

あなたは Calico を利用した Kubernetes クラスタの保守を任されている。しかし、ある作業の後、異なるノード上の Pod 間通信が一切できなくなってしまった。調べてみると CoreDNS Pod のステータスは正常を返しているものの、アプリケーション間通信が名前解決の後にタイムアウトしているようだ。

このトラブルと直接関係があると考えられる、可能性の高い原因を全て選べ。

選択肢（複数選択）

  1. kube-proxy の iptables モードを無効化する変更をした
  2. calico-node の BGP セッションが切断されている
  3. CoreDNS が無効なレコードを返すようになっている
  4. ノード間の IPIP トンネルが破損している

正解

2. calico-node の BGP セッションが切断されている
4. ノード間の IPIP トンネルが破損している

解説

問題に「CoreDNS Pod のステータスは正常を返している」「アプリケーション間通信が名前解決の後にタイムアウト」とあることから、 CoreDNS の異常が直接の原因とは考えられない。また kube-proxy の iptables モード無効化による影響と仮定した場合サービス間通信全体に影響出て CoreDNS での名前解決以前に失敗するのが自然である。

問29

管理している Linux ベースのサーバ再起動後、起動遅延が発生してしまった。調査したところ /mnt/data のマウントが失敗しており、 dmesg には superblock が読めなかったとある。次のうち、考えられる直接の原因として 不適当なもの を全て選べ。

選択肢（複数選択）

  1. SAS カードが故障している
  2. マウントしようとするデバイスのラベルが SELinux で許可されていない
  3. ファイルシステムが破損しており、fsck による修復が必要な状況である
  4. LVM で対象の論理ボリュームがアクティベートされていない
  5. /mnt/data のマウントポイントがすでに他のボリュームで使用されている

正解

2 マウントしようとするデバイスのラベルが SELinux で許可されていない
5 /mnt/data のマウントポイントがすでに他のボリュームで使用されている

解説

SELinux でブロックされると権限不足、他のボリュームで使用されている場合は「すでにマウント済み」や「マウントポイントがビジー」などのエラーが出るのが典型的。

問30

オフィス環境改善の一環として、 IoT デバイスを複数台設置し温湿度データなどの収集を行い可視化を行うプロジェクトを推進している。大量の DNS レコード登録の手間を省くため mDNS による解決を利用し、オフィスに設置したクライアント PC にインストールした可視化ツールからアクセスし表示する設計でにしている。 また、セキュリティの観点から IoT　デバイスとネットワーク分離が必須となっており、 VLAN によりオフィスの社内ネットワークからのみアクセスできるようにする必要がある。そこで mDNS リピータを用いて一方向再送構成を目指している。

以下にネットワークの構成を示す。

[ VLAN 10 (IoT) ]              [ VLAN 20 (オフィス) ]
+----------------+                 +----------------+
| Device 01      |----.       .----| Client         |
|  iot-01.local  |    |       |    |  pc.local      |
|  (avahi-daemon)|  [L2SW]  [L2SW] |  (avahi-daemon)|
| Device ...     |    |       |    |                |
+----------------+    |       |    +----------------+
                      |       |
                      |       |
              +-----------------------+
              |     mDNS リピータ※　   |
              |-----------------------|
              |     eth0 (VLAN10)     |
              |     eth1 (VLAN20)     |
              +-----------------------+

※ ここでは [email protected] の service mdns repeater を使用

動作検証にてオフィスのクライアントから IoT　デバイスの名前解決ができることを確認した。しかし同時に、IoT ネットワークにノート PC を接続し pc.local へ通信した場合も名前解決が成功してしまうことが判明した。この構成において名前解決が想定外に成功した要因として可能性が高い適当なものを全て選べ。

選択肢（複数選択）

  1. 検証に用いたパソコンが pc.local の情報が過去にキャッシュしており、応答なしでもローカルで名前解決できた
  2. mDNS リピータが、指定したすべてのインターフェース間で mDNS を双方向中継するようになっている
  3. IoT デバイスの avahi-daemon で reflector が有効になっており、 mDNS クエリがオフィスネットワークの機器へ中継されている
  4. 検証に用いたパソコンの nsswitch.conf のホスト設定により dns が mDNS よりも優先となっており、 RFC に準拠した企業内 DNS によって .local を解決している
  5. IoT デバイスの avahi-daemon が mDNS クエリを受信し、学習したホスト情報を代理応答している

正解

  1. 検証に用いたパソコンが pc.local の情報が過去にキャッシュしており、応答なしでもローカルで名前解決できた
  2. mDNS リピータが、指定したすべてのインターフェース間で mDNS を双方向中継するようになっているため

解説

  1. mDNS キャッシュのこと
  2. VyOS の mDNS repeater は、指定したすべてのインターフェース間で mDNS を双方向中継する実装となっている
  3. 複数インターフェースを跨いで反射するが、IoT デバイスは IoT ネットワーク ( VLAN 10 ) のみにしか接続性を持っておらず、VLAN20 へ直接中継できない
  4. RFC 的には .local は mDNS 用に予約されており .local ゾーンを DNS にて扱うことは RFC 違反であるため、「 RFC に準拠した企業内 DNS 」により解決されることはないと考えるのが妥当
  5. avahi-daemon では /etc/avahi/hosts に静的に定義されたホスト情報を返すことは可能だが、他ホストの mDNS を動的に学習し代理応答することはない