/

問題文

通信事業者である「Ictsc Fiber」では最近、MP‐BGPの検証を行っています。 今日も、Loopbackを用いてピアを張り、ルート共有を行う検証を同僚が行っていました。 ですが、上手くピアを張ることができずあなたに助けを求めに来ました。 原因を究明して解決し、正常にピアを張ってください。またピアを張った後に、図に示す「1841-A」の「Loopback 1」のルート共有を行ってください。

トラブルの概要

MP-BGPの設定を行い、Loopback間でピアを張ろうとしたが上手く張れません。以下の図に示す「C1941」と「1841-A」に設定を追記し、ピアを正常に張れるようにしてください。 また、1841-Aの「Loopback 1」のルート情報を共有し、C1941から1841-Aの「Loopback 1」へ疎通可能にしてください。

解説

今回の問題では、MP-BGPと呼ばれる技術を用いてルータ間でのIPv6ルートの共有を行おうとしています。 MP-BGPとは正式名称で「Multi Protocol BGP」と呼ばれ、Ipv4以外のプロトコルに対応しています。そのため、IPv6プロトコルを使用することができます。MP-BGPでも、ピアを確立しルート共有を行うという順番は変わりません。

MP-BGPでEBGPピアを張る際には、BGPと同じ様にEBGP Neighborの設定が必要になります。また、BGPと違ってaddress familyと呼ばれる設定をする必要があります。今回は以下の設定がそれぞれの機器に行われていました。

  • C1941
  router bgp 1
  no bgp default ipv4-unicast
  bgp router-id 1.1.1.1
  neighbor fd00:173::1 remote-as 2
  address-family ipv6 unicast
  neighbor fd00:173::1 activate
  • 1841-A
router bgp 2
  no bgp default ipv4-unicast
  bgp router-id 2.2.2.2
  neighbor fd00:172::1 remote-as 1
  address-family ipv6 unicast
  neighbor fd00:172::1 activate

物理インタフェースを用いるのであれば、これらの設定でピアを張ることができます。


ですが、今回の問題はLoopbackを用いてピアを張る必要があるため、追加で設定を加える必要があります。 実際に追加する必要がある設定は以下になります。

  • C1941
ipv6 route fd00:173::/64 fd00:171::2
neighbor fd00:173::1 update-source loopback 0
neighbor fd00:173::1 ebgp-multihop 2
  • 1841-A
ipv6 route fd00:172::/64 fd00:171::1
neighbor fd00:172::1 update-source loopback 0
neighbor fd00:172::1 ebgp-multihop 2

各機器に設定する項目は同じです。これらの設定を加えることでLoopback間でピアを張ることができます。 追加設定の内容について説明していきます。

ipv6 route ipv6_network_address nexthop

この設定は、IPv6でのスタティックルートを追加するものです。EBGPピアを張る際は、ピアの宛先のアドレスに疎通性がないと張ることが出来ません。初期の設定のままでは、疎通性がないためスタティックルートを追加する必要があります。

neighbor ipv6_network_address update-source loopback 0

ピアを張る際に送るメッセージを送る送信元は、デフォルトでは物理インターフェースに指定されているためLoopback 0 間でピアを張ることができません。そのため、送信元をLoopback 0に指定する必要があります。

neighbor ipv6_network_address ebgp-multihop 2

EBGPピアを張る際の送るメッセージのTTL(Time to Live)はデフォルトで「1」に設定されています。そのため、Loopbackを用いてピアを張る場合、TTLが1より大きくなってしまうためパケットが捨てられてしまいメッセージが宛先に届きません。そのため、この設定によってTTLの数を増やす必要があります。因みに、最後の値の部分を指定しないと、「255」に設定されます。

以上の設定によって、ピアを張ることができます。


さらに、今回の問題では、ピアを張ることが出来たら1841-Aの「Loopback 1」のネットワークをMP-BGPによって共有を行うという指定がありました。それを踏まえてルート共有を行う設定は以下のとおりです。

  • 1841-A
router bgp 2
 address-family ipv6 unicast
 network fd00:174::/64

この設定を行うとMP-BGPでのルート共有が行われます。

回答例

  • C1941
ipv6 route fd00:173::/64 fd00:171::2
router bgp 1
 neighbor fd00:173::1 update-source loopback 0
 neighbor fd00:173::1 ebgp-multihop 2
  • 1841-A
ipv6 route fd00:172::/64 fd00:171::1
router bgp 2
 neighbor fd00:172::1 update-source loopback 0
 neighbor fd00:172::1 ebgp-multihop 2
 address-family ipv6 unicast
 network fd00:174::/64

