/

 

問題文

社内Networkの定期メンテナンス以降、Router(c1941)に対してVPN接続が出来なくなったため管轄である経路安定課に派遣されることとなった。

この部署では、定期メンテナンス以前からも他部署からVPNに接続すると、外部へのアクセスが出来なくなるとの苦情が寄せられているらしい。

今回のトラブルと同時にこちらのトラブルも含めて原因を特定し修正してほしい。

トラブルシュートするにあたり、configの修正点と修正したコマンドも合わせて報告し、部署内で情報共有できるよう努めてほしい。

トラブルの概要

  • VPNの設定ミスでVPNに接続できない
  • Cisco機器のVPN用仮想IFにNATの設定をしていない為、外部接続が出来ない

 

解説

この問題は社外から社内にVPNに接続する際のトラブルについての問題です。

問題文の「VPN」のキーワードを元にconfigを注視するとL2TP over IPSecを使用していることがわかります。

今回のこの問題でVPNが繋がらないトラブルに関しては原因が2つあります。

1つ目は、VPNの仮想IFを識別する為のIF番号が、VPNを使用する設定で定義したIF番号と異なっていることです。

2つ目は、VPNの接続を受け付ける為の設定[crypto map]がIFに適応されていないことです。

この2つの原因を発見し修正する事でVPNに繋がらないトラブルを解決できます。

VPNに接続するとWEB(外部Network)に接続できなくなるトラブルに関しては、VPNに接続する際に使用する仮想IFにNATの設定(ip nat inside)を設定していないことが原因となっています。

このトラブルを修正すると、3点のトラブルの原因をすべて修正したことになり、この問題のゴールであるVPNに接続した状態でのWEB(外部Network)接続が出来るようになります。

 

解答例

vpdn-group L2TP

accept-dialin
virtual-template 15

interface gigabitEthernet [参加者手元アクセス用 IF]
crypto map CRYPTO_MAP_L2TP

interface Virtual-Template15
ip nat inside

採点基準

  • VPNへの接続成功
  • 外部サイト(google,yahoo等)への接続成功
 /

問題文

Topology.png

我社では、社内で上記のトポロジーでマルチホーム接続を実施している。
だが、通信状況が良くないと社員から苦情がきたため、回線断の状況などを調べる目的で、新しく通信監視のサービスを自社に導入することが決定し、監視サービス提供事業者に依頼した。
監視サービス提供事業者の仕様としては以下の通りである。

最初にテストの設定をしてもらったが、内部からの通信の疎通は問題なく出来るにもかかわらず、一部のIPでは疎通が取れずにアラートが上がりっぱなしになるという現象が発生した。
その原因を突き止めてほしい :pray: 。

当該ISPとの通信ではuRPFが設定されており、また両方で利用されているネットワーク帯は異なる。
当社に存在する ネットワーク帯 は以下の通りである。

このうち、192.168.2.128/30192.168.2.132/30 はISPとの接続用でISPより提供されたIPであり、この組織が利用できるIP帯は 192.168.2.136/29 である。
ISP内ではISPではuRPF Loose modeと団体ごとの接続に利用しているBGPプロトコルでの経路フィルタが設定されている。

また、自社のコンピュータは192.168.2.0/25をNAPTを利用して接続している。

この問題では、当社が保有するCoreルータ以外の設定変更は不可能である。
また、広報する経路の設定は変更してはならない。

監視用サーバーはISP-A・ISP-B双方から疎通が可能であり、またISP・CORE間はBGPにて動的ルーティングが行われている。監視用サーバーのIPは現地店では開示されていない。
監視用サーバーの監視結果やその他必要な情報については問い合わせることで確認することが可能である。

注意

この問題は「外部から疎通ができない」というものであり、
内部からの疎通は全て成功する状態が正常である。
また、この問題のネットワークは他の問題のネットワーク、無線LANとの疎通性とインターネットへの対外疎通は存在しない。そのため、当問題のセグメント(192.168.2.0/24)以外には疎通不可能な状態が正常である。

制約

上流ルータ等、当該ルータ以外の設定変更はしてはならない。
BGPで広報する経路の設定は変更してはならない。
NATの変換IPを変更してはならない。
使用するネットワーク帯を変更してはならない。
クライアント側ネットワークを1つに集約してはならない。
この問題ではVRFを使用していないため、VRFを利用するネットワークを変更してはならない。

