はじめに

こんにちは, IT基盤部ネットワークグループ(NOC)のnagiです.

NOCでは本社やグループ会社を含む多くのオフィスネットワークを運用しています. これらのオフィスネットワークの規模感はさまざまですが, 多くはインターネット回線を冗長化しています.

利用回線はいずれも品質を考慮しダークファイバー系のプロバイダーをよく採用しています. 加えてセキュリティ要件として必要なため/29で固定IPアドレスを確保しています. そのため回線費用は2万円~3万円程度, 回線冗長拠点の場合だとこれの倍です. 一拠点あたりでは大した金額ではありませんが, 拠点数が多いのでそこそこな金額にはなります. また事業部直営の拠点の場合は, 予算確保が難しく回線冗長化を断念するケースもありました.

そこでバックアップである副回線を安価なフレッツ光に切り替えました¹. NGN折り返し通信で自社DCまでのトンネルを用意し, DCからインターネットに出る基盤を構築しました. ISPを利用せずNGN網内で完結することで低遅延な通信を実現しています.

本記事では拠点とDCの接続構成について簡単に紹介します.

構成

初期構成

初期は遊休サーバを利用して拠点とDC間でIPトンネルを構築していました. DC側はメンテナンス用の踏み台サーバにVMを建てました. IPトンネルはインターネット通信用とし内部通信用に別途IPsec VPNも張っています. 主回線はJuniper SRXで終端していますが, 副回線はUbuntuサーバ間で終端する形になりました.

なぜUbuntuなのか, なぜ拠点側をSRXで終端しないのかの話をします. まずUbuntu採用には深い意図はありませんでした. NOC内で運用しているサーバは主にUbuntuであったため, 管理基盤に相乗りができOSの保守運用が楽という理由でした. そしてSRXで終端しなかった理由は, 当時はIPIP6がサポートされていなかったためです. 構成の複雑化を避けるために, IPsec VPNですべてのトラフィックを捌くことも検討しましたが, 利用していたモデルでは明らか力不足でした².

通信経路としては拠点FirewallからUbuntuを経由しDCでNATしてインターネットへ出る流れになります. DeNAはCloud Journey³前までは大規模なオンプレミス運用をしており, その名残りで今もASを保持し運用しています. 現在はオンプレミスでのサービス提供はなく, IPアドレスが多少余っているためその資源を活用した形になっています.

構築後, 実際にオフィスで何回か検証を実施し品質に問題がないことを確認しました⁴. スループットも400Mbps~500Mbps程度出ており, 中小規模拠点の回線として十分な性能が出ていました. ただ拠点側にサーバを設置する必要があること, トンネル設定, IPsec (Strongswan)の設定管理が面倒であったため他拠点への展開は様子見していました…

現構成 (本番構成)

なんということでしょう. 拠点側にあったUbuntuサーバは消え去り, IPsec VPNはIPトンネル内に収納されました.

実はJunos22.2以降でIPIP6に対応できるようになったため, サーバの排除が可能になりました. そしてDC側をUbuntuからVyOS⁵に置き換えました. VyOSはオープンソースのファイアウォールです. VyOSを選定した理由としては, 更新が活発であること, CLIがチーム内で馴染みのあるJunosライクであることが挙げられます. 当然ですがUbuntuで構築していたときと比べ圧倒的に設定はシンプルになりました. 同時に設定見直しを実施し, IPsec VPNはトンネル内に収納する形に変更しました. 機能的には変わりませんが, こっちのほうがシンプルです.

またNATをDC側ではなく, 拠点側のSRXで実施する形に変更しました. それに伴いDC側のIPsec終端を, サーバではなく主回線と同様の接続先に変更しました. SRXに置き換えましたが, 品質は問題なく, スループットも同程度出ていました (SRX340で検証).

参考までにサンプルconfigを抜粋して示します. ⁶

VyOS