採点基準

  • 各ルータのLoopback 0に向けてIPv6でのstatic routeが設定されている(30%)
  • neighborを張る送信元をそれぞれの Loopback 0に設定した(60%)
  • ebgp-multihopを2以上に設定している(90%)
  • BGPによって受け取ったルート情報でR1からR2のloopback 1に疎通性が取れる(100%)
 /

問題文

あなたの部署では IPv6 のネットワークを使用しており、ルータ以下に fd00:10::/64fd00:11::/64 の2つのサブネットがあり、それぞれのサブネットに端末がある。fd00:10::/64 には端末1が存在し fd00:11::/64 には端末2が存在している。

fd00:11::/64 のサブネットでは今まで静的に IPv6 アドレスを割り当てていたが、自動的な割り当てに切り替えることになった。ところが、切り替え作業時にオペレーションミスが発生してしまい、端末2が IPv6 アドレスを失ってしまったらしく、端末1から端末2へアクセスできなくなってしまった。

この状態から切り替え作業を完了させ、端末2に fd00:11::/64 の IPv6 アドレスを自動的に割り当てて端末1からアクセスできるようにしてほしい。なお端末2のアドレスとしては fd00:11::100 - fd00:11::199 の範囲のみが使用を許可されている。

情報

ルータ

IPアドレス: 192.168.10.1
ユーザー: admin
パスワード: w4HcAsJS

端末1

IPアドレス: fd00:10::2
ユーザー: admin
パスワード: w4HcAsJS

ルータからアクセスすることが可能です。

端末2

ユーザー: admin
パスワード: w4HcAsJS

構成

10_ryo_image.png

トラブルの概要

  • 端末2に静的に割り当てていた IPv6 アドレスが消えている
  • DHCPv6 の設定が入っていない

解説・解答例

まず、問題文を読めば以下の事項が要求されているとわかります。

  1. サーバ2に自動的にIPv6アドレスを割り当てる
  2. 自動的に割り当てるIPV6アドレスは fd00:11::100 - fd00:11::199 でなければならない

IPv4であれば、自動的にアドレスを割り当てる場合にはDHCPを利用します。一方でIPv6アドレスを自動的に割り当てる方法としては以下の二つがあります。

  1. Router Advertisement (RA) を利用したステートレス自動割り当て
  2. DHCPv6 を利用したステートフル自動割り当て

ステートレス自動割り当てではサーバがルータからRAというメッセージを受け取り、RAで配布された情報とサーバのインターフェースのMACアドレスを組み合わせてIPv6アドレスを生成します。そのため、特定の範囲内のアドレスを使わせることが不可能です。したがってDHCPv6を使わなければならないことがわかります。

そこでルータの fd00:11::/64 のインターフェースにDHCPv6の設定を行いましょう。

まずはルータにsshします。

$ ssh admin@192.168.10.1
Welcome to VyOS

sshの際にルータがVyOS であることがわかります。VyOS のコマンドで設定していきましょう。

$ show conf
ethernet eth2 {
address fd00:11::1/64
duplex auto
smp_affinity auto
speed auto
}

コンフィグを見るとeth2fd00:11::/64のインターフェースだとわかります。

$ conf
$ set service dhcpv6-server
$ set service dhcpv6-server shared-network-name eth2 subnet fd00:11::/64 address-range start fd00:11::100 stop fd00:11::199
$ edit interfaces ethernet eth2
$ set ipv6 router-advert send-advert true
$ set ipv6 router-advert managed-flag true
$ set ipv6 router-advert other-config-flag true
$ exit
$ commit; save

address-rangeでIPv6アドレスの範囲を指定します。これは、問題文に指定されている通り fd00:11::100 - fd00:11::199 にしましょう。

またeth2においてRAを有効にします。これは、DHCPv6による割り当てを使う場合でもまずはサーバがルータからRAを受け取る必要があるからです。DHCPv6でIPv6アドレスを配布するにはさらにmanaged-flagを有効にする必要があります。other-config-flagはDHCPv6サーバでネームサーバなどの情報を配布するかどうかのオプションであるため、ここでは有効にしていますが、無効でも良いです。なお VyOS ではother-config-flagに関わらず、デフォルトゲートウェイがRAを配布したインターフェースに設定されるようです。

さて、これでサーバ2にアドレスが割り振られるはずなので見てみましょう。以下のコマンドで割り当てられてい DHCPv6アドレスを確認することができます。

$ show dhcpv6 server leases
There are no DHCPv6 leases.

ところが、予想に反して、割り当てられているIPv6アドレスがありません。ルータとサーバ2の間に何らかのトラブルが発生していることが想定されます。サーバ2にsshしてトラブルシューティングを行いたいところです。しかし「サーバ2が IPv6 アドレスを失ってしまったらしく、サーバ1からサーバ2へアクセスできなくなってしまった」とあるように、サーバ2に割り当てられていた静的なIPv6アドレスは失われてしまっています。

