/
カテゴリー

問題文  

概要  

あなたが働く株式会社ICTSCでは、WebサイトをホストするためにKubernetesクラスタを構築しました。しかし、担当者が何らかのミスをし、現在クラスタは正しく動いていない状態です。
また、残念なことに担当者は失踪し、あなたが後任となりました。
正しくWebサイトへリクエストが送れるように、Kubernetesクラスタを直してください。

ネットワークの構成とは以下のようになっています。f35-managerと呼ばれるノードが3つ、f35-workerと呼ばれるノードが3つあり、それぞれ192.168.7.1から192.168.7.6までIPアドレスが割り振られています。それぞれのマシンは同じLANに属しています。 また、f35-lbと呼ばれるロードバランサがあり、kube-apiのロードバランシングを行っています。

image

またKubernetes内部では、HTTPリクエストへ応答するために、Webサーバーのリソースが作成されています。

他に仕様書などはありません。

初期状態  

  • 参加者の踏み台サーバーから curl 192.168.7.1:30000 を実行しても応答がない (connection refused)

終了状態  

  • 参加者の踏み台サーバーから curl 192.168.7.1:30000 を実行するとHTTP応答が帰ってくる

解説  

この問題で発生しているしている具体的な問題は2点。

  • f35-worker-3のkubelet.serviceがdisable & stopされている点。
  • ホスト名が変更されており、かつ使用不可能な文字が含まれている。

ホスト名でアンダーバーが使用されていると、kube-apiserverが起動しません。さらに、ホスト名が初期のものと変更されているので、それも元に戻す必要があります。

まず、各managerノードの/etc/kubernetes/kubelet.yamletcd.yamlを見ると、当初のホスト名であるf35-manager-数字が判明するので、managerノードのホスト名を修正できます。

その後、kubectl get nodeコマンドが使えるようになるため、そこでworkerノードのノード名(当初のホスト名)が判明します。そのためworkerノードのホスト名も本来の名前であるf35-worker-数字へ修正できます。

2つ目については、f35-worker-3のkubelet.serviceをstart & enableするだけで構いません。 以上でk8sクラスタが起動するようになります。 また、aliceのdeploymentはnodeselector: f35-worker-3指定があるため、worker-3が起動しないと動かないような設定になっています。

これにについて、報告書に明記していないがおそらく暗黙的にsystemctl start kubeletなど行って居たためにworker-3が起動していたチームは、deployment自体は動いていても満点にしていません。

ただ、「原因の報告」の明記は問題文中で指定されていなかったため、結果worker-3でpodが動くような指示(systemctl startsystemctl restartsystemctl disable && reboot、nodeselectorの削除等)を報告書に明記したチームに関しては満点にしました。

最後に、kubectl get serviceを実行すると、Aliceという名前のdeploymentがNodePort 30000ポートでlistenしていることがわかる。 試しにcurlしてみるとリクエストが通るので問題が解決できたことになります。

所感  

f35-worker-3のkubelet.serviceがdisable & stopされている点。という問題が結構なチームが気づかれず、作問者としては残念でした。

採点のポイントとしては、 「問題解決の手順を報告書に書いているかどうか」 と 「初期状態のマシンで、報告書に書いてある作業を同じように実行すれば終了状態を満たした状態ができるかどうか」 「報告書に書いてあるコマンドや編集作業を問題サーバーでも同じように実行しているかどうか」 の3点で採点を行いました。 ちなみに、今回満点を取ったのは3チームです。

最後に今回の珍解答ですが、k8sクラスタを解体しゼロから作り直しているチームが複数見受けられました。 正直、内容を見る限りとても頑張っていて点数を上げたかったのはやまやまなのですが、解体前に内部で動いているリソースをエクスポートし、構築後applyができていなかった(終了状態を満たしていなかった)ため、0点とさせていただきました。

以上、ありがとうございました。

 /
カテゴリー

問題を解いていただきありがとうございました!

問題文  

概要  

あなたのクラスメイトのA君は、CiscoルーターであるRTとUbuntuサーバーであるServer間でIPIP over ipsecの検証をしていました。 しかし、設定を変更しているとRTServer間の疎通ができなくなってしまいました。
A君の代わりに、RTServerのIPIP over ipsecの設定を修正し疎通できるようにして下さい。

topology.png
  • RT
    • Cisco CSR 1000v
    • IPアドレス
      • gi1 192.168.14.10/24
      • tun0 10.50.0.1/30
  • Server
    • Ubuntu 18.04
    • ipsec: strongswan
    • IPアドレス
      • eth0 192.168.14.20/24
      • tun0 10.50.0.2/30