スタート

上記のように設定されたネットワーク帯とページ最上部に置かれたトポロジーで、インターフェイスにつけられたIPアドレスへの疎通が取れない
この設問では、サーバーはCore Loopbackに接続されているものとする

ゴール

Core Loopback、 ISP-A – Core、 ISP-B – Core のネットワークに所属していて実際にインターフェイスに割り当てがされている全てのIPとICMPによる疎通が外部から取れるようになる。
(Pingコマンドで疎通が確認できる)

情報

接続できるルータの情報は以下の通りである。

サブインターフェイスの数値に付与されているxはチームIDである。
例えばチームIDが30かつISP-A側インターフェイスの名前は GigabitEthernet 0.3010 となる。

トラブルの解説

この問題は、一部のインターネットサービスプロバイダー等で利用されるセキュリティ確保の方法の一つであるuRPF (Unicast Reverse Path Forwarding)に関する問題でした。

本来は自組織・相手組織を接続するネットワークは通信に使うためのものではないのですが、今回はそのIPに対して疎通確認を行なっており、どちらの回線が断絶したかを確認できるようにするという意図で問題が展開されていました。

uRPFとは
http://www.infraexpert.com/study/aclz22.html
このURLを見ていただくと理解ができるでしょう。

IPルーティングを行うルーターでは、パケット送出時にルーティングテーブルを確認します。

今回正常に接続ができていたLoopback IPへのパケットの送出手順は以下の通りとなります。

Topology.png

Coreルータのルーティングテーブル

ISP-Aルータのルーティングテーブル

ISP-Bルータのルーティングテーブル

Untitled Diagram (7).png
上記の図では行きと帰りの経路が異なる様に記述していますが、今回の場合はどちらのISPからパケットが来ても、どちらのISPに返しても正常な動作です。

これは、この組織が割り当てを受けている/29のIPを双方のルータから経路広告しているため、また割り当てられているIPのため経路フィルタをされることなく当該IPに対するアクセスが全て許可されるためです。

今回正常に接続ができなかったISP側インターフェイスへのパケットフローは以下の通りとなります。

Topology.png

Coreルータのルーティングテーブル

ISP-Aルータのルーティングテーブル

ISP-Bルータのルーティングテーブル

Untitled Diagram (8).png

当該ルータのルーティングテーブルをみて、デフォルトルートが向いている方のISPからISP-Coreのつなぎのインターフェイスには、発信パケットが同じISPを通るため正常にICMPパケットの返答が帰って来ます。

しかし、デフォルトルートが向いていない側のISPから着信した場合、そのパケットの送信元IPは通信が許可されていないが向いていない側のISPであるにもかかわらずデフォルトルートが向いている方のISPにパケットが送信されます。

CoreルータでICMPパケットが処理された後に、そのパケットの送出処理の際の出力インターフェイスはルーティングテーブルを参照した結果によるものであるからです。

今回は双方のISPで送信元IPがルーティングテーブルに乗っているかどうかを判断しパケットを送信するuRPFとBGPでの経路フィルタが設定されているため、デフォルトルートが向いていない側のISP側の送信元IPでデフォルトルートが向いている方のISPにパケットが送信された場合、ISP側ルータでパケットが破棄されます。

それにより、Ping疎通が不可能となっていました。

また、問題文として「経路フィルタを行なっている」ことから、CoreルータとISPを接続する線を経路広告しても疎通を取ることはできませんでした。

回答例

access-list 21 permit 192.168.2.128 0.0.0.3
access-list 22 permit 192.168.2.132 0.0.0.3

route-map REPLY-ISP permit 10
 match ip address 21
 set ip next-hop 192.168.2.129

route-map REPLY-ISP permit 20
 match ip address 22
 set ip next-hop 192.168.2.133

ip local policy route-map REPLY-ISP

パケット送信元のIPをベースに、ネクストホップ(パケット送信先インターフェイス)を変更することでこのトラブルの回避が可能になります。

採点基準

パケットが本来出力されるべきインターフェイスから出力されていないことを指摘できる(10%)
ルーティングポリシーの設定を追加する(80%)
設定を保存する(10%)

講評