ここで、IPv6のリンクローカルアドレスを使います。IPv6が有効になっている全てのインターフェースには、MACアドレスから自動生成されたリンクローカルアドレスが割り当てられています。これは、その名の通り同じL2にいるインターフェース同士の通信に使用することができます。したがって、ルータからであればサーバ2のリンクローカルアドレスにアクセスすることができます。

サーバ2のリンクローカルアドレスはわからないので探しましょう。そのためには、IPv6のマルチキャストが有効です。IPv6にはリンクローカルなマルチキャストアドレスがあらかじめいくつか定義されており、同じL2に存在する特定の種類のインターフェース全てに通信することができます。ここでは、リンクローカルな全てのノードのアドレスを調べるためにeth2からff02::1に ping します。

$ ping6 -I eth2 ff02::1

これを実行すると1つ以上のインターフェースから応答があるはずです。なお、一度通信したことのあるインターフェースのアドレスは以下のコマンドでも調べられます。RAを有効にした後であれば、上記のpingのマルチキャストを行わなくても複数のインターフェースを見つけられるかもしれません。

$ show ipv6 neigh

ここまででサーバ2のインターフェースの候補がわかるはずなので、あとは地道にsshを試していきます。与えられたユーザとパスワードでログインできるのがサーバ2です。なお、リンクローカルアドレスにsshするときはアドレスの末尾に%eth2を追記して、インターフェースを明示する必要があります。

$ ssh admin@{{link local address}}%eth2
Welcome to Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-45-generic x86_64)

ログインに成功するとUbuntu 18.04であることがわかります。iproute2のコマンドでインターフェースを見ると、アドレスが振られていないのがわかります。

$ 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 52:54:5e:e0:21:7e brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:5eff:fee0:217e/64 scope link
valid_lft forever preferred_lft forever

Ubuntu 18.04ではネットワークインターフェースの管理にNetplanというソフトウェアを使っています。設定ファイルは/etc/netplan/以下にあります。今回は/etc/netplan/99-network-config.yamlが存在し、以下のように書かれています。

network:
version: 2
ethernets:
eth0:
dhcp4: false
accept-ra: false
gateway6: fd00:11::1

ここからRAが無効になっているとわかります。これではDHCPv6によるアドレス割り当てを行うことができません。そこで、RAとDHCPv6を有効にします。また、ゲートウェイはRAによって設定されるので、静的な設定は消してしまいます。

network:
version: 2
ethernets:
eth0:
dhcp4: false
dhcp6: true
accept-ra: true

書き換えて保存したら、以下のコマンドで設定を反映させます。

$ sudo netplan apply

すると今度はDHCPv6によって割り当てられたアドレスが確認できるはずです。

$ 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 52:54:5e:e0:21:7e brd ff:ff:ff:ff:ff:ff
inet6 fd00:11::199/128 scope global dynamic noprefixroute
valid_lft 43196sec preferred_lft 26996sec
inet6 fe80::5054:5eff:fee0:217e/64 scope link
valid_lft forever preferred_lft forever

問題が解決したかどうか確かめるために、サーバ1からこのアドレスにpingしてみましょう。

$ ssh admin@fd00:10::2
$ ping fd00:11::199
PING fd00:11::199(fd00:11::199) 56 data bytes
64 bytes from fd00:11::199: icmp_seq=1 ttl=63 time=1.38 ms
64 bytes from fd00:11::199: icmp_seq=2 ttl=63 time=1.17 ms

成功していれば、問題解決です。当初の目的通りに、サーバ2に特定の範囲のIPv6アドレスを自動的に割り当てることができました。

採点基準

想定解法の場合

  • サーバでRAを設定している: 60点
  • サーバでDHCPv6を設定している: 70点
  • 端末2にリンクローカルアドレスで接続している: 70点
  • クライアントを正しく設定している: 40点

その他の解法の場合

  • IPv6アドレスが正しく割り当てられている: 140点
  • 端末1から端末2へpingが通る: 100点

参考

この問題を解く、あるいは解説を理解するにあたって参考となるウェブページを上げておきます。

  • RAとDHCPv6について: https://www.infraexpert.com/study/ipv6z5.html
  • IPv6ユニキャストアドレスについて: https://www.infraexpert.com/study/ipv6z3.html
  • IPv6マルチキャストアドレスについて: https://www.infraexpert.com/study/ipv6z10.html
 /

問題文

