/

問題文


踏み台サーバのテストをするためにLinuxの機能を用いていろいろいじっていたところ、SSHが繋がらなくなってしまった。
どうやらVNCはそのまま繋がるようなので、原因を特定して繋がるようにしてほしい。

ゴール

  • SSHで接続できる

情報

  • IPアドレス: 192.168.0.10
  • ユーザー名: admin
  • パスワード: tWuVEsPiCLiP
  • VNCパスワード: tWuVEsPiCLiP

解説

/etc/hosts.deny によって他のホストからの接続が制限されていることが原因。

/etc/hosts.deny の中身を消すと接続できるようになる。 ncコマンドで確認しても見かけ上はopenになっているので注意。

/etc/hosts.allowでsshdや踏み台サーバのIPアドレスを許可することでSSHの接続を可能にする方法もある。ただし、IPアドレスで指定を行う場合は内部のネットワークアドレスである 192.168.0.10 を指定する必要がある。

VNCに接続する方法の一例としてsshやncコマンドを用いたポートフォワードが挙げられる。例えば下記のコマンドを実行すると、localhostの5901ポートにアクセスすることでVNCサーバーにつなげることができる。

ssh -L 5901:192.168.0.10:5901 ubuntu@[踏み台のIPアドレス]

 /

問題文  

自宅に置いてあるサーバ同士でOpenVPNを貼っていてある通信をOpenVPN越しにやりとりしていたのだが、 ある日突如通信ができなくなってしまった。この問題の原因を究明し、OpenVPNを利用して通信がまたできるようにしてほしい。

問題構成

  • OpenVPN Server:

    • OS: Ubuntu 18.04
    • SSH用IPアドレス: 192.168.0.10
    • SSHユーザ: admin
    • SSHパスワード: tP6xqe3f
    • パッケージ
      • OpenVPN 2.4.4
        • sudo systemctl status openvpn@server でデーモンの状態を確認できる
      • OpenSSL 1.1.1
      • PKI CAとして easyrsa3.0.6 を利用している
        • /easy-rsa-3.0.6 以下のディレクトリにある
        • CAのパスワードは ictsc-ca-pass で設定されている
  • OpenVPN Client:

    • OS: Vyos 1.1.8
    • SSH用IPアドレス: 192.168.0.20
    • SSHユーザ: admin
    • SSHパスワード: tP6xqe3g
  • 通信要件

    • OpenVPN Server/Client 共にeth1のインタフェースからトンネルを貼っている
    • OpenVPN Serverにはループバックインタフェース(172.25.0.1/32)があり、OpenVPN ClientはVPN越しにこのループバックのアドレスに通信ができること

問題のゴール状態  

OpenVPN ClientはVPN越しにこのOpenVPN Serverのループバックのアドレスに通信ができること

トラブルの概要  

証明書の期限が切れていて、通信ができなくなってる

解答例  

この問題ではまずなぜ通信ができなくなったかを確認する必要があります。 問題文には

ある日突如通信ができなくなってしまった

というところを見てヒントになったチームもあるかもしれません。 OpenVPN Serverの/var/log/openvpn/openvpn.logを参照すると下記のようなログが見えます。

Sun Jul 14 22:47:28 2019 192.168.200.20:57004 TLS: Initial packet from [AF_INET]192.168.200.20:57004, sid=672cf5a9 3ecb1b68
Sun Jul 14 22:47:28 2019 192.168.200.20:57004 VERIFY OK: depth=1, CN=Easy-RSA CA
Sun Jul 14 22:47:28 2019 192.168.200.20:57004 VERIFY ERROR: depth=0, error=certificate has expired: CN=vyos-user-4
Sun Jul 14 22:47:28 2019 192.168.200.20:57004 OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

error=certificate has expired

とあるのでこのログを見て、証明書の期限が切れたとわかります。

証明書の期限が切れているので、新しく証明書を発行しOpenVPN Serverに新しく証明書を登録します。

  1. OpenVPN Serverにログインする
  2. 以下のコマンドを打つ

cd /easy-rsa-3.0.6/easyrsa3 ./easyrsa build-client-full vyos-client-2 nopass ictsc-ca-pass

  1. OpenVPN Clientにログインする
  2. 以下のコマンドを打つ