問題の点数が高かったことと、問題名から滲み出る頭おかしい臭、また出題形式の都合で前の問題でブロックされていたことにより出題時間が短かったことによって、解答もチェック依頼も0件でした。問題内容くらいはちょろっと見てくれてたら良いなあと思いつつ、この解説を読んで「あー!なるほど!」ってなってくれる人がいると良いなと思っています。
この問題を見て「😔」してた人もいたのかな、相当意地悪な作りにしたのは申し訳ない限りです。

今回の問題で出題したuRPFについては、BCP38(Best Current Practice 38)で提唱されている、ISPレベルでの不正な通信(送信元IPなりすまし)のブロックにも用いられる技術で、最近のISPでも採用例が増えてきている技術です。「繋ぐ」技術だけではなく「繋がせない」技術にも目を向けてもらえればいいなと思い出題しました。

何はともあれありがとうございました、次回も運営をしていれば、もっと簡単な問題で会いましょう。

(追加補足) バックボーンの裏話

実はuRPFなんて大層なことを言っていますが、今回の問題環境で行なっていることは「BGP経路フィルタ」・「ACLによるアクセス制御」のみでした。ルーティングテーブルを参照する方法がうまく行かなかったため、同じ制御が行われた想定で通信を制御していました。
また、ブラフとしてLANを2つ用意したり、敢えてルーティングにBGPを利用、NAPTの必須化などで「Configを読むだけでは何を聞きたいかわからなくする」様な戦略を取り、また疎通のチェックをチーム内で行うことはできなくする、ISP側設定は聞くことができない等で参加者のみなさま、また運営の祭典担当の方々に大変なお手間をおかけする様な問題にしました。

 /

資料

 

問題文

社内インフラ管理をする部署に所属しているエンジニアがRouter(c1941)のメンテナンスをしていると潜在的なトラブルを発見した。

アクセスが出来なければいけない宛先[192.168.25.254]にRouterから疎通確認(ping)が出来ない。
しかし他部署からの苦情は寄せられておらず、PCをSwitch(2960B)に接続して確認してみると正常に疎通確認が出来ている。

現状は大きな問題にはなってはいないが、潜在的なトラブルを放置しては置けない。

だが、この潜在的なトラブルを発見したエンジニアは「明日から有給とるから後はよろしく!!」と言って退社してしまった。

そこで諸君にはこの潜在的なトラブルを修正しトラブルの原因と解決方法を報告して欲しい。

トラブルの概要

  • CBACの設定ミスによりRouterからの指定された宛先への疎通確認(ping)が出来ない。

解説

この問題はRouterにACL(deny any any)とCBACを使用してセキュリティの設定をした場合のトラブルです。

通常はクライアントが宛先となるIPに疎通確認(ping)が成功する場合は、それを中継しているRouterからも宛先に疎通確認(ping)が出来ます。

しかし今回はCBACの「Routerから発信するtrafficを無視する」という特性が働き、参加者のPCからの疎通確認(ping)の戻りのtrafficはCBACによって許可されますが、Router発信のtrafficが無視される為、Router発信の疎通確認(ping)の戻りのtrafficが許可されません。

この特性への対策としてCBACのコマンドのオプションに[router-traffic]を使用します。

このオプションを使用するとCBACがRouter発信のtrafficを無視しなくなり、Router発信の疎通確認(ping)に対しての戻りのtrafficが許可され疎通が出来るようになります。

解答例

ip inspect name ip-ipcp icmp router-traffic timeout 5

採点基準

  • Routerから指定された宛先への疎通確認成功
    ※想定回答(CBAC)以外の回答(ACLの編集)等での条件達成は+10点
 /

問題文

仮想機密伝送路課では、ルータの検証中に疎通が取れないトラブルにぶつかっており、現在在室している社員では解決できないらしい。
代わりにこの問題を解決し、社員に対して説明してほしい。
ただし、疎通先のルータは他部署が管理しているものであり設定を書き換えることができない。

トラブルの概要

この問題はciscoルータをブロードバンドルータとして使えるように設定する際に問題が発生したという設定であった。
configを読み解くと、一般的なISPで使用されるPPPoEを使用してWAN側のIPアドレスを取得し、ローカル側にはプライベートIPアドレスをDHCPで配布してNAPTを行うことで割り当てられた一つのアドレスでWAN側へ接続していることがわかる。

解説

この問題の場合PPPoEを利用しているため、NAPTのWAN側インターフェースはdialerであるのに対し、NATのoutsideが物理配線のインターフェースに設定されていた。
この個所を特定し、正しいconfigに書き換えることでISP側に設定したIPアドレスに対し疎通が取れるようになっていた。