あなたが所属している会社では、社内専用のWebサイトを別のサーバにリプレイスしました。Webサイトの移行はトラブルなく完了しましたが、後輩が担当していたネットワーク部分が上手く動作せず、社内ネットワークからWebサイトへアクセスできません。自分では手に追えなくなった後輩があなたに泣きついてきました。

「Webサイトには 『 http://192.168.15.125 』 でアクセスするんですが、社内ネットワークからアクセスすることが出来なくて……。多分、ルータのNAT周りの設定がおかしいと思うんですがどこを直したらいいんでしょうか……? 先輩助けてください!」

トラブルの原因を突き止めて、サイトが正常に閲覧できるようにしてください。

情報

  • 使用する手元機材 : AR2050V
  • ユーザー : admin
  • パスワード : IWgrk2Dz
  • 社内ネットワーク
  • IPアドレス:DHCPで配布
  • AR2050VのLANポートに接続すると社内ネットワークに入れる
  • Webサーバ
  • 社内ネットワークからWebサーバへアクセスするためのIPアドレス:192.168.15.125
  • なおWebサーバの本来のホストは192.168.15.125ではなく、192.168.15.32である。
  • Webサーバを操作することはできない

問題に関する禁止事項

  • NATルールを変更しない
  • 物理配線を変更しない
  • IPアドレスを変更しない
  • DHCPを変更しない

報告書を書く際の必須事項

  • 追記・修正するためのコンフィグ
  • 『 http://192.168.15.125 』にアクセスした結果

トラブルの概要

双方向NATをするための以下の要素が正しく設定されていないため、参加者PCからWebサーバへアクセスできません。

  • proxy arp の設定が漏れている
  • zone localの内容が間違っている
  • zone globalの内容が間違っている

解説

Webサーバへアクセスできないのは、双方向NATするための条件が揃っていないことが原因です。

双方向NATとは、1台のNATデバイスで「内部の送信元アドレス変換」と「外部の送信元アドレス変換」を同時に行うNATのことです。双方向にアドレスが変換されることから、内部ホストと外部ホストの双方ともお互いのIPアドレスを知ることなく通信することが可能になります。

双方向NATの条件がそろっていないことが原因ということですが、NATの設定から順を追ってみていこうと思います。

NATの確認

まずはNATの設定を確認しましょう。

今回のNAT設定は以下のようになっていました。

nat
rule 10 masq any from private to global with src global.wan.client
rule 20 portfwd any from private to local.lan.server with dst public.wan.server

今回は、スタティックNATで双方向NATを実現しています。

1行ずつ見ていきましょう。

「内⇒外」方向のスタティックNAT

rule 10 masq any from private to global with src global.wan.client

上記の設定は、

  • rule コマンドで masq アクションを指定されているため、「内⇒外」方向へのスタティックNATである。
  • すべてのアプリケーションの送信元エンティティー「from private」で宛先エンティティー「to global」のとき、送信元IPアドレスを「with src global.wan.client」に変換する。

を表します。

次に、このNATに関するエンティティーの内容を確認します。

zone private
network lan
ip subnet 192.168.15.64/26
host client
ip address 192.168.15.70
ip address 192.168.15.71
ip address 192.168.15.72
ip address 192.168.15.73
ip address 192.168.15.74
ip address 192.168.15.75
ip address 192.168.15.76
ip address 192.168.15.77
ip address 192.168.15.78
ip address 192.168.15.79
ip address 192.168.15.80
!
zone global
network wan
ip subnet 192.168.15.0/24
host client
ip address 192.168.15.125

送信元エンティティーである「private」は、ルータのLANポートに接続したときに降ってくるDHCPが指定されています。

宛先エンティティーである「global」は、NATの設定通りであるとすると、送信元IPアドレスを変換するための条件(ネットワーク定義にWebサーバが属するネットワークアドレス、ホスト定義に特定のipアドレス)が設定されているはずですが、でたらめな条件になっていることが分かります。

よって、このゾーン定義の内容を修正する必要があります。

no zone global
zone global
network wan
ip subnet 192.168.15.0/26
host client
ip address 192.168.15.33

送信元ipアドレスを変換するための「with src global.wan.client」は、show runnning-configを確認すると ip route 192.168.15.33/32 eth1 が設定されているので、192.168.15.33 を指定すると良さそうです。

「外⇒内」方向のスタティックNAT

rule 20 portfwd any from private to local.lan.server with dst public.wan.server

上記の設定は、

  • ruleコマンドで portfwd アクションを指定されているため、「外⇒内」方向へのスタティックNATである。
  • すべてのアプリケーションの送信元エンティティー「from private」で宛先エンティティー「to local.lan.server」のとき、宛先IPアドレスを「with dst public.wan.server」に変換する。

を表します。

次に、このNATに関するエンティティーの内容を確認します。

