現場の課題:エンタープライズにおけるエッジゲートウェイのジレンマ
半年前、アッシュバーンのコロケーション施設において、私たちのインフラは深刻な壁に直面しました。オンプレミスの3つのKubernetesクラスタ(約140台のワーカーノード)を上流のトランジットプロバイダーおよび5GbpsのAWS Direct Connect回線に接続するため、10Gbps×2の冗長エッジゲートウェイが必要でした。しかし、従来使用していたJuniper MX240シャーシは製品寿命(EOL)を迎えつつありました。ベンダーによるサポートとライセンス更新の見積もりは更新費用だけで68,000ドルを超え、後継ハードウェアの納期は18週間以上に及んでいました。
ローンチ期日のプレッシャーから、私たちは一時的な代替策を試みました。Ubuntu 22.04を搭載した2台のDell PowerEdge R640サーバーを用意し、BGP用にFRRoutingをインストール、NATとステートフルフィルタリングのためにnftablesをスクリプト化し、スタック全体をAnsibleでまとめ上げたのです。
しかし、稼働からわずか3週間で、この構成は運用の現実に耐えきれなくなりました。ルーティングポリシーの変更によって既存のファイアウォールのステートテーブルが頻繁に破壊されました。午後のピーク時にBGPフラップによってプレフィックスのドロップが発生した際、原因の特定には4つのフラットな設定ファイルを相互参照し、systemd-networkdの挙動を追跡し、複数のターミナルにまたがって個別のデーモンログを監視しなければなりませんでした。
根本原因の分析:アドホックなLinuxルーターが大規模運用で破綻する理由
標準的なLinuxディストリビューションは、極めて高速にパケットを転送できます。しかし、専用のネットワークオペレーティングシステム(NOS)が持つ統合されたアーキテクチャが欠落しています。汎用Linux上に本番向けエッジルーターをつぎはぎで構築すると、次の3つの構造的な障害パターンが恒常的に発生します。
- 設定の分断:動的ルーティング(FRR/BIRD)、パケットフィルタリング(
nftables)、IPアドレス割り当て(netplan)、カーネルチューニング(sysctl)がサイロ化して独立しています。インターフェースのMTU変更をBGP Path MTU DiscoveryやTCP MSSクランピングへ自動連係させる共通エンジンが存在しません。 - アトミックなコミットとロールバックの欠如:
nftablesのルールセット内に括弧が1つ欠けているだけで、処理が途中で中断します。その結果、パケットフィルターが中途半端に適用された状態となり、自動復旧経路もないままトラフィックがドロップしたり、帯域外(OOB)管理セッションが切断されたりするリスクを抱えます。 - ステート同期の不整合:コネクショントラッキング(conntrack)とは無関係に動的ルーティングデーモンを単独で再起動すると、頻繁にconntrackステートが無効化されます。これによりアクティブなTCPセッションが切断され、日中の定期メンテナンス時に微細な通信障害(マイクロアウトエイジ)を引き起こします。
ソリューション比較:専用ハードウェア vs 汎用Linux vs VyOS
高スループットルーティングとエッジセキュリティの基盤を選定する際、通常は次の4つのアーキテクチャが比較対象となります。
| 評価基準 | 専用ハードウェア(Cisco/Juniper) | 自作Linux(Ubuntu + FRR + nftables) | FreeBSD系ファイアウォール(pfSense/OPNsense) | VyOS(ソフトウェアルーター) |
|---|---|---|---|---|
| ライセンス&ハードウェア費用 | 30,000〜100,000ドル以上。ベンダー専用ASICに依存 | ソフトウェア費用0ドル。汎用x86/ARM/VMで稼働 | コミュニティ版は無料。公式アプライアンスも選択可能 | オープンソースコア。ベアメタル、VM、クラウド上で動作 |
| 設定エンジン | commit/rollbackを備えた階層型CLI | 分散したフラットファイル、トランザクション安全性なし | Web GUI主体。モノリシックなXMLバックエンド | アトミックなcommit/rollbackを備えた統合階層型CLI |
| BGP&動的ルーティング | フルルート対応、高度なルーティングポリシー | 高機能なFRRデーモンだが手動統合が必要 | FRRプラグイン利用可能。基本的なポリシー制御のみ | 高度なルートマップとプレフィックスリストを備えたネイティブFRRバックエンド |
| 自動化&CI/CD | プロプライエタリAPI、複雑なベンダーモジュール | 標準的なLinuxツール(Ansible、Bashスクリプト) | 限定的なREST API、GUI主体のワークフロー | ネイティブHTTP API、公式Ansibleコレクション、Terraformプロバイダー |
最適なアプローチ:BGP、ゾーンファイアウォール、NATを備えたVyOSの導入
VyOSは、Linuxカーネルの素のワイヤーレート性能と、JunOSを彷彿とさせるキャリアグレードの統合管理モデルを兼ね備えています。すべてのコマンドは単一の宣言的シンタックスツリーを対象としており、トランザクショナルなコミット、即時ロールバックポイント、予測可能なステート検証を標準で利用可能です。
実際の本番環境切り替えにおいて、VyOS 1.4を搭載した2台のベアメタル1Uサーバーは、ミリ秒未満のレイテンシで9.2Gbpsの持続スループットを難なく処理し、ハードウェアコストを従来の専用アプライアンスのほんの一部に抑えることができました。ここでは、WAN(eth0)とLAN(eth1)のデュアルインターフェースを備え、ゾーンベースのセキュリティポリシー、アウトバウンド送信元NAT、eBGPルート広告を完備したエッジゲートウェイの正確な構築ブループリントを紹介します。
1. 初期セットアップとインターフェースの割り当て
VyOSノードへのコンソールまたはSSHセッションを開きます。設定モードに入り、WANポートおよびLANポートに静的IPアドレスと識別用の説明タグを設定します。
configure
# 上流ISPトランジットに接続されたWANインターフェースを設定
set interfaces ethernet eth0 address '198.51.100.2/30'
set interfaces ethernet eth0 description 'WAN-Uplink-ISP1'
# 内部ワークロード用LANゲートウェイインターフェースを設定
set interfaces ethernet eth1 address '10.100.0.1/24'
set interfaces ethernet eth1 description 'LAN-Production-Core'
# ホスト名と上流再帰DNSリゾルバを設定
set system host-name 'gw-core-01'
set system name-server '1.1.1.1'
set system name-server '8.8.8.8'
commit
save
2. ゾーンベースのステートフルファイアウォールの構築
VyOSはゾーンベースセキュリティを採用しています。物理インターフェースに直接ファイアウォールルールをバインドするのではなく、インターフェースをセキュリティゾーンにまとめ、ゾーン間に双方向のポリシーを適用します。この設計により、トポロジが拡大してもルールの肥大化を防ぐことができます。
WANからLAN、LANからWAN、およびルーター自身を宛先とするコントロールプレーン通信(LOCAL)に対する明示的なポリシーを構築します。
# WANからLANへの定義:セッション応答を維持しつつインバウンドトラフィックをブロック
set firewall ipv4 name WAN_TO_LAN default-action 'drop'
set firewall ipv4 name WAN_TO_LAN rule 10 action 'accept'
set firewall ipv4 name WAN_TO_LAN rule 10 description '確立済みおよび関連トラフィックを許可'
set firewall ipv4 name WAN_TO_LAN rule 10 state 'established'
set firewall ipv4 name WAN_TO_LAN rule 10 state 'related'
set firewall ipv4 name WAN_TO_LAN rule 20 action 'drop'
set firewall ipv4 name WAN_TO_LAN rule 20 description '不正パケットおよび無効パケットを破棄'
set firewall ipv4 name WAN_TO_LAN rule 20 state 'invalid'
# LANからWANへの定義:内部ホストからのアウトバウンドインターネットアクセスを許可
set firewall ipv4 name LAN_TO_WAN default-action 'accept'
# WANからLOCALへの定義:ルーターの管理プレーンおよびルーティングエンジンを保護
set firewall ipv4 name WAN_TO_LOCAL default-action 'drop'
set firewall ipv4 name WAN_TO_LOCAL rule 10 action 'accept'
set firewall ipv4 name WAN_TO_LOCAL rule 10 description '確立済み・関連コントロールプレーントラフィックを許可'
set firewall ipv4 name WAN_TO_LOCAL rule 10 state 'established'
set firewall ipv4 name WAN_TO_LOCAL rule 10 state 'related'
set firewall ipv4 name WAN_TO_LOCAL rule 20 action 'accept'
set firewall ipv4 name WAN_TO_LOCAL rule 20 description '上流ピアからのインバウンドBGPを許可'
set firewall ipv4 name WAN_TO_LOCAL rule 20 protocol 'tcp'
set firewall ipv4 name WAN_TO_LOCAL rule 20 destination port '179'
set firewall ipv4 name WAN_TO_LOCAL rule 20 source address '198.51.100.1'
# セキュリティゾーンへインターフェースを割り当て
set firewall zone WAN interface 'eth0'
set firewall zone LAN interface 'eth1'
set firewall zone LOCAL local-zone
# ゾーンペアに方向性フィルタリングポリシーを適用
set firewall zone LAN from WAN firewall name 'WAN_TO_LAN'
set firewall zone WAN from LAN firewall name 'LAN_TO_WAN'
set firewall zone LOCAL from WAN firewall name 'WAN_TO_LOCAL'
commit
save
3. 送信元NAT(IPマスカレード)の設定
プライベートサブネット10.100.0.0/24内のワークロードがWANリンク経由で外部ネットワークにアクセスするには、アドレス変換が必要です。
# WAN eth0経由で送出されるプライベートサブネットトラフィックを変換
set nat source rule 100 description '送信元インターネットマスカレード'
set nat source rule 100 outbound-interface name 'eth0'
set nat source rule 100 source address '10.100.0.0/24'
set nat source rule 100 translation address 'masquerade'
commit
save
4. エンタープライズ向けeBGPピアリングの設定
動的ルーティングにより、上流回線に障害が発生した場合でもトラフィックの迂回が可能になります。この構成では、自組織の自律システム(AS 65001)が上流ISP(198.51.100.1のAS 64512)とピアリングし、割り当てられたパブリックIPブロック(203.0.113.0/24)を広報します。
プレフィックスフィルターを設定して自社が明示的に所有するアドレスのみを広告するように制限し、上流のルーティングテーブルを保護します。
# ローカルBGP自律システム番号(AS番号)とルーターIDを設定
set protocols bgp system-as '65001'
set protocols bgp parameters router-id '198.51.100.2'
# 上流トランジットピアを設定
set protocols bgp neighbor 198.51.100.1 address-family ipv4-unicast
set protocols bgp neighbor 198.51.100.1 remote-as '64512'
set protocols bgp neighbor 198.51.100.1 description 'Transit-ISP1-Uplink'
set protocols bgp neighbor 198.51.100.1 update-source 'eth0'
# 送出ルート広告を承認済み社内サブネットのみに制限
set policy prefix-list PL-EXPORT-PREFIXES rule 10 action 'permit'
set policy prefix-list PL-EXPORT-PREFIXES rule 10 prefix '203.0.113.0/24'
# プレフィックスリストフィルターを送出ルートマップに適用
set policy route-map RM-BGP-OUT rule 10 action 'permit'
set policy route-map RM-BGP-OUT rule 10 match ip address prefix-list 'PL-EXPORT-PREFIXES'
# ISPネイバーへの送出広告にルートマップをバインド
set protocols bgp neighbor 198.51.100.1 address-family ipv4-unicast route-map export 'RM-BGP-OUT'
# 静的アンカールートを生成し、プレフィックスをBGPに広報
set protocols static route 203.0.113.0/24 blackhole
set protocols bgp address-family ipv4-unicast network '203.0.113.0/24'
commit
save
5. 動作検証と運用ランブック
exitを入力して設定モードを終了します。以下の運用コマンドを実行して、ネイバーの隣接関係、アクティブなNATセッション、およびパケットドロップカウンターを検証します。
# BGPステータスがEstablishedであること、および受信プレフィックス数を確認
show bgp summary
# 上流プロバイダーへ広告しているルートを確認
show ip bgp neighbors 198.51.100.1 advertised-routes
# 負荷環境下でのアクティブなconntrackアドレス変換を確認
show nat source translations
# WAN-to-LANファイアウォールのリアルタイムパケットカウンターを監視
show firewall name WAN_TO_LAN statistics
設定ミスは起こり得るものです。メンテナンス中に未検証のルールによってトラフィックが遮断された場合でも、アプライアンスを再起動することなく、直前の正常稼働状態へ即座に復元できます。
# 記録されたコミット履歴とタイムスタンプを確認
show system commit-history
# 直前の正常な運用設定へ即座にロールバック
configure
rollback 1
commit
exit
VyOSは、Linuxの分断という弱点を取り除きつつ、その強力な制御性を最大限に提供します。トランザクション管理された設定、ネイティブFRRルーティング、ゾーンベースフィルタリングを既成のx86ハードウェア上で統合することにより、数百万円規模のサポート更新料を支払うことなく、自社のネットワーク境界を完全に自前でコントロールできるようになります。