解答例

ip nat inside source list 11 interface dialer 11 vrf vrf11 overload
interface Dialer 11
ip nat outside
exit
ip route vrf vrf11 0.0.0.0 0.0.0.0 dialer 11 permanent

採点基準

この問題は以下のポイントを押さえていれば部分点が与えられるようになっていた。

  • NAPTが原因であることを指摘できているかどうか
  • 正しく設定を変更しPCから指定のアドレスにpingで疎通を確認できる

講評

この問題を解くためには、参加者はPPPoEやNATに関する知識が必要な問題であった。
参加者の中には何度も関係のない解答を送ってきたチームもあったが、落ち着いて問題を切り分けることでより問題に気付きやすくなるだろう。
また、今回のコンテストで初めてPPPoEを知った参加者がいるのであれば、少し複雑ではあるが一般的な家庭とISPの間で接続を確立する手段としてよく利用されるプロトコルであるため、これを機に理解を深めるのもいいだろう。
本問題はコンテスト向けに一部の設定を省略しているため、本問題の状態で運用するとセキュリティ面などに問題がある。
そのため、実際に家庭に導入する際は正しくDNSやACLを設定しなければならない。

 /

問題文

この部署ではAS番号を持たない組織に対して、プロバイダのルータと組織内のルータの間に境界ルータを設置し、プロバイダのルータと境界ルータの間で双方向にStatic Routeを書くことで対応している。
ある組織は複数のIPアドレス(192.168.23.0/24)を持っており、組織内では独自でルーティングしている。
組織内では、割り当てられた中で使ってないIPアドレスがあり、その箇所に対しpingを行うと余計な帯域を食われてしまう問題が発生しているという苦情が届いた。
この問題に対して組織側のネットワークに影響が出ないようこの問題を解決し、原因を報告してほしい。

トラブルの概要

この問題はプロバイダ側が使用していないアドレス帯があることを想定しておらず双方向にStaticを書いたことで発生したトラブルであった。

解説

この問題はプロバイダ側が使用していないアドレス帯があることを想定しておらず双方向にStaticを書いたことで発生したトラブルであった。
この場合、未使用アドレス帯にパケットを投げた場合、組織内では、自身のルーティングテーブルに情報が乗っていないため、Default Routeである境界ルータに転送する。
境界ルータはStaticRouteより、プロバイダのルータにパケットを送るが、プロバイダは組織内のIPアドレスであると判断し境界ルータにパケットを送る。その結果、境界ルータとプロバイダのルータ間でループが発生しパケットのTTL倍の帯域を無駄に消費していた。
この問題を解決するためにはパケットを破棄するNullInterfaceを設定しNullRoutingの設定を行う必要があった。

解答例(一例)

ip route 192.168.23.128 255.255.255.128 Null 0

講評

この問題はPCからpingを実行した際のエラー文からループが発生していることを見抜けるかどうかを問う問題であった。
解答方法はチームごとに異なり、Nullを使用していない場合でも現状のネットワークに支障の出ないACLを書いているチームにも等しく点数を与えていた。
しかし、ACLを使用する場合既に書かれてある場合もあり導入が困難なケースや、設定次第で新たなトラブルの原因になりやすいため扱いには十分注意が必要である。
参加者の中にはdenyが一行書かれたACLを解答として送ってきたチームもあった。これでは全てのパケットが対外に出ることができなくなるため、暗黙のdenyに関する知識やaccess-listに関する理解を深める必要がある。
ルーティングプロトコルが集約されるときには常に、集約内のすべての IPアドレスに対するトラフィックをルータが受信する可能性がある。
しかし、すべてのIPアドレスが常に使用されているわけではないので、集約対象のトラフィックを受信するルータでデフォルトルートが使用されている場合にはパケットがループする危険性があるので注意する必要がある。

 /

問題文

我社では、新しい部署の開設に伴い新たなネットワークレンジを割り当てることになった。

担当者はメールで渡された情報に従ってコンフィグを作成し、新しく導入した機材に流し込んだ。
しかし、いざ設定してみると他部署のネットワークとの疎通が取れないことが分かった。
各担当者に問い合わせたが原因は特定できなかったという。

そこで、この問題を解決し、原因およびその根拠、また修正したコンフィグを報告してほしい。

担当者に送られたメール:

件名: ○○部署開設に伴うネットワーク情報まとめ

本文:
お疲れ様です。
○○部署で使うネットワーク情報についてのまとめです。
192.168.38.0/24、デフォゲは192.168.38.1
ipv6アドレスの割り当てなし。

新しく使うアドレス
192.168.39.0/24
ipv6アドレスの割り当てなし。

新しく導入した機材で192.168.38.39を介して192.168.39.0/24を接続し、RIPで社内LAN向けに経路情報を投げてください。

制約・情報

routerAの192.168.39.0/24のネットワークにPCを接続して192.168.37.1にPingが飛ぶように設定を修正してください。

PCは、2960Bのfa0/1に接続してください。

routerAは1941です、routerBは操作できません。
enable password : ZWKKEFzV

この問題に関係のあるIP及びvrfは192.168.37.0/24,192.168.38.0/24,192.168.39.0/24,vrf05です。それを除く他のIP,vrfは当問題とは関係ありません。

回答していただく項目は以下の通りです。

  • トラブルの原因とその根拠(使用したツールやコマンド等も明記して)
  • 修正したコンフィグ

問題のスタート

192.168.39.0/24に接続されたPCから192.168.37.1にPingが飛ばない

問題のゴール

問題を解決し、192.168.39.0/24に接続されたPCから192.168.37.1にPingが飛ぶように設定を修正する。

トラブルの概要

RIPのバージョン指定を忘れたときに経路情報は見えてるのにPCからPingが飛ばなくなる

解説

routerAではripのバージョンを指定せず、routerBのみripにversion2を指定した。

ciscoルーターの場合ripのバージョンを指定しなければversion1で動作するが、version2の経路情報も受け取るため、routerAでは192.168.37.0/24を受け取ることができる。しかしrouterBはversion2で固定しているため、version1の経路情報を受け取らない。

そのため、routerBには192.168.39.0/24が伝わらないため疎通が取れなくなる。

この問題はルーター2台のコンフィグを見比べて問題を特定することができない為、流れているパケットを読む(debugなど)必要がある。

routerAでdebug ip ripコマンドで自分はversion1をsend、相手からはversion2をreceiveしていることが分かる

手元のRIPのバージョンを2に変更すると正しく疎通できるようになる。

回答例

1941でdebug ip rip コマンドを使用したところ、手元がRIPv1、対向がRIPv2を使っていることが分かりました。

そこで
router rip
address-family ipv4 vrf vrf05
version 2
と入力したところ、PCから正しくPingが飛ぶことを確認しました。

最低限これだけの情報が書かれていたらOKです。

 /

どうも、作問者のnasuと言います。

問題文

今回ある学校のL2部分をalaxala製のL2SWで構築することになった。
そして回線障害、機器障害が起きても通信を問題なく行えるように、alaxalaの独自プロトコル(リングプロトコル、GSRP)で冗長化をする。
しかし検証環境で設定を入れて、ALA-CとALA-Bを繋いでいるケーブルの障害試験を行なった際に、正常に切り替わることができず検証用のホスト(192.168.19.200/26)へ一切疎通が取れなくなってしまった。
またコンソールにはたくさんのログが流れており、状況がつかめずにいる。
あなたは疎通が取れない原因の報告と、そして障害が起きた状態で疎通が出来るように対処をしてもらいたい。

制約

  • ALA-B,ALA-C,2960-B間は必ずgsrpを使った冗長設定、またALA-A,ALA-B,ALA-Cはリングプロトコルを使った冗長設定にしてください。プロトコルを使わないという解答は点数になりません。

トラブルの概要

  • 両方のスイッチのgsrpにno-neighbor-to-master direct-downと設定が入っている為、障害時に両方のスイッチがお互いに障害が発生したと判断してパケットが両方のスイッチでフォワードされるようになり無限ループする構成となってしまった
  • リングプロトコルのhealth-checkの値が間違っている

解説

ALA-B,ALA-Cでつながっているインターフェースはgsrp-directlinkになっており、gsrpの切り替えがno-neighbor-to-master direct-downと設定されている為、障害時お互いがお互いに障害が起きたと判断して2台ともマスター状態で動いているためブロードキャストストームが起きた為パケットが正常に飛ばなくなるということです。
またringプロトコルのヘルスチェックの送信間隔時間及び保護時間が間違っている為

解答例