初期状態  

  • RT, Server間で通信が行えない
    • RTから ping 10.50.0.2 をしても応答がない
    • Serverから ping 10.50.0.1 をしても応答がない

終了状態  

  • RT, Server間で通信が行える
    • RTから ping 10.50.0.2 をして応答がある
    • Serverから ping 10.50.0.1をして応答がある
  • IPIP over ipsecでトンネリング及び暗号化がされている
  • 設定が永続化されており、再起動後も自動で疎通ができる状態になっている

採点基準  

  • RTとServer間の通信でき、暗号化されている (80%)
    • RT -> Server ping 10.50.0.2 (40%)
    • Server -> RT ping 10.50.0.1 (40%)
  • 上記を満たしており、トンネリングにはIPIPのみを用いている (20%)
    • ipsecでトンネリングやその他のトンネリングはNG

解説  

RTとServerのそれぞれの設定が間違っていることによるトラブルでした。 具体的には以下の3つの原因が上げられます。

  • strongswanの設定でauto=addになっている
  • ipsecの通信モードが異なっている
  • ikeのバージョンが異なっている

原因  

strongswanの設定でauto=addになっている  

auto=addを設定したとき、strongswanは起動時設定の読み込みのみを行います。そのため、手動で接続しなければトンネルを張ることができません。 そこで、startまたはrouteを設定することによって接続を自動で行うようにします。

startrouteは以下のように動作します。

  • start サービス起動時にトンネルを張る
  • route 通信時にトンネルを張る

ipsecの通信モードが異なっている  

strongswanではipsecの通信モードをtype=transportとtransportモードに設定していますが、RTではmode tunnel とtunnelモードになっていました。

今回の構成では、IPIP over ipsecを行っているのでトンネリングはIPIPが担当します。そのため、ipsecではトンネリングする必要が無いのでRTの設定をmode transportに設定します。

ikeのバージョンが異なっている  

上記の問題を解決したあと、RTからServerへpingを送ってみると、接続が確立され疎通が取れていることが確認できます。

RT#ping 10.50.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.50.0.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms

しかし、接続を確立していない状態でServerからRTへpingを送ってみると接続が確立されず疎通が取れません。

user@Server:~$ sudo systemctl restart strongswan
user@Server:~$ ping -c 1 10.50.0.1
PING 10.50.0.1 (10.50.0.1) 56(84) bytes of data.

--- 10.50.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

RTは設定からikev1を利用していることがわかります。 strongswanの設定では、keyexchange=ikeというように指定されています。strongswanでは、ikeを指定した場合、接続の開始時にikev2を提案します。しかし、受信時にはいずれかのバージョンをacceptします。
そのため、RTからServerでは接続できでも、ServerからRTはできないという状態になっていました。 今回の構成ではikeのバージョンを指定されていないので、楽に修正ができるikev1に合わせます。 strongswanの設定を、keyexchange=ikev1に変更します。

修正後の設定  

RTの設定  

RTの設定は以下のようになります。(show run 一部抜粋)

crypto ipsec transform-set TS_IPSEC esp-aes esp-sha256-hmac 
 mode transport

Server(strongswan)の設定  

Serverのstrongswanの設定(/etc/ipsec.conf)は以下のようになります。

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
	
conn RT
	authby=secret
	left=192.168.14.20
	leftid=192.168.14.20
	right=192.168.14.10
	rightid=192.168.14.10
	auto=start
	type=transport
	keyexchange=ikev1
	ike=aes-sha256-modp3072
	esp=aes-sha256

参考文献  

 /
カテゴリー

問題文 

A社の社内システム用に作成したdocker上のmariaDBコンテナが非常に不安定で、すぐに落ちてしまい、社内システムの可用性に影響が出ている。 このシステムはとある社員が一人で作成したが、完成した日に退職してしまって連絡が取れず、このシステムの仕様書なども存在しない。

現在コンテナに安定したアクセスができない原因を報告し、 コンテナをレコード情報を保持したまま動作が可能となるように復旧せよ。

初期状態  

  • VM上でdocker ps -aをするとmariaDBコンテナが1つ存在している
  • VM上でdocker start mariaDBdocker exec -it mariaDB bashをしても落ちて開けない

終了状態  

  • コンテナが継続して起動している状態である
  • docker exec -it mariaDB bashでコンテナに入ることができ、入った際にMariaDBのDBictsc_incusersテーブルを見たときに