zone local
network lan
ip subnet 192.168.15.0/24
host server
ip address 192.168.15.33
!
zone private
network lan
ip subnet 192.168.15.64/26
host client
ip address 192.168.15.70
ip address 192.168.15.71
ip address 192.168.15.72
ip address 192.168.15.73
ip address 192.168.15.74
ip address 192.168.15.75
ip address 192.168.15.76
ip address 192.168.15.77
ip address 192.168.15.78
ip address 192.168.15.79
ip address 192.168.15.80
!
zone public
network wan
ip subnet 192.168.15.0/26
host server
ip address 192.168.15.32
!

送信元エンティティーである「private」は、1行目のNATのときと同じなので割愛します。

宛先エンティティーである「local.lan.server」は、問題文に書かれていた、社内ネットワークからWebサーバにアクセスするときのIPアドレス192.168.15.125 が当てはまるはずですが、1行目のNATと同様に、ネットワーク定義もホスト定義もでたらめになっています。

よってこのゾーン定義を修正する必要があります。

no zone local
zone local
network lan
ip subnet 192.168.15.64/26
host server
ip address 192.168.15.125

宛先ipアドレスを変換するための「with dst public.wan.server」は、Webサーバの本来のipアドレスが指定されているので、修正する必要はありません。

代理応答機能を追加する

Firewallはすべてのエンティティー間を許可しているので問題ないため、NAT周りはすべて修正出来ました。

双方向NATでは、ルータ本体に設定されていないIPアドレスを使用しています。

よって、そのIPアドレスに対してルータが代理応答する必要があります。

特定のIPアドレス範囲を代理応答させるためには local-proxy-arp コマンドを用いて設定する必要があります。

しかし、show runnning-configを確認した限り、設定されていないようなので、追加設定をしなければなりません。

local-proxy-arp 192.168.15.125/32
local-proxy-arp 192.168.15.33/32

上記の設定を有効にするためには、該当するインターフェースに対してリミテッドローカルプロキシーARPを有効にする必要がありますが、インターフェースvlan43とインターフェースeth1どちらとも有効になっているので、設定する必要はありません。

回答例

!
local-proxy-arp 192.168.15.125/32
local-proxy-arp 192.168.15.33/32
!
no zone global
zone global
network wan
ip subnet 192.168.15.0/26
host client
ip address 192.168.15.33
!
no zone local
zone local
network lan
ip subnet 192.168.15.64/26
host server
ip address 192.168.15.125
!

採点基準

  • proxy arp の設定が正しく追加されている(30%)(計30%)
  • zone global の設定が正しく修正されている(15%)(計45%)
  • zone local の設定が正しく修正されている(15%)(計60%)
  • client から 192.168.15.125 にブラウザからアクセスするとWebページが閲覧できる(40%)(計100%)

 

 /

問題文

さて、突然ですが超有名大企業ICTSC Comに入社した新入社員のあなたのミッションは、SRv6を使ってHostAからHostBへの通信の際にIDS(Snort)をサービスチェインして通るようにするということを任されました。
しかし現在はSRv6でHostAからHostBへ通信はIDS Nodeを通らずに通信をしてしまっています。
これをIDS Nodeを通ってからHostBに通るようしてほしい。

HostA: 10.0.0.1/24から HostB: 10.0.1.1/24にPingが飛ばせています。
この状態ではIDS Nodeを通らずHostAからHostBへSRv6を使ってルーティングされています。

IDS Nodeではnetwork namespaceで切り分けられたLinuxとSnortが内部に存在します。残念ながらSnortはディフォルトではSRに対応できていないため注意してください。またSnort自身の設定は変えなくても問題ないように設定されています。
そしてちゃんとパケットが流れればSnortのコンソールを確認するとアラートが流れることが確かめることができます。

以下にトポロジーと認証情報を添付するので確認してみてください。

情報

全てのホストは以下情報で入れます
ユーザー: admin
パスワード: hello_5g

以下のIPアドレスはManagementのための接続アドレスです。

Host A

IPアドレス: 192.168.12.6

Router 1

IPアドレス: 192.168.12.1

Router 2

IPアドレス: 192.168.12.2

Router 3

IPアドレス: 192.168.12.3

Router 4

IPアドレス: 192.168.12.4

IDS

IPアドレス: 192.168.12.5

Host B

IPアドレス: 192.168.12.7

構成

問題スタート

HostAからHostBにPingが飛ばせる。この状態ではAからBへSRv6を使ってルーティングされてる

問題ゴール

HostAからIDSを通ってHostBにPingが飛ばせる様になる。
IDSではICMPを認識して検出ができる.