ALA-B,ALA-Cをどちらかのgsrpの設定をno-neighbor-to-master direct-downと設定しgsrpをリスタートさせることで片方がバックアップとなりパケットを流さなくなります。
これによってpingが正常に飛ぶようになります。
ALA-B or ALA-C

ena
conf t
gsrp 1
no-neighbor-to-master manual
exit
exit
restart gsrp

またリングプロトコルのヘルスチェックの値に不備がある為これもパケットがおかしくなるという言及、及び設定変更
ALA-A

enable
conf ter
axrp 1
health-check interval 500
health-check holdtime 1600

採点基準

pingが届くだけならgsrpの設定のみで済むので以下の配点となっています
1. gsrpの挙動への言及とgsrpの設定変更をしpingが正常に飛ぶ → 基準点
2. gsrpの解答をした上でaxrpのヘルスチェックの値に不備があることへの言及及び設定変更 → 満点

講評

先に講評から
15チーム中5チームからの解答があり4チームが基準点を突破しそのうち1チームが満点でした。
また満点のチームは外部のドキュメントを引用して何が起きているかの言及、また設定変更の手順を1つずつ丁寧に説明せれており芸術点も追加されています。
さて学生のみなさんはRS232cを使うネットワーク機器を扱ったことはありますでしょうか?
初めて見る学生さんは「なんだこのコンソールポートの口は?」と驚いたかもしれません
最近では比較的rj45を使う機器しか見ないと思いますが、ベンダーによってはちらちらと出しているところを私は見ます。
世間のネットワーク機器はcisco以外にもあらゆるベンダーで構成されています。
そして一度も触ったことがないのに突如上司から「ネットにドキュメントがあるから読んでやって」というのも大人の世界ではあるかもしれません(私のバイト先ではありました。)
今回出したalalaxaはコマンド体系がシスコライクなので学生でもcisco機器を勉強していれば、そこまで扱うのにはそこまで難しくないと思われます。
今回cisco以外の機器を触って「あ、おもしろいな」って思った学生のみなさんはこれを機にあらゆるのベンダーのネットワーク機器に触れてみるのもいいかもしれません。
次回も”出来ればですが”cisco以外のネットワーク機器を使った問題を作ってみたいと考えていますので楽しみにしてください。(確実に出るという保証は無いorz)

 /

問題文

社内にVyOSを導入することが決まった。
そこで、社内のインフラを構築する前に以下の図の様なテスト環境で検証を行った。
VyOSにDNSのキャッシュサーバとDHCPサーバを起動し、下に接続されているUbuntuにIPアドレスを割り当てた。
しかし、Ubuntuから外部のサーバにアクセスしようとしたが接続できずICMPを送っても応答がない。ところが、VyOSからICMPを外部のサーバに送ると応答が返ってくる。
なので、Ubuntuから外にアクセスできる様に解決してほしい。ただし、Ubuntuに直接接続することはできず、VyOSからはアクセスできるようになっている。

スタート

  • Ubuntuから外部のサーバにアクセスできない
  • VyOSからはアクセスが可能

ゴール

  • Ubuntuから外部にアクセスできる

情報

サーバ IP アドレス アカウント パスワード
vyos 192.168.20.80 admin PxZsMqycN4a4nzlk1Xg7
client 192.168.20.2 admin kopvVL3cT2tkALu4nQnD

トラブルの概要

この問題ではVyOSがNATをして下に接続されているUbuntu Server(以下clientとする)が外とアクセスできるような構成になっていました。しかし、何らかトラブルでclientが外と全く疎通が取れない状態でした。VyOSから8.8.8.8にpingをすると応答が帰ってくるという状態でした。

解説

問題文を読んだだけで大抵の人はVyOS側に問題があることに気づいたかと思われます。答えはVyOSのNATの設定に不備がありclientが外に繋げられなかったということです。

解答例

NATの設定を確認するためにshow natを打つと以下のように表示されます。

nat {
source {
rule 1 {
outbound-interface eth1
source {
address 192.168.20.0/26
}
translation {
address masquerade
}
}
}
}

今回の場合、VyOSが対外に接続しているインターフェースはeth0なのにoutbound-interface eth1となっています。これが原因な訳でこれを消すか上書きしてあげることで疎通が取れるようになるはずです。以下のような手順で上書きをしてみます。

# set nat source rule 1 outbound-interface eth0
# commit
# save