+----+------------+-----------+------+-------+
| ID | First_Name | Last_Name | Age  | Sex   |
+----+------------+-----------+------+-------+
|  1 | Tarou      | Yamada    |   23 | MAN   |
|  2 | Emi        | Uchiyama  |   23 | WOMAN |
|  3 | Ryo        | Sato      |   25 | MAN   |
|  4 | Yuki       | Tayama    |   22 | WOMAN |
|  5 | Yuto       | Takahashi |   21 | MAN   |
+----+------------+-----------+------+-------+

が存在している。

  • 社内システムがDBを参照出来るよう、3306番ポートが開いている。

配点  

  • このコンテナが不安定になっている原因を明確な証拠をもとに正しく特定できている(60%)
  • コンテナが継続動作するように復旧できている(25%)
  • 当該コンテナ上で問題文通りのレコードを参照できる(15%)

解説  

こちらの問題では、社内システムのデータベースとして使用している DockerのMariaDBコンテナの動作が何らかの原因で不安定になっているがその原因を報告し解決する、 というものでした。

まずこの問題でのシステム構成図を説明したいと思います。  このMariaDBコンテナと社内システムは3306番ポートを用いて接続されており、社内システムは日々このコンテナのMariaDBに対しデータの読み書きを行っています。 また、このコンテナはコンテナ内部にデータを保持している訳ではなく、mariaVOLというDocker内部のボリュームにコンテナ内部のデータディレクトリ/var/lib/mysqlをマウントしています。よって、このコンテナが破損したとしてもデータベース内部のデータは保持され続ける仕組みとなっております。

トラブルの原因  

この問題でMariaDBコンテナが不安定であった原因はこのシステムを退職した社員が「サーバーのメモリが足りないので、メモリを食わないようにしたい」ということでこのMariaDBコンテナが使用できるメモリの量を4MBにしたことが原因でした。 以下が当該コマンドです。

docker run -m "4M" -v mariaVOL:/var/lib/mysql -d --name mariaDB -e MYSQL_ROOT_PASSWORD=MariaPass -p 3306:3306 -d mariadb:latest

-mオプションでこのコンテナが利用できるメモリを4MBまでに制限していることが分かります。 ここでは当時打たれたコマンドを出してメモリ制限がされていることが分かりましたが、今回はDockerの設定やログ等でしかトラブルの原因を知ることが出来ません。

この原因を知る例として、細かいものは他にもあるかとは思いますが、大きく2つ紹介します。

1.docker inspectコマンドを使用する  

docker inspectコマンドは、dockerコンテナの設定情報を参照することが出来るコマンドです。これを見ると、コンテナがどのような設定で動作しているのかが分かります。しかし、この設定データの量は膨大で、全てを見るには時間がかかってしまいます。 例えばですが、この問題の原因のメモリについて調べたい際、docker inspect mariaDB | grep Memoryなど、grepコマンドなどを使い検索すると、

 "Memory": 4194304,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": -1,
            "MemorySwappiness": null,

といった値が出てきます。ここに出た"Memory": 4194304という値はバイト表記でして、MBに換算すると約4MBということが分かります。設定されていた値と同じですね。

2.docker statsコマンドを使用する  

docker statsコマンドは、コンテナのリソース使用状況を表示するコマンドです。Linuxのtopコマンドに似たような機能を持っています。 ここで、コンテナのリソース使用状況を知ることが出来ます。

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT   MEM %               NET I/O             BLOCK I/O           PIDS
eb99786557f7        mariaDB             8.44%               3.664MiB / 4MiB     91.60%              656B / 0B           1.89GB / 0B         3

こちらでもMEM USAGE / LIMITの欄で3.664MiB / 4MiBと見えており、メモリが4MB制限であること、そして使用中のメモリが逼迫している状態であることから不安定になる原因であることが推定出来ます。

解決策  

前項の方法でメモリ制限が原因であることを突き止めた場合、現在のトラブルをどのように解決するかについて例を載せます。

1.docker updateコマンドを使用しリソース設定を更新する  

docker updateコマンドはコンテナの設定を更新するためのコマンドです。 コンテナの設定をコンテナを作り直すことなく変更することが可能です。 例として、問題のコンテナのメモリ制限を4MBから1GBへと緩和します。例えば、 docker update --memory 1G mariaDBこのコマンドを実行する事により、メモリ上限を4MBから1GBに変更することが出来ます。 docker inspect mariaDB | grep Memoryで見てみると

            "Memory": 1073741824,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": -1,
            "MemorySwappiness": null,

となり、Memory": 1073741824(byte)は約1GBですので、1GBへと緩和されたことが分かります。