注意事項

  • 必ずSRv6の機能をつかうようにしてください。
  • トラブルはSRだけとは限りません。あらゆる事がありえます。
  • SnortはIDSが立ち上がっている中でnetwork namespace(veth)で区切られている。以下の方法で簡単に確認ができます。

下には便利なチートシートです。

# srextを使うときはこれを実行してからではないと動きません(公式ドキュメントから抜粋)
sudo depmod -a
sudo modprobe srext

# vethにpacketが通ってきているか見たいとき
ip netns exec Snort tcpdump -i veth0-Snort

# Snort側のnamespaceに移る
ip netns exec Snort bash

# Snortでのアラートが見たいとき(exec Snort bashをした後に使える)
Snort -c /etc/Snort/Snort.conf -A console

トラブルの概要

SFCをしたいができていない。

解説

この問題は、2つのIPv4対応ホスト(hostA and hostB)がSegment routing over IPv6 dataplane(SRv6)を介して通信できるようにして、サービスチェインを実装する問題でした。

トポロジーの細かい要素としては以下のようになります。

  • Router
    • R1,R3,R4: SRv6をサポートするルーター
    • R2: v6だけサポートするルーター
  • IDS: namespaceで区切られたSnortが動作しているサーバ

実際にパケットの動きを見ていきましょう。

まず今回の基本設定の状態はAからBへのトラヒックはR1,R2,R3,R4を通じてBへ渡されます。
実際のフローを少し細かく文章化すると以下のようになります。

IPv4のペイロードがHostAからHostBへ送信される

IPv4のペイロードがHostAから送信されます。
ここではSegment routing header(以下SRH)は付与されず、宛先がHostBになっているIPv4パケットとして送信されます。

パケット構成は以下のようになります。

  • Ethernetヘッダ
  • IPv4
    • 送信元アドレス: HostA
    • 送信先アドレス: HostB

HostAから送信されたパケットがR1に到着

R1では以下の作業が行われます。

  • IPv6カプセル化をする
  • 2つのノードを対象にするヘッダであるSegment Routing Header(SRH)を挿入しカプセル化をする

SRHの中にはロケーター情報として、R3,R4を経由するという順序情報と、Segments Left(SL)というSRに対応したルーターを残りいくつ通るかの情報が記載されています。

この作業が終わった後のパケット構成は次のようになります。

  • Ethernetヘッダ
  • IPv6ヘッダ
    • 送信元アドレス: R1::1
    • 宛先アドレス: R3::bb
  • SRH
    • ロケーター情報: R4::bb, R3::bb
    • Segments Left(SL): 1
  • IPv4
    • 送信元アドレス: HostA
    • 送信先アドレス: HostB

上記情報から、IPv6ヘッダの指し示す宛先がR3であるため、R1のルーティングテーブルを見てパケットはR2へと転送されます。

R1から転送されたパケットがR2に到着

R2ではSRv6に対応するための設定は投入していません。
しかし、IPv6の経路情報はR2にインストールされているため、IPv6ルーティングによりR3に転送することができます。

R2から転送されたパケットがR3に到着

R3ではSRv6に対応するための設定が投入されているため、R3::bbに対応する操作を実行し、次の処理を行えるようにするためにEnd動作をします。
End動作により、IPv6ヘッダの値とSRHのSegments leftの値が書き換わります。

  • Ethernetヘッダ
  • IPv6ヘッダ
    • 送信元アドレス: R1::1
    • 宛先アドレス: R4::bb
  • SRH
    • ロケーター情報: R4::bb, R3::bb
    • Segments Left(SL): 0

この情報から、次はR4へとパケットを転送します。

R3から転送されたパケットがR4に到着

R4がSRv6網の終端となります。
この先のネットワークはIPv4ネットワークで、SRv6とIPv6のカプセル化を解除する必要があるため、End.DX4動作をしてカプセル化の解除を行います。

その際、具体的には外部のIPv6ヘッターを除去し、R3でSRv6の設定(function)により決められたIPv4 Next hopへとパケットを転送します。

  • Ethernetヘッダ
  • IPv4
    • 送信元アドレス: HostA
    • 送信先アドレス: HostB

上記の手順により、HostBにPing Requestを送信することができました!

次はPing Replyパケットが送信されるまでのフローを見ていきましょう。

問題出題状態では、R3を通らずに R4 -> R3 -> R1 のようにパケットが転送されるようになっています。

IPv4のペイロードがHostBからHostAへ送信される

IPv4のペイロードがHostBから送信されます。

  • Ethernetヘッダ
  • IPv4
    • 送信元アドレス: HostB
    • 送信先アドレス: HostA

HostBから送信されたパケットがR4に到着