この後に8.8.8.8に対してpingをすると以下のように接続できていることがわかります。

$ 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=61 time=12.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=11.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=61 time=10.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=61 time=9.57 ms

採点基準

  • 外部に疎通できないことを指摘
  • 解決方法の提示
  • そのあとに疎通できることを提示

講評

この問題はウォームアップ問題として作成しました。なのでほとんどのチームが解答してくれました。実はVyOSは一回も触ったことがありませんでした。だそうにも難しくすることができないので実際に自分がミスしたところを出せばいいのではと思い出題しました。

 /

問題文

以下の図のようなDMZとLOCALの2つの空間が接続されている内部向けDNSサーバと、外部向けのwebサーバがあり、webサーバは8000番で待ち受けている。
LOCALからそのwebサーバの8000番に対しFQDNでアクセスしても表示されないと社内の各所から連絡があった。

そのため、内部からwebサーバにFQDNでアクセスできる様に解決してほしい。
ただし、既に構築してあるこのDNSサーバを使い、FQDNで正常にアクセスできることを証明してほしい。

制約

この問題での制約は問題文で指示されている通り、図にあるdns-serverを必ず使用することです。

スタート地点

  • DNSの問い合わせができない

ゴール地点

  • DNSの問い合わせができる
  • 正常に問い合わせができているかをコマンドを使用して証明する
  • 健全なDNSサーバを構築する

必要情報

  • ドメイン: ictsc.local
  • ホスト:
  • web-server: www.ictsc.local
  • dns-server: dns.ictsc.local

情報

サーバ IP アドレス アカウント パスワード
dns 192.168.4.70 admin e4EYoNiTlII4zEE7udxG
web 192.168.4.71 admin Eaa4mXBsgygxag934x3H

トラブルの概要

図のように各サーバは2つのNICをもちそれぞれDMZとLOCALに接続されていました。トラブルの概要としてLOCAL側からdns-serverに対して名前解決の問い合わせをしてもドメインと紐づけられているIPアドレスが帰ってこないというものでした。

解説

このトラブルは/etc/bind/以下にDMZとLOCALの空間から名前解決できるように定義されたzoneファイルが不適切のため発生していました。それがこの4つのファイルです。

  • 0.4.168.192.in-addr.arpa
  • 64.4.168.192.in-addr.arpa
  • ictsc.local-0.zone
  • ictsc.local-64.zone

トラブルの原因としてこの4つのファイル全てに共通して以下の3つがありました。

  • SOAレコードを定義する箇所で最初の@が抜けている
  • SOAレコードのhostmaster-emailの最後に.がついていない
  • SOAレコードを括弧で囲むときに最後が)ではなく}となっている

問題の初期状態は以上の3つが原因でDMZとLOCALから名前解決ができませんでした。なので適切な状態に書き直して名前解決ができることを提示すると基準点となります。満点にするためにはゴール地点に記載した通り健全なDNSサーバを構築するまで行うことです。実はこのdns-serverはDMZからictsc.local以外の名前解決をしてしまいます。つまりオープンリゾルバ状態でした。なので外部からはictsc.local以外は受け付けないように設定を変更する必要があります。それには以下のファイルを書き換える必要があります。

  • named.conf.default-zones

解答例

まず、/etc/bind/以下の0.4.168.192.in-addr.arpaを書き換えます。これはDMZの空間からの逆引きを解決するためのファイルです。

$TTL 3600
IN SOA dns.ictsc.local. root.ictsc.local (
2018022400
3600
900
604800
86400
}

IN NS dns.ictsc.local.
10 IN PTR dns.ictsc.local.
11 IN PTR www.ictsc.local.

これを先ほど指摘した3つの原因を以下のように修正します。

$TTL 3600
@ IN SOA dns.ictsc.local. root.ictsc.local. (
2018022400
3600
900
604800
86400
)

IN NS dns.ictsc.local.
10 IN PTR dns.ictsc.local.
11 IN PTR www.ictsc.local.

これを他のファイルも同様に修正し、サービスの再起動を行うことで名前解決ができるようになります。
次にオープンリゾルバを解決するためにnamed.conf.default-zonesを修正します。このファイルの中にinternalexternalのゾーンによって読み込むファイルを記述している箇所があります。そこにmatch-clientsを追加して適切な空間を記述することでオープンリゾルバを回避することができます。