set high-availability vrrp group ipip1 address 2001:db8:2::1
set high-availability vrrp group ipip1 advertise-interval '2'
set high-availability vrrp group ipip1 interface 'eth0.40'
// VyOS1と2でPriorityを変更
set high-availability vrrp group ipip1 priority '200'
set high-availability vrrp group ipip1 vrid '140'
set high-availability vrrp group ipip2 address 2001:db8:2::2
set high-availability vrrp group ipip2 advertise-interval '2'
set high-availability vrrp group ipip2 interface 'eth0.40'
set high-availability vrrp group ipip2 priority '100'
set high-availability vrrp group ipip2 vrid '240'

set interfaces tunnel tun0 encapsulation 'ipip6'
set interfaces tunnel tun0 mtu '1460'
set interfaces tunnel tun0 parameters ipv6 encaplimit 'none'
set interfaces tunnel tun0 remote ${branch1_ipv6}
set interfaces tunnel tun0 source-address '2001:db8:2::1'
set interfaces tunnel tun0 source-interface 'eth0.40'
set interfaces tunnel tun1 encapsulation 'ipip6'
set interfaces tunnel tun1 mtu '1460'
set interfaces tunnel tun1 parameters ipv6 encaplimit 'none'
set interfaces tunnel tun1 remote ${branch2_ipv6}
set interfaces tunnel tun1 source-address '2001:db8:2::2'
set interfaces tunnel tun1 source-interface 'eth0.40'

Juniper SRX

set interfaces ip-0/0/0 unit 0 tunnel encap-type ipv6
set interfaces ip-0/0/0 unit 0 tunnel source 2001:db8:1::1
set interfaces ip-0/0/0 unit 0 tunnel destination 2001:db8:2::1
set interfaces ip-0/0/0 unit 0 family inet filter input TO_NGN
set interfaces ip-0/0/0 unit 0 family inet address 192.0.2.1/32

監視

SRXやVyOSの監視は, 死活監視やリソース, トラフィック量等の一般的な項目をPrometheusで監視しています. これらはすでに稼働している監視基盤に追加するだけなので大変なことではありません.

副回線特有の遅延監視の課題

ただ回線の遅延監視は少し工夫が必要でした. この回線は副回線です. つまり主回線が死んでいるときに利用する回線になります. そのため通常時は副回線宛の経路が入っておらず疎通性がありません. もちろんPBR (Policy-Based Routing)などで疎通性を確保することもできますが, このためだけに設定を複雑化したくはありません.

では他の拠点も監視していないのかというとそうではなく, 多くはプロバイダのGWを宛先とし品質監視を実施しています. 今回はこれと同様のことはできません. なぜならNGNは網内でしか疎通性がない謎のIPv6で構築されているからです. AWSや主要拠点に設置されたSmokeping⁷サーバとの疎通性はありません.

VyOS上でのping_exporterによる解決

そこでSmokepingではなくVyOSそのものに監視を担当させることにしました. VyOS上でping_exporter⁸を動かし, Prometheusからメトリクスを取得する形で品質監視を実施しています. ただこちらもちょっとした罠がありました. VyOSのマネジメント通信はVRFで隔離しているため, ping_exporterが動いてもVRFをまたげず, Prometheusからメトリクスの取得はできませんでした. この問題はカーネルパラメータを設定することで解決できました.

# 1. VRFを跨いだ接続の受け入れを許可
sudo sysctl -w net.ipv4.tcp_l3mdev_accept=1

# 2. 自分（デフォルトVRF）が持っていないIPへのバインドを許可
sudo sysctl -w net.ipv4.ip_nonlocal_bind=1

# 3. マネジメントVRFでリッスン
./ping_exporter --web.listen-address 10.0.0.100:9427 2001:db8:1::1

実際にRTTメトリクスを取得し, 元々利用していたダークファイバープロバイダの回線と比較しましたがほぼ同等の品質であることが確認できました.

まとめ

副回線をダークファイバー系プロバイダーからフレッツ光に切り替えることで, コスト削減を実現しました. ISPを利用せずNGN網で完結する構成にすることで低遅延な通信を実現しています.

逸般家庭ではよく利用されている網内折り返し通信ですが, 中小規模なオフィスネットワークでも十分利用可能な実例を示しました. 主に情シス担当の方に参考となれば幸いです.