scp admin@192.168.0.10:/easy-rsa-3.0.6/easyrsa3/pki/issued/vyos-client-2.crt ~/ scp admin@192.168.0.10:/easy-rsa-3.0.6/easyrsa3/pki/private/vyos-client-2.key ~/ cp * /config/auth/ configure set interfaces openvpn vtun0 tls cert-file /config/auth/vyos-client-2.crt set interfaces openvpn vtun0 tls key-file /config/auth/vyos-client-2.key commit

  1. ping 172.25.0.1 を打って疎通を確認する。通ればOK

 /

問題文

通常用セグメント 192.168.1.0/24 と、管理用セグメント 192.168.2.0/24 を持ったネットワーク上にいくつかのサーバがある。client1をこのネットワークに追加し設定したところ、client1とclient2間の通信が不安定になってしまった。192.168.1.0/24 のセグメントで正常に通信が行えるようにし、今後同じ状況にならないように設定を書き換えて、原因を報告してほしい。 管理用セグメント (192.168.2.0/24) からは正常にアクセスできるため、こちらからsshすること。

トポロジー図

トラブルの概要

本問題では動的割当のホストと静的割当のホストのIPアドレスが重複してしまい、通信が不安定になるトラブルでした。

解説

この問題はVyOSの設定のservice dhcp-server global-parameters ‘ping-check false;’という項目でDHCPによるアドレス割り当ての前にアドレスの使用状況を確認する動作が無効化されていたため、静的割り当てのホストと同じアドレスがDHCPによって払い出されていました。

解答例

VyOS

delete service dhcp-server global-parameters ‘ping-check false;’

Client(動的割り当て)

sudo dhclient -r

sudo dhclient

採点基準

  • 正常に通信を行えるかどうか
  • 原因を特定し、今後同じ状況にならないような設定にしているか

この二つを確認していました。

クライアントのどちらか片方のアドレスをnetplanで静的に書き換えても正常に通信はできますが、問題文に今後同じ状況にならないように設定してください。と記載されているため、DHCPの設定まで直して満点となります。

まとめ

IPアドレスの重複は簡単そうに見えて実際にトラブルに直面すると意外と気づきにくい所であり、DHCPの仕組みを理解していないとVyOSの誤設定に気づけない問題でした。

解答の設定の数もそれほど多くないのですぐ特定できた方は解決まで早かったのではないかと思います。

 /

問題文

社内のラボ環境でVyOSにサーバ、クライアントを接続し、相互にIPv6で通信できる環境を構築していた。
ある日VyOSの再起動を行ったところ、設定ファイルの保存を行っていなかったためVyOSの設定が消えてしまった。
 
VyOSを以下の要件に従って設定を行いクライアント-サーバ間で通信ができるように復旧し、管理者用アカウントを追加して欲しい。
また、今後同様の事象が発生しないように対策を講じること。

条件

  • eth0は踏み台接続用のインタフェースなので設定を変更してはならない
  • タイムゾーンはJSTに設定すること
  • VyOSに以下のアカウントを新しく追加し、デフォルトのアカウント (vyos ユーザ) は削除すること
    • ユーザー名: ictsc2019
    • パスワード: ictsc2019

ゴール

  • 上記の要件に従って設定を行いクライアント-サーバ間で通信ができる
  • 再起動をしても設定が消えないようにする

情報

VyOS

  • IPアドレス: 192.168.0.1
  • ユーザー名: vyos
  • パスワード: vyos

クライアント

  • IPアドレス: 192.168.0.2
  • ユーザー名: admin
  • パスワード: admin

補足

  • クライアントは、RAにより 2001:db8:2000::/64 のプレフィックスのアドレスが割り振られる
  • サーバは、2001:db8:1000::2/64 がインターフェースに割り振られており、ゲートウェイとして 2001:db8:1000::1 が指定されている

解説・解答例

条件・ゴール通りに一つずつ設定を行っていきましょう。

設定の投入方法

VyOSにアクセスした後、設定を変更可能なモードに移行するにはconfigureコマンドを実行しましょう。設定変更に関するコマンドはコンフィグレーションモードで行います。

$ configure
[edit]
#

eth1とeth2に適切な設定を投入

クライアントとサーバ側のインターフェースに適切な設定を投入しましょう。
トポロジ図を参照すると、クライアント側のインターフェースはeth1、サーバ側はeth2だという事が分かります。