R4では以下の作業が行われます。

  • IPv6カプセル化をする
  • 2つのノードを対象にするヘッダであるSegment Routing Header(SRH)を挿入しカプセル化をする
  • その後のパケットは以下のようになります

    • Ethernetヘッダ
    • IPv6ヘッダ
      • 送信元アドレス: R4::dd
      • 宛先アドレス: R1::1
    • SRH
      • ロケーター情報: R1::1
      • Segments Left(SL): 0
    • IPv4
      • 送信元アドレス: HostB
      • 送信先アドレス: HostA

    上記情報から、IPv6ヘッダの指し示す宛先がR3であるため、R1のルーティングテーブルを見てパケットはR2へと転送されます。

    R4から転送されたパケットがR2に到着

    R2ではSRv6に対応するための設定は投入していません。
    しかし、IPv6の経路情報はR2にインストールされているため、IPv6ルーティングによりR1に転送することができます。

    R2から転送されたパケットがR1に到着

    R1がSRv6網の終端となります。
    この先のネットワークはIPv4ネットワークで、SRv6とIPv6のカプセル化を解除する必要があるため、End.DX4動作をしてカプセル化の解除を行います。

    その際、具体的には外部のIPv6ヘッターを除去し、R3でSRv6の設定(function)により決められたIPv4 Next hopへとパケットを転送します。

    • Ethernetヘッダ
    • IPv4
      • 送信元アドレス: HostB
      • 送信先アドレス: HostA

    ここまでが基本的な状態の設定として問題環境に設定していた状態でした。
    SRv6について理解するためのきっかけになったと思います。

    では実際の問題を解くフェーズに入っていきます。

    今回の問題で行う方策をまとめると、

    • Snortがあるホスト(IDS)を通ってパケットを動かす必要がある
      • しかしSnortはSRv6に対応していない

    ということになります。

    (ちなみに 普通Snortは別ホストじゃないんですか? という質問については、この問題で使用するVMのリソースがコンテストで使用している物理サーバーのうち一台のサーバーをおおむね専有するほど多く、メモリを節約するためにしょうがなく行った苦肉の策でした。
    ですが出題としては全く問題ないのでこのまま出題しました。)

    今回のトポロジーから、Snortがあるホストにパケットを転送させるにはR1で付与するSRHのロケーター情報にR5を追加することで、R5を経由することができるようになります。

    しかし、SnortはSRv6に対応していません。そのため、一度SRv6のカプセリングを外してIPv4のパケットだけに変換する必要があります。

    「SRv6はデータプレーンにロケーション情報等が付与されているだけなので一旦外す」という方法が考えれると思います。
    ちょっと意地悪に見えるかなぁと思い、出題的には # srextを使うときはこれを実行してからではないと動きません(公式ドキュメントから抜粋) と書いておいたコードがありました。
    このコードについてインターネットで調べると、例えば

    いhttps://github.com/netgroup/SRv6-net-prog

    というリンクが見つかり、以下のようなそれっぽいfunctionを見つけることができます。

    • End.AD4: Endpoint to IPv4 SR-unaware APP via dynamic proxy
    • End.EAD4: Extended End.AD4 behavior that allow SR-unaware VNFS to be the last SF in SFC

    このことから、bbの定義を

    srconf localsid add fc00:5::bb end.ad4 ip 192.168.1.2 veth0 veth1

    このようにすることで、無事Snortまで通信が転送されます。Snortから戻ってきたパケットは正常にR4に流れていきます。
    別解としてEnd.EAD4を利用する方法もありますが、こちらでも問題はありません

    具体的な挙動としては、veth0に対して流れてきたパケットのSRHを外して、 IPv4 Payload オンリーにして流してあげるだけです。veth1に戻ってきたら、先程外したSRHを再度付与します。
    これで無事通信をIDSを通じてhostBへ行くことができました!

    問題作成の狙いとお気持ち

    この問題は次世代ネットワークについての知識をつけてほしいということから作りました。そもそもほぼ全員がSRv6ってなんやねんというところからで辛いかなと思ってたんですが、まずは存在を知ってもらって、その上でおもしろいところや有用性を理解してもらえたら嬉しいなと思って作った問題でした。また、狙いとしてSRv6はほぼmininet以外で遊べる環境というものは公開されていないため直接OSに対して書き込むconfigとかがあまり見ることができないというのがあります。なので今回は公開をすることでトラコン参加者以外も幸せになるおもしろい問題になったんじゃないかと思います。

    ちなみにですが実は自動起動の設定にsystemctlを使用したため、問題参加者はそのへんをガサゴソするとconfigがでてきて参考になったかも知れません。
    なおホントはもう少し難しい問題にする予定だったんですが、、、これではあまりにも解けなそうではと言われて変更して、変更したやつも、ちょっとむずかしいのでは?と言われてSRのコマンドだけの修正で解ける問に変更されたので Baby とつけていました。ちょっとpwn系のCTF問題みたいなネームみたいですね。
    それでも難しいと言われたので誰も挑戦してくれないかなとヒヤヒヤしていましたが、いくつかのチームは挑戦してくれたのでホッとしました笑

    回答例

    R1のSegment ID table(SID, つまり通るべき経路の指定)をR3,R5,R4の順番でオーダーする
    ip route add 10.0.1.0/24 encap seg6 mode encap segs fc00:3::bb,fc00:5::bb,fc00:4::bb dev eth1
    IDS NodeのSnortはSRHを処理することができません。よってIPv6 headerを取り外してあげる必要があります。よってサービスチェインのダイナミックプロキシを行う必要があります
    srconf localsid add fc00:5::bb end.ad4 ip 192.168.1.2 veth0 veth1
    ちなみにR1でR3,R4で指定してR3でR5に行くようにoverSRv6を更にしたらいいのではと思うかもしれないですが、拡張カーネルが必要で今回は対応していないため困難です

    これは今回出題したSRv6についての問題を体験できるVagrantFileです。もしよかったらぜひ遊んでみてください!!
    https://github.com/takehaya/SRv6_SFC_Example

    採点基準

    点数となるのはIDSNodeまでの中継するべきノードをSRv6でオーダーされていて50%+その後にダイナミックプロキシされるで満点を与える方針
    そもそもオーダーがない場合などは部分点をつけることはしません

 /

