ICTSC2025 一次予選 問題解説: 問23 - 問26
問23
以前は正常にクライアントから SSH 接続できていた server01（IP アドレス：10.0.2.10/24）に接続できなくなった。調査の結果、以下のような出力が得られた。
$ traceroute 10.0.2.10
traceroute to 10.0.2.10 (10.0.2.10), 30 hops max, 60 byte packets
1 10.0.1.1 (10.0.0.1) 0.057 ms 0.018 ms 0.020 ms
2 10.0.1.1 (10.0.0.1) 3083.580 ms !H 3082.961 ms !H 3082.930 ms !H
$
$
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0@if49: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether bc:24:11:1a:b4:94 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.0.1.50/24 brd 10.0.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::be24:11ff:fe1a:b494/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
$ ssh user@server01
ssh: connect to host server01 port 22: No route to host
$ ip route
default via 10.0.1.1 dev eth0 proto static
10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.50
$cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.0.2.10 server01
# ping server01
PING server01 (10.0.2.10) 56(84) bytes of data.
From 10.0.1.1 icmp_seq=1 Destination Host Unreachable
From 10.0.1.1 icmp_seq=2 Destination Host Unreachable
From 10.0.1.1 icmp_seq=3 Destination Host Unreachable
From 10.0.1.1 icmp_seq=4 Destination Host Unreachable
^C
--- server01 ping statistics ---
19 packets transmitted, 0 received, +12 errors, 100% packet loss, time 19814ms
pipe 4
SSH 接続できなくなった原因として現時点で最も可能性が高いものを1つ選べ。ただし、クライアントと同じセグメント帯の他のホスト、server02（IP アドレス： 10.0.1.10/24）には接続可能である。
選択肢（択一選択）
- クライアント PC が
10.0.2.0/24へのルートを保持していない - server01 の iptables により通信が DROP されている
- server01 の NIC がダウンしているためクライアントのデフォルトゲートウェイが ARP 解決できていない
- クライアントの ARP キャッシュが古くなっており正しい MAC アドレス解決ができない
解説・作問者コメント
ping と traceroute の結果は、通信の失敗がクライアントからではなく、デフォルトゲートウェイ（10.0.1.1） から発生していることを示しています。これは、クライアントPCが宛先である 10.0.2.10（server01）へのパケットをデフォルトゲートウェイに正しく転送したものの、ゲートウェイがその先の経路を知らなかったためとなります。したがって、正解は 3 となります。
問24
client01 で外部ホスト名の解決ができないという報告があった。DNS 関連の設定を確認したところ、次の通りであった。
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=4.03 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=3.44 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=3.49 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=3.17 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4011ms
rtt min/avg/max/mdev = 3.170/3.505/4.029/0.283 ms
$ ping google.com
ping: google.com: Name or service not known
$ cat /etc/resolv.conf
nameserver 127.0.0.53
$ systemctl status systemd-resolved
active
$ resolvectl status
Global
DNS Servers: —
Fallback DNS: 1.1.1.1
Link 2 (eth0)
Current Scopes: DNS
DNS Servers: —
なお、以下の事項を前提とする。
- DHCP クライアントは使用しているが、DHCP サーバより DNS サーバを取得しているかは確認できていない
- NetworkManager は有効状態である
/etc/systemd/resolved.confのDNS=は空欄である
外部ホスト名が解決できない原因として最も可能性が高いものを1つ選べ。
選択肢（択一選択）
- クライアントが DHCP から DNS サーバを正常に取得できていない
- Fallback DNS は存在しているが、Primary DNS が設定されていないため無効になっている
systemd-resolvedのキャッシュが破損し、内部ループが発生している127.0.0.53が自身を指しているため、名前解決が循環している
解説・作問者コメント
Fallback DNS は条件付きでしか使われず、通常のクエリでは参照されません。Primary DNS が空なため、lookup できず失敗するはずです。可能性として 1 もあり得ますが、添付されているログ、条件より DHCP で DNS サーバが取得できているかいないかを確認するコマンドを実行していないため「最も可能性の高いものを選択する」ということから選択肢を絞り込んでいただく形となります。したがって、正解は 2 となります。
問25
VyOS を起動後、IP アドレスの設定とルーティングを設定し、commit と save を実行し通信を行った。数日後、VyOS を起動したところ、設定が全て消えてしまっていた。設定が消えてしまった原因を記述せよ。
解説・作問者コメント
問題文ではインストール作業を行ったことが明記されていません。
そのため、インストール作業を行わずに commit, save を実行したせいで、再起動時に設定が消えてしまった、ということを推察する問題でした。
初めて VyOS、Linux を触られた方がほとんどこの事象を経験するかと思われます。また、採点においてはインストール以外の事象として、揮発性のものに書き込んだからなどということなどについても採点の対象としています。それ以外の回答については未知の事象として部分点の対象とさせていただいております。
問26
Docker Compose を使って WordPress 環境を構築しようとしたが、コンテナは正常に起動しているにも関わらず、ウェブブラウザからサイトにアクセスできない。
以下に、 調査時の状況を挙げる。
docker compose up -dを実行後、docker psでwordpressコンテナとdbコンテナの両方が Up 状態であることを確認済みdocker logs wordpress_appを確認しても、エラーログらしきものは見当たらない- ホスト OS から
curl http://localhost:80を実行しても、何も応答がない docker inspect <wordpress_app_container_id>で確認すると、wordpressコンテナはポート 80 をリッスンしていることが確認できる- nftables の設定では、
tcp dport 80 acceptのみ投入し、ポート 80 へのアクセスを許可したが、それ以外のルールについては確認をしていない - docker のバージョンは 28.2.2 であり、docker compose のバージョンは v2.36.2 である。
- OS は RockyOS9 である
以下は使用している docker-compose.yml である。
services:
db:
image: mysql:8.0
container_name: wordpress_db
environment:
MYSQL_ROOT_PASSWORD: root_password
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress_password
volumes:
- db_data:/var/lib/mysql
wordpress:
depends_on:
- db
image: wordpress:latest
container_name: wordpress_app
ports:
- "80:80"
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress_password
WORDPRESS_DB_NAME: wordpress
volumes:
- ./wp-content:/var/www/html/wp-content
volumes:
db_data:
ウェブブラウザからサイトにアクセスできない原因として考えられるものを1つ選べ。
選択肢（択一選択）
- ホスト OS の nftables に、コンテナの公開ポートへルールがなく通信をドロップしている
- ホスト OS の別のプロセスがポート 80 を使用しており、
wordpressコンテナがポートをバインドできていない docker-compose.yml内のWORDPRESS_DB_HOSTの値が間違っており、wordpressコンテナがデータベースに接続できていない- Docker ネットワークが正しく構成されておらず、
wordpressコンテナとdbコンテナ間で通信できていない wordpressコンテナの起動スクリプトに問題があり、Web サーバ（Apache/Nginx）が正常に起動していない
解説・作問者コメント
ホスト OS の別のプロセスがポート 80 を使用していいた際、コンテナは起動できないのと、compose.yml にて 80 をバインドしているため、2 を選択から除外。 compose.yml を見る限りでは記述は間違えていないのでパスワード設定ミスなども可能性としてはあるが、問題文から読み取れる情報として可能性としては一番低いため 3 も除外。wordpress と db コンテナ間で正しく通信できていない際、wordpress コンテナが起動しないため、4 も選択肢から除外。 コンテナの起動スクリプトに問題がある場合、大抵の場合は、エラーログとして出力されるが、問題文からは読み取れない為、5も除外。nftable でポート 80を許可する設定をしたものの、どの範囲に入れたか問題文、状況には記載していない為、考えられる可能性として １ が正答となります。