eth0の設定

補足情報からクライアントには2001:db8:2000::/64のアドレスがRAで配布される事が分かります。VyOSのeth1にRAの設定を投入します。なお、インタフェースに割り当てるアドレスは2001:db8:2000::/64内のアドレスであれば、どんなアドレスにしても問題ありません。ここではEUI-64で自動生成しています。
以下のコマンドで設定します。

# set interfaces ethernet eth1 ipv6 address eui64 2001:db8:2000::/64
# set interfaces ethernet eth1 ipv6 router-advert send-advert true
# set interfaces ethernet eth1 ipv6 router-advert prefix 2001:db8:2000::/64
# commit

eth1の設定

補足情報からサーバのインタフェースは2001:db8:1000::2/64が静的に割り振られており、ゲートウェイとして2001:db8:1000::1が設定されていると分かります。
VyOSのeth2に2001:db8:1000::1/64を静的に設定しましょう。

# set interfaces ethernet eth2 address 2001:db8:1000::1/64
# commit

アカウントの追加と削除

デフォルトのvyos:vyosを削除し、管理用にictsc2019:ictsc2019のアカウントを追加します。
ログイン状態にあるアカウントを削除する事はできないので、先にアカウントの追加を行います。

# set system login user ictsc2019 authentication plaintext-password ictsc2019
# set system login user ictsc2019 level admin
# commit

一旦ログアウトして、ictsc2019ユーザでSSH接続します。
ログインできたらvyosユーザを削除して完了です。

# delete system login user vyos
# commit

タイムゾーンの設定

これはコマンド一発です。

# set system time-zone Asia/Tokyo
# commit

設定の保存

ここまで設定を終えて、クライアントからサーバへの疎通が取れる事を確認したら、設定を保存しておきましょう。
これもコマンド一発です。

# save
 /

問題名  

監視できない!

問題文  

あなたは新しくkubernetesのクラスタを構築しました。そして、クラスタの情報を取得するためにnotifierというアプリケーションを作りました。このアプリケーションは自身がデプロイされたクラスタのPodに関するイベントを外部のサーバにwebhookする機能を持っています。

さて、そのアプリケーションをデプロイしてRunningと表示されるのですが、なぜかイベントを見ることが出来ません。なんとかしてイベントを見れるようにしてください。

条件  

  1. notifierのイメージを変更してはいけない。
  2. notifierはkubernetesの内部に設置する必要がある。
  3. default namespaceに別のPodをデプロイする際に、デフォルトで権限を与えすぎないようにする必要がある。

ゴール  

miscサーバでlocalhostにcurlすると、最新のイベントが確認できる。

各マシンの説明  

k8s  

kubernetesが動作しているマシン。kubernetesの上ではnotifierが動作している。また、/manifestsにはnotifierをデプロイする際に使用したマニフェストが保存されている。

  • IPアドレス: 192.168.0.1
  • ユーザ名: admin
  • パスワード: kkkkkkkks

misc  

Docker Registryやwebappなどが動作しているマシン。

  • IPアドレス: 192.168.0.201
  • ユーザ名: admin
  • パスワード: kkkkkkkks

各アプリケーションの説明  

notifier  

kubernetes上で動作しているアプリケーション。kubernetesのPodリソースを監視し、作成, 変更, 削除があった場合には http://misc/webhook にイベント情報を飛ばす。

webapp  

misc上で動作しているWebhookを受け取るアプリケーション。notifierから受け取った最新10件のイベント情報を http://misc で公開している。

解説  

踏み台サーバを経由してmiscサーバに入りcurl http://miscを実行してみると、確かにログが1件も見えていないことが分かります。

その次に、k8sサーバに入りkubectl get podskubectl logs ${POD_NAME}等のコマンドでnotifierのログを見てみます。

条件にもある通り、default namespaceにデプロイされるコンテナに不必要な権限が与えられてしまってはいけないので、まず初めにnotifier用のService Accountを作成します。

notifierが新しく作成したService Accountを使用するようにDeploymentにも変更を加えます。

次に、このService Accountに対し、notifierで必要とされる権限を付与していきます。何度かlogを見ながら試行錯誤していくと、podsに対するlist権限とwatch権限が必要だと分かるので、その2つをnotifierに付与します

最後に想定回答を示します。