問題文

日本拠点とベネチア拠点間にGREトンネルを開通する。
しかし、うまく疎通性の確認が取れない。
あなたは今から日本拠点のトンネル構築をするルータである 892J-A の設定を調査して解決し、何が原因だったのか報告してほしい。

情報

  • 892J-A

ポート: FastEtheret0〜7
ユーザー: admin
パスワード: 1Fa3Iiik

892J-Aのみ操作を行う

問題のゴール状態

PCから192.168.4.255 への疎通性がある

提出すべきもの

  • 設定したコンフィグ
  • 参加者PCから 192.168.4.255 までのトレースルートの結果

構成

禁止行為

  • 物理配線・論理構成(IPアドレス・VRFなど)の変更

トラブルの概要

  • tunnel vrf コマンドを入れていない為、GREトンネルがアップしない
  • +VRF tunnel にスタティックルートを書いてない為、192.168.4.255にPingが飛ばない

解説

今回のトラブルは、この中のGREトンネルのインターフェース(892J-Aのtunnel80)がLinkUpせず、PCから 192.168.4.255 へ疎通できないものでした。

まず、CiscoのGREトンネルの挙動についてのおさらいですが、GREトンネルはそれ自体のIPアドレスとは別にカプセル化したパケットの宛先IPと送信元IPもしくは送信元インターフェースを指定する必要があります。トンネルのインターフェースがLinkUpする条件は、この宛先IPアドレスへの経路がルーティングテーブルにインストールされているかどうかとなります。

これはVRF-Liteと呼ばれるルーティングテーブルを仮想的に分割する技術を使用していても使用することは可能ですが、その場合はカプセル化したパケットの宛先IPアドレスがどのルーティングテーブルに従って送信するかを明示的に指定する必要があります。今回の場合カプセル化したパケットはVRF global に従うように設定する必要があります。

その部分の解答コンフィグを以下に示します。

interface tunnel80
tunnel vrf global
exit

また、トンネルインターフェースとPCを接続するインターフェースが所属するVRF tunnel に、192.168.4.255 への経路が書かれていなかったため、それを手動で追加する必要があります。

その部分の解答コンフィグを以下に示します。

ip route vrf tunnel 192.168.4.255 255.255.255.255 192.168.4.201

以上のコマンドを入力することで、PCから192.168.4.255まで疎通することができるようになります。その時のtracerouteの結果は以下のようになります。

192.168.4.255 へのルートをトレースしています。経由するホップ数は最大 30 です

1 <1 ms <1 ms <1 ms 192.168.4.1
2 <1 ms <1 ms <1 ms 192.168.4.255

トレースを完了しました。

ここまでのコマンドとtracerouteの結果を示すことで、この問題は完答となります。またコマンドはこの通りでなくても同じことができるものであれば得点としています。

回答例

int tunnel 80
tunnel vrf global
exit
ip route vrf tunnel 192.168.4.255 255.255.255.255 192.168.4.201

採点基準

  • tunnel vrf コマンドを正しく入力している。:60%
  • スタティックルートまで正しく入力し、想定通りのtraceroute結果を示している。:満点