2.同じ設定のコンテナを作り直す  

解法の一つとして、同じ設定のMariaDBコンテナを再作成する方法があります。 docker run -v mariaVOL:/var/lib/mysql -d --name mariaDB -e MYSQL_ROOT_PASSWORD=MariaPass -p 3306:3306 -d mariadb:latest などで、メモリ制限を緩和、およびメモリ制限を無くしたコンテナを作成します。 ただし、MariaDBのデータベースはボリュームmariaVOLにマウントされているという点に注意しなければなりません。mariaVOLへコンテナをマウントしないと、コンテナに入ってもデータベースを参照することが出来なくなってしまいます。

上記の2つの設定のどちらかを適用し、

docker exec -it mariaDB bash

mysql -u root -p ${MYSQL_ROOT_PASSWORD}

use ictsc_inc;

select * from users;

をするとこちらのテーブル

+----+------------+-----------+------+-------+
| ID | First_Name | Last_Name | Age  | Sex   |
+----+------------+-----------+------+-------+
|  1 | Tarou      | Yamada    |   23 | MAN   |
|  2 | Emi        | Uchiyama  |   23 | WOMAN |
|  3 | Ryo        | Sato      |   25 | MAN   |
|  4 | Yuki       | Tayama    |   22 | WOMAN |
|  5 | Yuto       | Takahashi |   21 | MAN   |
+----+------------+-----------+------+-------+

を見ることが可能で、復旧したことが分かります。

 /
カテゴリー

問題文  

概要  

おお久しぶり!!

君が居ないあいだに社内ネットワークを IPv6 only にしておいたんだ。外向きのIPアドレスは v4 しかないけどルーターで NAT64 をしているからインターネットにはつながるようになっているよ。

ただ名前解決ができないのと社内ネットワークにある Web に繋がらなくなっちゃったんだ、これ以上は手が付かないから君がなんとかしてくれないかな?

初期状態  

  • ubuntu-1 から curl https://blog.icttoracon.net/ をしてもつながらない
  • ubuntu-1 から curl http://[2403:bd80:c000:900::1]/ をしてもつながらない

終了状態  

  • ubuntu-1 から curl https://blog.icttoracon.net/ をするとステータスコード200のレスポンスが返ってくる。
  • ubuntu-1 から curl http://[2403:bd80:c000:900::1]/ をするとステータスコード200のレスポンスが返ってくる。

配点  

  • ubuntu-1 から curl https://blog.icttoracon.net/ をするとステータスコード200のレスポンスが返ってくる
    • 80%
  • ubuntu-1 から curl http://[2403:bd80:c000:900::1]/ をするとステータスコード200のレスポンスが返ってくる
    • 20%

技術的な解説  

unbound と Apache2 の設定が適切になされていないことで起こる問題です。

unbound  

dns64-prefix は ubuntu-router の JOOL の設定を参照する必要があります。これを確認すると dns64-prefix が 64:ff9b::/96 で有ることがわかります。

また、blog.icttoracon.net ではデュアルスタック方式を採用しているおり dns64-synthall が no に設定されていると、blog.icttoracon.net にもともと設定されている IPv6 アドレスが AAAA レコードとして名前解決されるため、 ubuntu-1 からアクセスすることができなくなってしまいます。

さらに、この dns-1 のサーバーは NAT64 ネットワーク内に設置されているために forward-addr が 8.8.8.8 になっていると通信が行えません。forward-addr: 64:ff9b::808:808 に変更する必要があります。

Apache2  

IPv6 アドレスで Listen されていないので1行追記するだけです。

解答例  

問題が発生している原因は2つ存在している。1つ目は、unbound に DNS64 の設定が正しくされていない点である。これを解決するために /etc/unbound/unbound.conf.d/dns.conf を以下のように変更する。

server:
  verbosity: 2
  pidfile: "/var/run/unbound.pid"
  use-syslog: yes
  module-config: "dns64 iterator"
  dns64-prefix: 64:ff9b::/96
  dns64-synthall: yes
  interface: ::0
  access-control: ::0/0 allow
 
forward-zone:
  name: "."
  forward-addr: 64:ff9b::808:808

これにより https://blog.icttoracon.net/ にアクセスできるようになる。

2つ目の原因は ubuntu-router の Web (Apache2) の Listen Address が適切に設定されていないことにある。これを解決するために以下の一行を config に追記する。

Listen [::0]:80
 /
カテゴリー

問題回答ありがとうございました。 あまり聞きなれないVPNだったと思いますが、いかがでしたでしょうか。

