はじめに
ICT トラブルシューティングコンテストとは、ネットワーク・サーバー・セキュリティ・データベースなどを出題範囲とし、それに関するトラブルを特定・解決し報告書を提出するといった競技内容となってます。
実際にトラブルが発生しているサーバーにアクセスし、課題解決に取り組みます。
今回は５人でチームを組み参加しました。
日程
2023 年３月４日～ ３月５日 の２日間オンラインで行われました。
１日目
| 時間 | 予定 |
|---|---|
| 10:00 ～ 10:20 | 開会式 |
| 10:30 | 競技開始 |
| 16:30 | 競技終了 |
２日目
| 時間 | 予定 |
|---|---|
| 10:00 | 競技開始 |
| 16:30 | 競技終了 |
| 17:30 ～ 19:00 | 閉会式 |
コンテスト前にやったこと
過去問を眺めていたところ、ネットワーク問題ではVyOSが使用されていたため、
VyOS の基本的な操作を勉強しました。
1 日目
この日はチーム同士オフラインで集まって取り組みました。
奴の名は (1)
この問題は、LDAP に保存されているaliceユーザーに ssh でログインできるようにするというものです。
早速つまずきました。
LDAP って何？？という状態だったので、まずはそこから調べました。
とりあえず、ssh すると
$ ssh alice@localhost
alice@localhost's password:
Permission denied, please try again.
このようにログインできませんでした。
色々調べましたが、分からなかったため次の問題に移りました。
なお２日目に再挑戦しました。
ping が飛ばない
この問題は、Host01 から Host02 への ping が飛ばない原因を突き止めて解決するというものです。
Host01,Router,Host02には VyOS がインストールされている状態です。
+------------+
| |
| Host01 |
| 172.16.0.1 |
+-----+------+
|
|
+-------+--------+
| 172.16.255.254 |
| |
| Router |
| |
| 172.17.255.254 |
+-------+--------+
|
|
+-----+------+
| |
| Host02 |
| 172.17.0.1 |
+------------+
まず、Host01 -> Routerでは ping が通るためHost01の静的ルーティングを疑い、見事設定されていないことが分かりました。
set protocols static route 172.17.0.0/16 next-hop 172.16.255.254
設定をしても ping が通らなかったため、Routerのファイアウォールを見ました。
とりあえず、icmp の許可を行いました。
set firewall name ETH1-OUT rule 11 action accept
set firewall name ETH1-OUT rule 11 protocol icmp
後は報告書を書いて提出し、満点を頂きました！！
やらかしたかもしれない…
この問題は、sudo suを実行した後にcd /ができなくなるため、それをできるようにするというものです。
user@host01:~$ echo $SEHLL
/bin/bash
user@host01:~$ sudo su
root@host01:/home/user# echo $SHELL
/usr/bin/rbash
制限付きのbashであるrbashであることが分かり、
$ ls -l /usr/bin/rbash
lrwxrwxrwx 1 root root 4 Jan 7 2022 rbash -> bash
bash のシンボリックリンクであり解除するコマンド
unlink rbash
を実行し解決しました。
データベースに入れない (1)
この問題は、PCからRouterを挟んで MySQLServerにログインできるようにするというものです。
+--------------+
| |
| PC |
| 172.16.1.128 |
+-----+--------+
|
|
+-----+------+
| 172.16.1.1 |
| |
| Router |
| |
| 172.16.2.1 |
+-----+------+
|
|
+-----+--------+
| |
| Server |
| 172.16.2.128 |
+--------------+
MySQL サーバーの設定等は他のメンバーに頼み、自分はRouterのファイアウォール等を確認しました。
set firewall name client-in rule 10 action accept
set firewall name client-in rule 10 destination port 3306
set firewall name client-in rule 10 protocol tcp_udp
しかし 200 点満点中 190 点だったため、残り 10 点の原因を模索しました。
なお２日目に再挑戦しました。
２日目
この日はチーム同士オンラインで取り組みました。
オフラインの方が教え合いや議論が円滑に進み、
やりやすいと感じました。
奴の名は (2)
/var/log/auth.logから ssh のアクセスログを見ました。
エラーログをそのまま検索にかけると/etc/nsswitch.confを修正することで解決することが分かりましたが、些細なミスにより正解には辿り着けませんでした。
俺自身が DHCP サーバーとなることだ
この問題は、wsmhostの DHCP サーバーを設定した上で直接machine-xを接続し、疎通確認を取るというものでした。
何も考えず、
$ sudo systemctl start isc-dhcp-server
をやってしまうと、wsmhostの ssh が切断され何もできなくなってしまいます。
閉会式で、この問題が一番再展開された回数が多いことが分かり、みんな同じミスをしているのかと思いました。
wsmhostには２つインターフェースがあり、それぞれデフォルトゲートウェイが設定されています。
そこで、デフォルトゲートウェイが必要でないインターフェースの設定を見直しました。
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.128 10.0.0.140;
# option routers 10.0.0.1; <- コメントアウト
option subnet-mask 255.255.255.0;
option broadcast-address 10.0.0.255;
default-lease-time 600;
max-lease-time 7200;
}
これで、解決です。
range 10.0.0.128 10.0.0.140;により DHCP のアドレスが10.0.0.128から割り当てられると思っていました。
10.0.0.128に ping が通りますが、実際machine-xには10.0.0.129が割り当たっていました。
なぞです。
とりあえず、満点だったので良かった。
user@wsmhost:~$ sudo systemctl status isc-dhcp-server
● isc-dhcp-server.service - ISC DHCP IPv4 server
Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; disabled; vendor preset: enabled)
Active: active (running) since Sun 2023-03-05 10:51:59 JST; 2min 3s ago
Docs: man:dhcpd(8)
Main PID: 40497 (dhcpd)
Tasks: 4 (limit: 1111)
Memory: 4.5M
CGroup: /system.slice/isc-dhcp-server.service
└─40497 dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf eth0
Mar 05 10:51:59 wsmhost sh[40497]: Listening on LPF/eth0/9c:a3:ba:32:44:0a/10.0.0.0/24
Mar 05 10:51:59 wsmhost dhcpd[40497]: Sending on LPF/eth0/9c:a3:ba:32:44:0a/10.0.0.0/24
Mar 05 10:51:59 wsmhost sh[40497]: Sending on LPF/eth0/9c:a3:ba:32:44:0a/10.0.0.0/24
Mar 05 10:51:59 wsmhost dhcpd[40497]: Sending on Socket/fallback/fallback-net
Mar 05 10:51:59 wsmhost sh[40497]: Sending on Socket/fallback/fallback-net
Mar 05 10:51:59 wsmhost dhcpd[40497]: Server starting service.
Mar 05 10:52:02 wsmhost dhcpd[40497]: DHCPDISCOVER from 9c:a3:ba:32:d5:13 via eth0
Mar 05 10:52:03 wsmhost dhcpd[40497]: DHCPOFFER on 10.0.0.129 to 9c:a3:ba:32:d5:13 (machine-x) via eth0
Mar 05 10:52:03 wsmhost dhcpd[40497]: DHCPREQUEST for 10.0.0.129 (10.0.0.128) from 9c:a3:ba:32:d5:13 (machine-x) via eth0
Mar 05 10:52:03 wsmhost dhcpd[40497]: DHCPACK on 10.0.0.129 to 9c:a3:ba:32:d5:13 (machine-x) via eth0
IPv6 の DHCP
この問題はdhcp-serverに frr をインストールして、clientに IPv6 アドレス(2001:db8::/64)を配布し、疎通確認をするというものです。
FRRouting が何のことか分からず、時間がかかりました。
コマンドは Cisco に似ている気がします。
$ sudo apt update && sudo apt install frr frr-pythontools
sudo vtyshで FRR に入り、eth0の設定をします。
公式ドキュメントでDHCPの単語で検索をかけてもなかったため、
IPv6 のページを見ていたらそれらしい説明がありました。
interface eth0
ipv6 address 2001:db8::1/64
ipv6 nd prefix 2001:db8::/64
no ipv6 nd suppress-ra
ipv6 nd prefix 2001:0DB8:5009::/64
これにより、dhcp-serverが定期的に自身を広報するようになります。
clientの方では、IPv6 の DHCP を有効にしました。
# /etc/netplan/01-netcfg.yaml
network:
ethernets:
eth0:
addresses:
- 192.168.6.2/24
dhcp4: 'no'
dhcp6: 'yes' ## 変更箇所
routes:
- to: 0.0.0.0/0
via: 192.168.6.254
nameservers:
addresses:
- <address>
- <address>
search:
- localdomain
renderer: networkd
version: 2
clientでip aをすると、
user@client:~$ 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
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 9c:a3:ba:32:93:a0 brd ff:ff:ff:ff:ff:ff
altname enp0s3
altname ens3
inet 192.168.6.2/24 brd 192.168.6.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2001:db8::9ea3:baff:fe32:93a0/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 2591712sec preferred_lft 604512sec
inet6 fe80::9ea3:baff:fe32:93a0/64 scope link
valid_lft forever preferred_lft forever
これより、clientが2001:db8::/64のレンジ内でアドレスが付与されていることが確認できます。
ping 結果は、
user@dhcp-server:~$ ping 2001:db8::9ea3:baff:fe32:93a0
PING 2001:db8::9ea3:baff:fe32:93a0(2001:db8::9ea3:baff:fe32:93a0) 56 data bytes
64 bytes from 2001:db8::9ea3:baff:fe32:93a0: icmp_seq=1 ttl=64 time=0.170 ms
64 bytes from 2001:db8::9ea3:baff:fe32:93a0: icmp_seq=2 ttl=64 time=0.304 ms
64 bytes from 2001:db8::9ea3:baff:fe32:93a0: icmp_seq=3 ttl=64 time=0.211 ms
64 bytes from 2001:db8::9ea3:baff:fe32:93a0: icmp_seq=4 ttl=64 time=0.187 ms
64 bytes from 2001:db8::9ea3:baff:fe32:93a0: icmp_seq=5 ttl=64 time=0.221 ms
^C
--- 2001:db8::9ea3:baff:fe32:93a0 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4102ms
rtt min/avg/max/mdev = 0.170/0.218/0.304/0.046 ms
満点を頂けました。
データベースに入れない (2)
ルーターで 3306 ポートのTCP通信のみを許可する設定に変更しました。
set firewall name client-in rule 10 action accept
set firewall name client-in rule 10 destination port 3306
set firewall name client-in rule 10 protocol tcp
また、Serverのファイアウォールの設定で IPv6 を不許可に変更しました。
# /etc/default/ufw
IPV6=no
２回修正し提出しましたが、点数は変わらず 190 点でした。
トラブルシューターの初仕事
この問題は OSPF に変更したところ、pcからsv01,sv02それぞれにアクセスできなくなりそれを解決するというものです。
あと一歩のところで解けなく悔しかったです。
３台のルーターで OSPF を動かしているのですが、router-idが重複していたためそれを修正しました。
しかし、それでも解決せず試行錯誤しましたが、断念しました。
たかし先輩の K8s 作問
マニフェストを眺めたり、pod や svc のログを見たり意味のないことをしていました。
まとめ
ICTSC2022 では主にネットワーク系の問題を２人で取り組みました。
Kubernetes を軽く触ったことがあり、問題に取り組んでみましたが全く歯が立たずまだまだだなといった感じです。
22 チーム中 14 位という結果となりましたが、とても良い刺激になりました。