採点基準

  • 上記のトラブルを指摘
  • 対策後にちゃんと名前解決ができていることを提示
  • オープンリゾルバとして動作してしまっているのでそれを指摘して対処(加点対象)

講評

この問題はウォームアップ問題として作成しましたが実際に解答を送ってくれたチームは半分ぐらいで想定と違う結果となり驚きました。その中でもちゃんと最後まで解けていたのは1チームのみでした。

 /
カテゴリー

問題文

電子通信網局 特殊物理装置課から構築中のトラブルを解決して欲しいと依頼が届いた。
社内IoTシステムの開発のためRaspberryPiにRaspbianをインストールしたが、SSH接続ができず何もセットアップができない状態らしい。
尚、初めからSSHを用いてセットアップを行う予定だったためディスプレイやキーボードは用意されていないようが、なんとかしてセットアップを完了させてほしい。

スタート

RaspberryPiにRaspbianをインストールした直後の状態

ゴール

指定されたIPアドレスがRaspberryPiに振られており、SSHでアクセスできる。

情報

  • 指定されたIPアドレス 192.168.0.88
  • ネットワーク・アドレス 192.168.0.0/24
  • デフォルトゲートウェイ 192.168.0.254
  • DNSサーバー 8.8.8.8
  • ユーザー pi
  • パスワード raspberry
  • イメージ 2017-11-29-raspbian-stretch-lite

トラブルの概要

Raspbian は 2016/11/25 以降のイメージではデフォルトでsshが無効化されていて、有効化するためには何らかの方法を取る必要がある。
Raspbian では、IPアドレスを固定する際に編集するファイルが、 /etc/network/interfaces から /etc/dhcpcd.conf に変更された。

解説

Raspbian では以下のいずれかの方法によって ssh を有効化する必要がある。

  • /boot パーティションに ssh という名前の空のファイルを設置してから電源を入れてブートを始める。
  • Raspbian の Linux ファイルシステムを手元のPCにマウントして、 /etc/rc.d などに起動時にsshを有効化するスクリプトを作成する。
  • UART などの何らかの方法でコンソールにアクセスして raspi-config からsshを有効化する、もしくは $ systemctl start ssh ($ systemctl enable ssh) を実行してsshを有効化する。

また、IPアドレスを固定するために /etd/dhcpcd.conf にIPアドレスの設定を追記する。

解答例

お疲れ様です。運営委員の源波です。「アップルパイが完成しない!」問題の作業報告を提出いたします。

まず、一度 Raspberry Pi の電源を抜いてから、Raspberry Pi に挿入されていたSDカードを手元のノートパソコンにマウントします。dfコマンドの結果、 /boot パーティションは手元PCの /Volumes/boot にマウントされていることがわかったので次のコマンドで空のsshというファイルを作成します。$ touch /Volumes/boot/ssh lsコマンドで正常にファイルが作成されていることを確認してから、SDカードを手元からアンマウントし、Raspberry Pi に挿入し直してから電源ケーブルを再度差し込みます。

これで Raspberry Pi のsshが有効化されたので、次にDHCPによって割り振られているアドレスを特定します。Raspberry Pi と同じLANに属しているインターフェイスを対象として、arp-scanコマンドを実行します。 $ arp-scan --interface en0 -l
Raspberry Pi に割り振られているIPアドレスが 192.168.0.8 であることがわかったので、sshで接続します。 $ ssh pi@192.168.0.8 sshで接続できたら、IPアドレスを固定するために、/etc/dhcpcd.conf に以下の設定を追記しました。

interface eth0
static ip_address=192.168.0.88/24
static routers=192.168.0.254
static domain_name_servers=8.8.8.8

networking を再起動して、変更を完了します。$ sudo systemctl restart networking

これでIPアドレスが固定されます。$ ssh pi@192.168.0.88

以上が作業報告になります。よろしくお願いします。

採点基準

採点の基準として、sshの有効化とIPアドレスの固定で、それぞれ50%を想定していましたが、どちらかしかできていないチームはなかった。IPアドレスの固定については、現在でも /etc/network/interfaces の編集による設定でも変更が可能であるが、/etc/network/interfaces の中には、/etc/dhcpcd.conf を編集しろという旨の記述がコメントアウトされており、そちらのほうが妥当であると考え、/etc/network/interfaces を編集していたチームには満点より10点低い点数をつけた。

最近のコメント