問題文  

Router-CとRouter-DをスポークとしてハブルーターであるRouter-AとDM-VPNで接続してください。
ただし、Router-AとRouter-Bの既存の設定を上書きする変更もしくは削除しないでください。
また、Router-Dの配下にはネットワークが追加される可能性があるのでRouter-DはOSPFで経路を広報してください。
全てのサーバーがVPNを通して通信ができるようにそれぞれのルーターに追加した設定を回答に記入しそれぞれの設定を説明してください。
さらに、DM-VPNの構成要素であるIPSecでは通常、NAPTを使用する場合VPNを構築することはできません。 DM-VPNでNAT越しにVPNが構築できる方法・理由を報告してください。

初期状態  

  • Router-DがRouter-AとDM-VPNで接続していない
  • Router-CがRouter-AとDM-VPNで接続していない

終了状態  

  • Router-DがRouter-AとDM-VPNで接続している
  • Router-CがRouter-AとDM-VPNで接続している
  • Router-DとRouter-AがVPNを通してOSPFで経路交換をしている
  • 全てのServer同士がVPNを通して通信できる
  • Router-AとRouter-Bの既存の設定を上書きする変更もしくは削除していない

解説  

Router-AとRouter-Dに広報する経路が抜けいてるために追記します。 また、Router-DではOSPFで経路情報を広告していますが、DMVPNを使用している環境ではトンネルインターフェース に「ip ospf network broadcast」を入れないと全てのノードへ広告することができず、一部機器で経路情報が正常に同期できないという問題が発生してしまいます。
また、DMVPN環境ではハブルータが常にDRになるように「ip ospf priority 0」を入れる必要があります。
この二つの設定を行うことで正常にOSPFにて経路情報の交換ができるようになります。

Router-D・Router-Cでは、VPNの設定が入っていなかったり間違ったパラメータが設定されているため修正する必要がありました。

Router-CでのVPN内のルーティングに関しては特に指定していませんでしたがServer,同士で通信する必要があるため、OSPFを使用した解答例のconfigは以下の通りです。

Route-A
interface Tunnel1
 tunnel protection ipsec profile VPN
router ospf 1
network 192.168.1.0 0.0.0.31 area 0
network 192.168.1.32 0.0.0.31 area 0
Router-C
crypto isakmp policy 1
 encr aes 256
 hash sha512
 authentication pre-share
 group 2
 lifetime 21600
crypto isakmp key hoge address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 30
!
crypto ipsec transform-set IPSEC esp-aes esp-sha512-hmac 
 mode transport
!
crypto ipsec profile VPN
 set transform-set IPSEC 
!
interface Tunnel1
 no ip address
 ip address 192.168.1.2 255.255.255.224
 ip nhrp map 192.168.1.1 192.168.1.65
 ip nhrp map multicast 192.168.1.65
 ip nhrp network-id 1
 ip nhrp nhs 192.168.1.1
 ip ospf network broadcast
 ip ospf priority 0
 ip ospf mtu-ignore 
 tunnel source 192.168.1.98
 tunnel protection ipsec profile VPN
!
no ip route 192.168.1.0 255.255.255.0 192.168.1.97
!
ip route 192.168.1.64 255.255.255.224 192.168.1.97
!
router ospf 1
 network 192.168.1.0 0.0.0.31 area 0
 network 192.168.1.129 0.0.0.31 area 0

Router-D
interface Tunnel1
 tunnel protection ipsec profile VPN
 ip ospf network broadcast
 ip ospf priority 0
 ip ospf mtu-ignore 
 tunnel source 192.168.1.67
 
!
router ospf 1
 network 192.168.1.0 0.0.0.31 area 0
 network 192.168.1.160 0.0.0.31 area 0

また、NAT越しのDM-VPNについて、 IPsecをNAT越しに行うためにはNATトラバーサルが必要である。 NATトラバーサルはIKEを利用することで自動的に適応されます。 また、NHRPはIPsecトランスポートモードを使用したときにNAT パブリック アドレスを学習・使用できる。

採点基準  

  • Router-B,Router-Aで既存の設定が変更・削除されず、Router-D、Router-CがDM-VPNをRouter-Aとつなぐことができている:60%
  • Router-DとRouter-AでOSPFの経路交換ができており、全てのServer同士がVPNを経由して通信しあえる:  30%
  • NATを挟んだ状態でNATトラバーサルはIKEによって行われ、NHRPがNAT パブリック アドレスの学習・使用はIPsecトランスポートモードの時に動作することを理解している。:   10%