/
カテゴリー

問題文  

概要  

あなたが働く株式会社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

参考文献  

 /
カテゴリー

問題文  

概要  

おお久しぶり!!

君が居ないあいだに社内ネットワークを 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%
 /
カテゴリー

以前、あるイベントで回線契約をして、もらった接続情報を元にルータを設定しようとした時に遭遇したトラブルを今回出題しました。

問題文  

問題文は以下の通りです。

network.png
あなたはある企業の情報システム部に所属しています。上司から「今の回線遅いから新しいのに変えといて」と言われたため、Aさんが新しくプロバイダと契約し、上に記載した/32のIPアドレスとPPPoEの接続情報をもらいました。Aさんはその接続情報を元に`CSR_client`にPPPoEとNATの設定を行なったんですが、上の図の`ubuntu`から外部のwebサービスを利用しようと思ったけど繋がりませんでした。`CSR_client`で接続を確認したところPPPoEのセッションは張れていることが確認できたんですが、依然として外部のサービスを利用できません。Aさんの代わりにこの原因を突き止め解決してほしいです。

初期状態と終了状態  

初期状態  

  • ubuntuから外部ネットワークに繋がらない

終了状態  

  • ubuntuから外部ネットワークに繋がる

解説  

今回発生していた問題はインターフェースの設定にありました。 プロバイダから受け取った/32のIPアドレスはGigabitEthernetに設定できません。そのため、/32のIPアドレスを設定できるLoopbackを用いる必要があります。 初期状態で不足している、または間違っているコンフィグは以下の3つです

  1. Loopbackのインターフェースがない
  2. ip nat ousideがDialerに設定されていない
  3. NAPTの設定が間違っている(1.に起因するもの)

CSR-clientの初期状態は以下のコンフィグになっていました。

interface GigabitEthernet1
 no ip address
 ip nat outside
 duplex auto
 speed auto
 pppoe enable
 pppoe-client dial-pool-number 1
!         
interface GigabitEthernet2
 192.168.51.254 255.255.255.0
 ip nat inside
 duplex auto
 speed auto
!
interface Vlan1
 no ip address
!
interface Dialer1
 no ip address
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 ppp authentication chap callin
 ppp chap hostname XXXXXXXXXXXXXXXXXXX
 ppp chap password 0 XXXXXXXXXXXXXXXXX
!
ip nat inside source list 1 interface GigabitEthernet1 overload

上記の問題を解決したコンフィグが以下の通りです。

interface Loopback0
 ip address xxx.xxx.xxx.xxx 255.255.255.255
 !
!
interface GigabitEthernet1
 no ip address
 ip virtual-reassembly
 duplex auto
 speed auto
 pppoe enable group global
 pppoe-client dial-pool-number 1
 !
!         
interface GigabitEthernet2
 ip address 192.168.51.254 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 duplex auto
 speed auto
 !
!
interface Dialer1
 ip unnumbered Loopback0
 ip nat outside
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 ppp authentication chap callin
 ppp chap hostname XXXXXXXXXXXXXXXXXXX
 ppp chap password 0 XXXXXXXXXXXXXXXXX
!
ip forward-protocol nd
!
ip http server
no ip http secure-server
!
ip nat inside source list 1 interface Loopback0 overload
ip route 0.0.0.0 0.0.0.0 Dialer1
!
access-list 1 permit any
ping_result.png

このコンフィグを入れてubuntuからpingを8.8.8.8に送ると以下のように通ってることが確認できます。 

採点基準  

  • Loopbackを用いて/32のipを設定している(10%)
  • GigabitEthernet1からip nat outsideが外れている(10%)
  • ip unnumberd loopbackがdialerに設定されている(20%)
  • ip nat outsideがDialerに設定されている(10%)
  • ip nat inside source list list-number interface loopback list-number overload が設定されている(20%)
  • ubuntuから1.1.1.1などの外部サービスにpingが通る(30%)

講評  

お詫び  

あるチームで展開に失敗している環境がありました。環境の不備をお詫びします。

解答について  

みなさんIPアドレスを設定する時に、Dialerに/31を設定しているチームがありました。しかし、問題文にもらった接続情報を使って設定してくださいと明記していなかったため、そのように設定しているチームは点数を与えました。

15チーム中、12チームが解答し満点は6チームでした。難易度的には適切だったのかなと思います。