AWS×Palo Alto VMFWで作るVPN接続環境
>100 Views
November 20, 25
スライド概要
サードパーティー製の仮想FWアプライアンスであるPalo Alto VMFWを活用したVPN接続のフィージビリティや、セキュリティ強化のアプローチについて検証を行いました。
エヌアイデイの若手メンバーが参加し、基礎技術の習得と実践的な経験を目的とした社内の技術検証取り組みの資料です。
株式会社エヌアイデイの公式アカウントです。ソフトウェア開発、システム構築、システム運用まで幅広いICTサービスを提供する、1967年創業の独立系IT企業です。 NIDエンジニアの社内取り組みや登壇資料を共有します。
関連スライド
Meta XR SDK(V66-74)でQuestアプリを開発
あうぜん
1.1M
各ページのテキスト
AWS×Palo Alto VMFWで作る VPN接続環境 2025年11月27日 株式会社エヌアイデイ ICTデザイン事業部ANA部第2課 大野 みなみ (2年目※検証当時) Copyright(c)2025 NID All Rights Reserved ※記載されている会社名および製品名は、各社の登録商標または商標です。 ※本資料中の「Palo Alto」および「VMFW」は便宜上の略称であり、正式な製品名とは異なります。 1
参加メンバー&検証年月 ※いずれも検証当時 ICTデザイン事業部ANA部第2課 ICTデザイン事業部ANA部第2課 ICTデザイン事業部ANA部第2課 ICTデザイン事業部ANA部第2課 ICTデザイン事業部ANA部第2課 ICTデザイン事業部ANA部第2課 大野 みなみ (2年目) 内田 滉太郎 (1年目) R.T. (1年目) F.M. (1年目) M.I. (1年目) M.N. (3年目) ※2024年8月～12月検証実施 Copyright(c)2025 NID All Rights Reserved 2
➢ 目次 ➢ Copyright(c)2025 NID All Rights Reserved 検証概要 ➢ 検証目的 P.4 ➢ 結果 P.5 ➢ 総評 P.6 ➢ 参加メンバーのコメント ➢ 検証内容 P.8-9 ➢ 構成図 P.10 環境構築 ➢ AWS P.11-19 ➢ Google Cloud P.20-28 ➢ Palo Alto VMFW P.29-49 ➢ 検証 ①多重セキュリティ P.50-67 ➢ ②-1 障害発生時の接続切り替え(手動) P.68-76 ➢ ②-2 障害発生時の接続切り替え(自動) P.77-86 ➢ P.7 ➢ 今後の展望 P.87 ➢ 今後の課題 P.88 ➢ 躓いたところ ➢ Appendix ➢ GREトンネル P.97 ➢ BGP P.98 ➢ IPsec VPN P.99 ➢ DPDK P.100 ➢ 商標に関する注記 P.89-95 P.101
検証概要 ■検証目的 ① 外部ネットワークとの接続において、オプションの柔軟性に乏しく高頻度のメンテナンスなど ミッションクリティカル用途では採用しづらいAWS Site-to-Site VPNではなく、サードパーティー 製の仮想FWアプライアンスであるPalo Alto VMFWを利用したVPN接続のフィージビリティと、セ キュリティを確保するためのアプローチと有効性を確認する。 ② 閉域網接続において、Palo Alto VMFWとAWS TGW間接続でTGW Connectを用いた構成のフィージ ビリティを確認する。 ③ Palo Alto VMFWにてホットスタンバイの冗長構成を組み、通信障害を想定した経路切り替えの方 法(手動・自動)を確認する。 ④ 将来、ミッションクリティカルなネットワーク構築案件で利用する予定であるサービス、製品に おいて、事前に検証を行いナレッジを蓄積することで、今後案件を進めていく際の円滑な対応を 可能とする。 Copyright(c)2025 NID All Rights Reserved
検証概要 ■結果 ① 外部ネットワークであるGoogle CloudとPalo Alto VMFW間で、動的ルーティングによるVPN接続 のフィージビリティが確認できた。また、SGやネットワークACLを用いることでFWに到達する よりも前の段階で外部からの通信を制御でき、VMFWのポリシーと併用して多重セキュリティを 実現できることが確認できた。 ② Palo Alto VMFWとAWS TGW間にて、TGW connectを用いた動的ルーティングによる通信のフィー ジビリティが確認できた。 ③ IFを付け替えることで、自動フェイルオーバー、手動での切り替えが共に可能であることが確認 できた。また、自動の場合は1分30秒、手動の場合は8分20秒で経路の切り替えが完了し、通信 が復活することを確認できた。 ④ TGW connectや、Palo Alto VMFWなどをデプロイした経験や実績が少ないこと、またPalo Alto公 式ドキュメントが英語しかなく、個人ブログやwebサイトなどの参考資料もあまりない中で、そ れぞれの環境やサービス毎の設定内容や考慮事項をまとめた日本語の資料を作成、ナレッジをま とめることができた。 Copyright(c)2025 NID All Rights Reserved
検証概要 ■総評 十分実現可能な構成であり、高セキュリティかつコントローラビリティに優れた構成のハブ環境を提 供することが可能となるため、ソリューションの幅が広がる。 また、ハブ環境の接続設計・構築から運用までの一貫したソリューションを1つのサービスとして提 供することができるため、環境構築時の一時的な利益に留まらず、環境提供後の運用による継続的な 利益の確保が期待できる。 Copyright(c)2025 NID All Rights Reserved
検証概要 ■参加メンバーのコメント 技術的な知識不足で躓くことも多く、調べては検証を繰り返していく中で新しい知識が身につき、ま た既存の知識への理解が深まっていった。多くの人に技術的なアドバイスをいただき、課題解決へ向 けたアプローチ方法を学び、またPalo Alto Networksの方とも連絡を取り合うことで、内部外部問わず コミュニケーションをとることで検証を無事終えることができ、多くの人に支えられ成功した検証だ と考える。 また、推進メンバーとして短期間かつ簡易的だがチームを運営するという貴重な経験ができた。 しかし、検証を進めることばかりに集中してしまい、検証参加メンバーとのコミュニケーション不足 や、進捗管理や報連相の「報告」「連絡」をおろそかにしてしまうなど、今後の改善点も多くあった。 Copyright(c)2025 NID All Rights Reserved
検証内容 ■検証内容 ①多重セキュリティ NG FW側でポリシーを設定するだけでなく、ポリシー前の段階での脆弱性対策として、AWS側にてセ キュリティグループ（SG）やネットワークACLを用いた二重の防御策を行う。 セキュリティグループ（SG）やネットワークACLにて制御している通信と、FWにて制御している通 信、AWS側とFW側の両方で制御している通信を用意し、それぞれの疎通結果を確認する。 ネットワークACL サブネットに関連付けることで、インス タンスに到達する前に通信をブロック Copyright(c)2025 NID All Rights Reserved セキュリティグループ(SG) インスタンスに関連付けることで、FWポ リシーではじかれる前に通信をブロック
検証内容 ■検証内容 ②障害発生時の通信経路切り替え 主系がダウンした場合、IPフローティングによって手動でIPアドレスを付け替えることで、従系の VMFWにIPsecトンネルを付け替える。 HA構成を組んでいる主系、従系にて自動フェイルオーバーを実行する。 IFの切り替えは、手動または自動で行う Copyright(c)2025 NID All Rights Reserved
検証概要 ■構成図 192.0.3.0/24 10.0.0.4 10.1.0.53 10.1.0.20 192.168.1.1 10.0.0.0/24 192.168.1.4 10.1.0.0/24 192.168.1.0/28 Copyright(c)2025 NID All Rights Reserved
AWS環境の構築 ①VPCとサブネットの作成 ②疎通確認用EC2の作成 ③TGWとTGWATMの作成 ④IGWの作成 ⑤VPCルートテーブル、 TGWルートテーブルの設定 ⑥VMFWの作成 ⑦NIFの作成、EIPをNIFに割当 ⑧Connectピアの作成 Copyright(c)2025 NID All Rights Reserved 本資料では今回の構成において最も重要な ⑤～⑥に重点を置いて説明をしていきます。
AWS構成図 AWS Cloud Virtual private cloud (VPC) Virtual private cloud (VPC) Route table Route table Availability Zone Availability Zone Private subnet Attachment Private subnet Route table AWS Transit Gateway Public subnet VMFW Attachment Instance Elastic network interface Internet gateway Connect ピア Instance Instance VMFW 10.0.0.0/24 Copyright(c)2025 NID All Rights Reserved 10.1.0.0/24
AWS構成図 ①VPCとサブネットの作成 ⑤VPCルートテーブルの設定 ⑤VPCルートテーブルの設定 AWS Cloud ⑤TGWルートテーブルの設定 Virtual private cloud (VPC) Virtual private cloud (VPC) Route table Route table Availability Zone ⑥VMFWの作成 Private subnet Private subnet ③TGWとTGWATMの作成 Attachment Route table AWS Transit Gateway Availability Zone Public subnet Attachment Instance Connect ピア Instance Instance ⑧Connectピアの作成 ④IGWの作成 VMFW Elastic network interface Internet gateway ⑦NIFの作成、EIPをNIF に割当 VMFW ②疎通確認用EC2の作成 10.0.0.0/24 Copyright(c)2025 NID All Rights Reserved 10.1.0.0/24
AWS ルートテーブルの設定 AWS Cloud Virtual private cloud (VPC) Virtual private cloud (VPC) Route table Route table Availability Zone Availability Zone Private subnet VPCルートテーブル Private subnet Public subnet Route table 宛先 nexthop TGWルートテーブル 10.0.0.4/24 Local 宛先 Attachment 10.1.0.0/24 TGW 192.168.1.0/28 TGW 0.0.0.0/0 AWS Transit Gateway Attachment Connect ピア IGW Instance VMFW nexthop Instance Copyright(c)2025 NID All Rights Reserved nexthop 宛先 Elastic network Internet gateway 10.0.0.4/24 TGW ATM 10.1.0.0/24 interface 192.168.1.0/28 TGW ATM 193.0.3.0/24 TGW 192.168.1.0/28 Instance Connect ATM 10.0.0.0/24 TGW 0.0.0.0/0 IGW VMFW 10.0.0.0/24 VPCルートテーブル Local 10.1.0.0/24
AWS VMFWの作成 AWS Cloud Virtual private cloud (VPC) Virtual private cloud (VPC) Route table Route table Availability Zone Availability Zone Private subnet Attachment Private subnet Route table AWS Transit Gateway VMFW Attachment Marketplaceより、以下製品を利用 Connect ピア AMI：ami-0867169f74bdc995d Instance Public subnet Instance Elastic network interface Internet gateway Instance VMFW 10.0.0.0/24 Copyright(c)2025 NID All Rights Reserved 10.1.0.0/24
AWS NIFの作成 VMFW1号機 IF 用途 Ethernet0 管理用コンソールIF(1号機) HA1構成用 Ethernet1/1 HA2構成用 Ethernet1/2 GREトンネル用IF AWS Cloud Virtual private cloud (VPC) Virtual private cloud (VPC) Route table Availability Zone Ethernet1/3 Private subnet Private subnet Route table Attachment VMFW2号機 Instance Copyright(c)2025 NID All Rights Reserved Attachment IPsecトンネル用 Public subnet EIPの関連付け Instance Elastic network interface Internet gateway 用途 Connect ピア Ethernet0 管理用コンソールIF(2号機) HA1構成用 Ethernet1/1 HA2構成用 10.0.0.0/24 Availability Zone VMFW AWS Transit Gateway IF Route table Instance VMFW 10.1.0.0/24
AWS Connectピアの作成① VPC ＞ Transit Gateway アタッチメント ■Transit Gateway ID →事前に作成したTransit Gatewayを選 択 ：vm-kensho-tgw ■アタッチメントタイプ ：[Connect] ■Connect アタッチメント →事前に作成したVMFW側のアタッチ メントを選択 ：vm-kensho-tgw-atm-fw Copyright(c)2025 NID All Rights Reserved
AWS Connectピアの作成② ■Transit Gateway GRE アドレス →事前に作成したTransit Gateway CIDRを指定 ：192.0.3.0/24 ※上記サブネット内から、利用可能なIPアドレスが1つ 払い出される ■ピア GRE アドレス →VMFW側のEthernet1/2(GREトンネル用IF)のアドレ スを指定 ：10.1.0.53 ■BGP 内部 CIDR ブロック IPv4 →BGPにて利用するIPアドレスを/29で指定 ：169.254.9.0/29 ※割り当てられるCIDRブロックに制限があるので注意 参照：https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-connect.html ■ピア ASN →VMFW側のASNを指定 ：64515 Copyright(c)2025 NID All Rights Reserved
AWS Connectピアのパラメータ 名前 test1 Connect ピア ID Connect アタッチメント ID Transit Gateway GRE アドレス 192.0.3.56 ピア GRE アドレス 10.1.0.53 BGP 内部 CIDR ブロック 169.254.9.0/29 Transit Gateway ASN 64512 ピア ASN 64515 ピア BGP アドレス 169.254.9.1 Transit Gateway BGP 1 アドレス 169.254.9.2 Transit Gateway BGP 2 アドレス 169.254.9.3 Copyright(c)2025 NID All Rights Reserved
Google Cloud環境の構築 ①VPCとサブネットの作成 ②Compute Engineの作成 ③Cloud Routerの作成 ④Cloud VPN GWの作成 ⑤ピア VPN GWの作成 ⑥Cloud VPNトンネル、BGPの作成 Copyright(c)2025 NID All Rights Reserved 本資料では今回の構成において最も重要な ④～⑥に重点を置いて説明をしていきます。
Google Cloud構成図 Google Cloud Tokyo Region VPC ZoneA Cloud VPN VGW Cloud Router Compute Engine 192.168.1.0/28 Copyright(c)2025 NID All Rights Reserved
Google Cloud構成図 Google Cloud ①VPCとサブネットの作成 Tokyo Region VPC ④Cloud VPN GWの作成 ⑤ピア VPN GWの作成 ZoneA Cloud VPN VGW Cloud Router Compute Engine ⑥Cloud VPNトンネル、BGPの作成 ②Compute Engineの作成 ③Cloud Routerの作成 192.168.1.0/28 Copyright(c)2025 NID All Rights Reserved
Google Cloud Cloud VPN GWの作成 ネットワーク接続 ＞ VPN ＞ CLOUD VPNゲートウェイ ＞ VPNゲートウェイを作成 ■VPNゲートウェイの名前 →任意の名前：vm-kensho-vgw ■ネットワーク →事前に作成したCompute Engineのある VPCを選択 ：vm-kensho-gcp ■リージョン →ネットワークを構築するリージョンを選 択 ：asia-northeast1(東京) Copyright(c)2025 NID All Rights Reserved
Google Cloud ピア VPN GWの作成 ネットワーク接続 ＞ VPN ＞ ピアVPNゲートウェイ ＞ ピアVPNゲートウェイの作成 ■名前 →任意の名前：vm-kensho-peer ■インタフェース →物理ピアゲートウェイのインターフェー ス数を選択 ：1つのインタフェース VMFW側のVPN ゲートウェイとなる ethernetインターフェース IP アドレスを追 加 ：3.114.130.94 Copyright(c)2025 NID All Rights Reserved
Google Cloud Cloud VPNトンネルの作成① ネットワーク接続 ＞ VPN ＞VPNトンネルを作成 ■ピアVPNゲートウェイ →接続先の環境を選択 ：[オンプレミス、またはGoogle Cloud 以外] ■リージョン →VPNトンネルを構築するリージョン ：asia-northeast1(東京) ■VPNゲートウェイの名前 →事前に作成したVPNゲートウェイを選択 ：vm-kensho-vgw Copyright(c)2025 NID All Rights Reserved
Google Cloud Cloud VPNトンネルの作成② ■高可用性 →VPNトンネルをいくつ作成するかを選択 ：[VPNトンネルを1つ作成する] ■Cloud Router →事前に作成したCloud routerを選択 ：vm-router ■VPNトンネルの編集 →関連付けられているCloud VPNゲートウェイインタフェース ：0 : 34.157.70.106 →関連付けられているピア VPNゲートウェイインタフェース ：0 : 3.114.130.94 ■IKEバージョン ：IKEv2 ■IKE事前共有キー ：tunnel1kensho ※VMFWにてIKEゲートウェイを作成する際に使うので、保管しておく Copyright(c)2025 NID All Rights Reserved
Google Cloud BGPの作成 ■名前 →任意の名前：vm-kensho-1-bgp ■ピアASN →VMFW側のASN：64515 ■アドバタイズされたルートの優先度 →デフォルト ※ Google Cloudのデフォルト値は以下 ・キープアライブ間隔：20秒 ・ホールドタイマー：キープアライブ間隔×3秒 参照： https://cloud.google.com/network-connectivity/docs/router/howto/managing-bgp-timers?hl=ja Copyright(c)2025 NID All Rights Reserved
Google Cloud Cloud VPNトンネルのパラメータ 名前 vm-kensho-1 リモートピアゲートウェイ(名前) vm-kensho-peer リモートピアゲートウェイ(IPアドレス) 3.114.130.94 Cloud VPNゲートウェイ(名前) vm-kensho-vgw Cloud VPNゲートウェイ(IPアドレス) インターフェース：0 34.157.70.106 ルーティングタイプ 動的(BGP) IKEバージョン IKEv2 BGPセッション(名前) vm-kensho-1-bgp BGPセッション(ピアASN) 64515 BGPセッション(Cloud RouterのBGP IP) 169.254.64.165 BGPセッション(ピアBGP IP) 169.254.64.166 Copyright(c)2025 NID All Rights Reserved
VMFWの設定 ①ゾーンの作成 ②トンネルインターフェースの作成 ③Ethernetインターフェースの作成 ④HA用インターフェースの作成 ⑤GREトンネルの作成 ⑥IPsec暗号プロファイルの作成 ⑦IKE暗号プロファイルの作成 ⑧IKEゲートウェイの作成 ⑨IPsecトンネルの作成 ⑩ルートテーブルの設定 ⑪BGPピアの作成 Copyright(c)2025 NID All Rights Reserved
VMFW ゾーンの作成 NETWORK ＞インターフェース ＞ゾーン ＞追加 Trust →内部でのやり取りをするIF(GREトンネル用 IF)でtrustゾーンを指定 Copyright(c)2025 NID All Rights Reserved Untrust →外部とのやり取りをするIF(IPsecトンネル用IF) でuntrustゾーンを指定
VMFW トンネルインターフェースの作成① GREトンネル用のものと、IPsecトンネル用のものを作成する。 GREトンネル用 NETWORK ＞インターフェース ＞トンネル >設定 ■インターフェース名 →任意の数字：1 ■インターフェースの割り当て先 論理ルーター：default セキュリティゾーン：trust IPsecトンネル用 ■インターフェース名 →任意の数字：22 ■インターフェースの割り当て先 論理ルーター：default セキュリティゾーン：untrust Copyright(c)2025 NID All Rights Reserved
VMFW トンネルインターフェースの作成② GREトンネル用のものと、IPsecトンネル用のものを作成する。 NETWORK ＞インターフェース ＞トンネル >IPv4 GREトンネル用 ■IPv4 AWSにて作成したConnectピアの 「ピア BGP アドレス」を記載 ：169.254.9.1/29 IPsecトンネル用 ■IPv4 Google Cloudにて作成したCloud VPN トンネルの「ピア BGP IP」を記載 ： 169.254.64.166/30 Copyright(c)2025 NID All Rights Reserved
VMFW トンネルインターフェースの作成③ NETWORK ＞インターフェース ＞トンネル >詳細 GREトンネル用 IPsecトンネル用 ■管理プロファイル →事前に作成したものを選択 ：test2 ■MTU ：デフォルト Copyright(c)2025 NID All Rights Reserved
VMFW Ethernetインターフェースの作成① GREトンネル用 GREトンネル用のものと、IPsecトンネル用のものを作成する。 ■インターフェースタイプ ：レイヤー３ NETWORK ＞インターフェース ＞Ethernet >設定 ■インターフェース名 ：Ethernet1/2 ※EC2インスタンスと同じインデックスのインター フェースを選ぶ必要がある ■インターフェースの割り当て先 論理ルーター：default セキュリティゾーン：trust IPsecトンネル用 ■インターフェースタイプ ：レイヤー３ ■インターフェース名 ：Ethernet1/3 ※EC2インスタンスと同じインデックスのインター フェースを選ぶ必要がある Copyright(c)2025 NID All Rights Reserved ■インターフェースの割り当て先 論理ルーター：default セキュリティゾーン：untrust
VMFW Ethernetインターフェースの作成② GREトンネル用のものと、IPsecトンネル用のものを作成する。 NETWORK ＞インターフェース ＞Ethernet >IPv4 GREトンネル用 ■IPv4 AWSにて作成したConnectピアの 「ピア GRE アドレス」を記載 ：10.1.0.53/28 IPsecトンネル用 ■IPv4 AWSにて作成したIPsecトンネル用 IF (EIPが関連付けられているNIF)のIPア ドレスを記載 ：10.1.0.20/28 Copyright(c)2025 NID All Rights Reserved
VMFW Ethernetインターフェースの作成③ NETWORK ＞インターフェース ＞Ethernet >詳細 GREトンネル用 IPsecトンネル用 ■管理プロファイル →事前に作成したものを選択 ：test2 ■MTU ：デフォルト Copyright(c)2025 NID All Rights Reserved
VMFW HA用インターフェースの作成 NETWORK ＞インターフェース ＞Ethernet HA2用 ■インターフェースタイプ ：HA Copyright(c)2025 NID All Rights Reserved
VMFW GREトンネルの作成 ■インターフェース →事前に作成したインターフェースを選択 ：ethernet1/2 NETWORK ＞GREトンネル ■ローカルアドレス ：10.1.0.53 ■ピアアドレス →AWS側の「Transit Gateway GRE アドレス」を記載 ：192.0.3.56 ■トンネルインターフェース →事前に作成したトンネルIFを選択 ：tunnel.1 ■TTL ：2 ■キープアライブ 間隔(sec)：10 再試行：3 ホールド タイマー：30 ※TTLとキープアライブはAWS側の条件に合わせて設定 Copyright(c)2025 NID All Rights Reserved 参照：https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgwconnect.html
VMFW IKE暗号プロファイルの作成 ■DHグループ ：group20 NETWORK ＞ネットワークプロファイル ＞IKE暗号 ■認証 ：non-auth ■暗号化 ：aes-256-gcm ■タイマー キーの有効期間：時間 ：10 IKEv2多重認証：デフォルト 参照： Palo Alto https://docs.paloaltonetworks.com/networksecurity/ipsec-vpn/administration/set-up-site-tosite-vpn/define-cryptographic-profiles/define-ikecrypto-profiles Google Cloud https://cloud.google.com/networkconnectivity/docs/vpn/concepts/supported-ikeciphers?hl=ja Copyright(c)2025 NID All Rights Reserved
VMFW IPsec暗号プロファイルの作成 ■IPsecプロトコル ：ESP NETWORK ＞ネットワークプロファイル ＞IPsec暗号 ■暗号化 ：aes-256-gcm ■認証 ：sha256 ■DHグループ ：group20 ■ライフタイム ：時間 ：3 参照： Palo Alto https://docs.paloaltonetworks.com/network-security/ipsecvpn/administration/set-up-site-to-site-vpn/definecryptographic-profiles/define-ipsec-crypto-profiles Copyright(c)2025 NID All Rights Reserved Google Cloud https://cloud.google.com/networkconnectivity/docs/vpn/concepts/supported-ikeciphers?hl=ja
VMFW IKEゲートウェイの作成① NETWORK ＞ネットワークプロファイル ＞IKEゲートウェイ ＞全般 ■バージョン ：IKEv2 only mode ※Google CloudのCloud VPNトンネルと整合性を 合わせる。 ■インターフェイス →IPsecトンネル用のインターフェイスを選択 ：ethernet1/3 ■ピアアドレス Cloud VPN ゲートウェイの「IPアドレス」を記載 ：34.157.70.106 ■認証 ：Pre-Shared Key ■事前共有鍵 ： tunnel1kensho ※Google CloudのCloud VPNトンネル作成時に 使ったものと同じもの Copyright(c)2025 NID All Rights Reserved
VMFW IKEゲートウェイの作成② NETWORK ＞ネットワークプロファイル ＞IKEゲートウェイ ＞詳細オプション ■IKE暗号プロファイル →事前に作成したものを選択 ：test-ike Copyright(c)2025 NID All Rights Reserved
VMFW IPsecトンネルの作成① NETWORK ＞IPsecトンネル ＞全般 ■トンネルインターフェース ：tunnel.22 ※事前に作成したトンネルインターフェースを指定 ■タイプ ：自動キー ■アドレスタイプ ：IPv4 ■IKEゲートウェイ ：GoogleCloud1-ike ※事前に作成したIKE ゲートウェイを指定 ■IPsec暗号プロファイル ：test-ipsec ※事前に作成したIPsec暗号を指定 ■トンネルモニター → Google Cloudの「Cloud RouterのBGP IP」を記載。 宛先 IP：169.254.64.165 プロファイル：default Copyright(c)2025 NID All Rights Reserved
VMFW IPsecトンネルの作成② NETWORK ＞IPsecトンネル ＞プロキシID ＞IPv4 ■プロキシID →任意の名前 ： test ■ローカル →VMFW側のローカルサブネット ：10.1.0.0/24 ■リモート →接続先のローカルサブネット ：192.168.1.0/28 ■プロトコル ：any ※ポリシーベースVPNの場合は、 このプロキシの設定は必須 Copyright(c)2025 NID All Rights Reserved
VMFW ルートテーブルの設定 NETWORK ＞ 論理ルータ ＞default ＞スタティック ■TGW-ipv4-unicast 宛先：192.0.3.0/24(AWS TGW CIDR) ネクストホップ：AWS VPCルーターのIPアドレス(Private Subnet) ■Google-Cloud-VPN-GW-ipv4-unicast 宛先：Google CloudのCloud VPNゲートウェイ ネクストホップ： AWS VPCルーターのIPアドレス(Public Subnet) ※メトリックは、目的地までの距離を示す。同じ宛先向けのルートが複数ある場合、このメトリックが 小さい方から優先的に接続が行われる。デフォルトは100。 Copyright(c)2025 NID All Rights Reserved
VMFW BGPピアの作成① NETWORK ＞ 論理ルータ ＞default ＞BGP ＞ピアグループ GREトンネル用 ■ピアアドレス peer1 →AWSの「Transit Gateway BGP 1 アドレス」 ：169.254.9.2 Peer2 →AWSの「Transit Gateway BGP 2アドレス」 ：169.254.9.3 ■ローカルアドレス →AWSの「ピアBGPアドレス」を記載 ：169.254.9.1/29 ■ピアAS →AWSの「Transit Gateway ASN」を記載 ：64512 Copyright(c)2025 NID All Rights Reserved
VMFW BGPピアの作成② NETWORK ＞ 論理ルータ ＞default ＞BGP ＞ピアグループ IPsecトンネル用 ■ピアアドレス peer1 → Google Cloudの「 Cloud RouterのBGP IP 」 ：169.254.64.165 ■ローカルアドレス →Google Cloudの「ピアBGP IP 」を記載 ：169.254.9.1/29 ■ピアAS → Google CloudのCloud Routerにて割り当てら れているGoogle ASNを記載 ：65534 Copyright(c)2025 NID All Rights Reserved
GREトンネルの状態確認 VMFW AWS TGWのもつルートがBGPにより広報されて いることを確認。 AWS Copyright(c)2025 NID All Rights Reserved TGW connectピアのステータスがUpになってい ることを確認。
IPsecトンネルの状態確認 VMFW Google Cloud AWS TGWのもつルートがBGPにより広報されて いることを確認。 Google Cloudにて、VPNトンネルのステータス、BGPセッションのステー タスが確立されていることを確認。 AWS IPsecトンネルが確立されたことで、TGWのルートテーブルにGoogle Cloud側のルートがVMFWから広報されていることを確認。 Copyright(c)2025 NID All Rights Reserved
検証①多重セキュリティ検証結果 内部→外部への通信 Copyright(c)2025 NID All Rights Reserved
検証①多重セキュリティ 想定される結果 FWポリシー ネットワークACL 通信① 〇 〇 通信② ✕ ✕ 通信③ 〇 ✕ 通信④ ✕ 〇 左記の通信において、VMFWでのログ確認、 疎通できるかできないかを確認 ✕…deny、〇…allow 通信① 疎通可能、FWにてallowログあり 通信② 疎通不可、FWログなし 通信③ 疎通不可、FWログなし 通信④ 疎通不可、FWにてdenyログあり Copyright(c)2025 NID All Rights Reserved
検証①多重セキュリティ 通信① ネットワークACLとVMFWどちらでも送信元制御をしていない通信 許可 VMFWポリシー ネットワークACL 許可 許可 VMFW CLI 疎通OK 想定通り、疎通可能であること、VMFWにて allowログがあることを確認できた。 ※証跡のログの時間には若干のラグがあります Copyright(c)2025 NID All Rights Reserved
検証①多重セキュリティ 通信② 送信元(10.0.0.4)を、ネットワークACLのインバウンドルールにて拒否、VMFWのポリシ ーでも拒否した通信 VMFWポリシー 拒否 拒否 ネットワークACL 拒否 VMFW CLI 疎通NG 疎通結果はNG、しかし、想定外の結果としてVMFWにて通信 がdropしたログが残っていた。(FWポリシーにてはじかれた) ※証跡のログの時間には若干のラグがあります Copyright(c)2025 NID All Rights Reserved
検証①多重セキュリティ 通信② Cloud Watch CloudWatchにて、内部の通信の出入口であるIF(10.1.0.53)のログを確認したところ、ログにて記録されている送信元IPアドレス が10.0.0.4ではなくAWS側のGREトンネルインタフェースのIPアドレスである192.0.3.56となっていた。 同様に、送信先IPアドレスも最終的な目的地である192.168.1.4ではなく、VMFW側のGREトンネルインタフェースのIPアドレス である10.1.0.53となっていることを確認。 → GREトンネリングによってカプセル化されているためと推測。 ネットワークACL ネットワークACLにて制御する通信を上記のように修正し、再度pingによる疎通確認を行い疎通不可であること、CloudWatchに て192.0.3.56の通信がREJECTされること、VMFW側ではログが記録されないことを確認する。 Copyright(c)2025 NID All Rights Reserved 拒否
検証①多重セキュリティ 通信② CLI Cloud Watch 疎通NG 拒否 VMFW CloudWatchにて、該当通信がREJECTされているログを確認し、VMFWにてCloudWatchのログがとれた前後の時間のログ (12/04 23:52:21)を確認し、pingによる通信ログがないことを確認できた。(VMFWまでpingが到達していない) Copyright(c)2025 NID All Rights Reserved
検証①多重セキュリティ 通信③ 送信元(192.0.3.56)をネットワークACLのインバウンドルールにて拒否、送信元(10.0.0.4)を VMFWのポリシーで許可した通信 許可 VMFWポリシー ネットワークACL 拒否 Cloud Watch VMFW CLI Copyright(c)2025 NID All Rights Reserved 疎通NG 想定通り、疎通不可であること、CloudWatchにてREJECTのログ、 VMFWにて12/05 00:12:50前後のログがないことを確認できた。 ※証跡のログの時間には若干のラグがあります
検証①多重セキュリティ 通信④ 送信元(192.0.3.56)をネットワークACLのインバウンドルールにて許可、送信元(10.0.0.4)を VMFWのポリシーで拒否した通信 VMFWポリシー 拒否 許可 ネットワークACL Cloud Watch 許可 VMFW CLI 拒否 疎通NG 想定通り、疎通不可であること、CloudWatchにてACCEPTのログ、 VMFWにてdenyログがあることを確認できた。 Copyright(c)2025 NID All Rights Reserved ※証跡のログの時間には若干のラグがあります
検証①多重セキュリティ検証結果 外部→内部への通信 Copyright(c)2025 NID All Rights Reserved
検証①多重セキュリティ 通信⑤ 左記の通信において、VMFWでのログ確認、 疎通できるかできないかを確認 ✕…deny、〇…allow 通信⑤ 疎通可能、FWにてallowログあり Copyright(c)2025 NID All Rights Reserved FWポリシー ネットワークACL 通信⑤ 〇 〇 通信⑥ ✕ ✕ 通信⑦ 〇 ✕ 通信⑧ ✕ 〇
検証①多重セキュリティ 通信⑤ VMFWポリシー 許可 ネットワークACL 許可 Cloud VPN VGWのIP 許可 Cloud Watch Cloud VPN VGWのIP Cloud VPN VGWのIP VMFW CLI 許可 疎通OK ※CLIの証跡を取り忘れたので、同じ条件でPingを飛ばした別日時のログ※ 想定通り、疎通可能であること、VMFWに てallowログがあることを確認できた。 Copyright(c)2025 NID All Rights Reserved ※証跡のログの時間には若干のラグがあります
検証①多重セキュリティ 通信⑥ 左記の通信において、VMFWでのログ確認、 疎通できるかできないかを確認 ✕…deny、〇…allow 通信⑥ Copyright(c)2025 NID All Rights Reserved 疎通不可、FWログなし FWポリシー ネットワークACL 通信⑤ 〇 〇 通信⑥ ✕ ✕ 通信⑦ 〇 ✕ 通信⑧ ✕ 〇
検証①多重セキュリティ 通信⑥ VMFWポリシー 拒否 ネットワークACL 拒否 Cloud VPN VGWのIP Cloud Watch 拒否 Cloud VPN VGWのIP Cloud VPN VGWのIP VMFW CLI Copyright(c)2025 NID All Rights Reserved 疎通NG 想定通り、疎通不可であること、CloudWatchにてREJECTの ログ、VMFWにてログがないことを確認できた。 ※証跡のログの時間には若干のラグがあります
検証①多重セキュリティ 通信⑦ 左記の通信において、VMFWでのログ確認、 疎通できるかできないかを確認 ✕…deny、〇…allow 通信⑦ Copyright(c)2025 NID All Rights Reserved 疎通不可、FWログなし FWポリシー ネットワークACL 通信⑤ 〇 〇 通信⑥ ✕ ✕ 通信⑦ 〇 ✕ 通信⑧ ✕ 〇
検証①多重セキュリティ 通信⑦ VMFWポリシー 許可 ネットワークACL 拒否 Cloud VPN VGWのIP Cloud Watch 拒否 Cloud VPN VGWのIP Cloud VPN VGWのIP VMFW CLI 疎通NG Copyright(c)2025 NID All Rights Reserved 想定通り、疎通不可であること、CloudWatchにてREJECTの ログ、VMFWにてログがないことを確認できた。 ※証跡のログの時間には若干のラグがあります
検証①多重セキュリティ 通信⑧ 左記の通信において、VMFWでのログ確認、 疎通できるかできないかを確認 ✕…deny、〇…allow 通信⑧ 疎通不可、FWにてdenyログあり Copyright(c)2025 NID All Rights Reserved FWポリシー ネットワークACL 通信⑤ 〇 〇 通信⑥ ✕ ✕ 通信⑦ 〇 ✕ 通信⑧ ✕ 〇
検証①多重セキュリティ 通信⑧ 拒否 VMFWポリシー ネットワークACL 許可 Cloud VPN VGWのIP Cloud Watch 許可 Cloud VPN VGWのIP Cloud VPN VGWのIP VMFW CLI Copyright(c)2025 NID All Rights Reserved 拒否 疎通NG 想定通り、疎通不可であること、CloudWatchにてREJECTの ログ、VMFWにてdenyログがあることを確認できた。 ※証跡のログの時間には若干のラグがあります
検証①多重セキュリティ Security GroupでネットワークACLによる同様の検証を行ったが、ネットワークACLと同様 の結果となった。(証跡の記載は割愛) 【結果】 内部から外部への通信を制御する場合、トラフィックはすでにカプセル化されてしまっ ているため、GREトンネルのアンダーレイのIPアドレスを送信元として指定することで、Security GroupやネットワークACLを用いたVMFW前段での送信元IPアドレスによる通信制御が可能。 外部から内部への通信を制御する場合、特定の送信元IPアドレスのみを許可したり、また は拒否することが可能。 外部から内部への通信において、SGやネットワークACLを用いたFWの前段での送 信元IPアドレスによる通信制御は可能である。 結果として、FWポリシーとAWSのSGとネットワークACLを併用した多重セキュリティの 実現は可能であると言える。 Copyright(c)2025 NID All Rights Reserved
検証②-1障害発生時の接続切り替え(手動) Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(手動) 手動付け替え 手動付け替え ①EC2からの連続ping疎通を開始。 ②1号機(active)を停止。 ③1号機に割り当てられているNIFをデタッチし、 2号機にアタッチ。 ④EC2インスタンスの詳細から、NIFが1号機から2号機へ付け替えられていることを確認。 ⑤VMFW 2号機にて、VMFWの再起動を実施。 ⑥pingのログを注視し、ログの出力が一時停止し、その後再開することを確認。 ⑦2号機のwebUIにアクセスできることを確認し、 2号機のインタフェースの状態が、全てUPになっている ことを確認。 ⑧2号機のwebUIにて、VMFW側で該当通信のログが出力されていることを確認。 Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(手動) 手順① vm-fw-1(FW1号機) VMFWをデプロイしているEC2インスタンスを停止する。 Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(手動) 手順② EC2 ＞ インスタンス ＞ ネットワークインターフェース ①FW1号機のethernet1/2のアドレス(10.1.0.53)をデタッチし、 FW2号機のethernet1/2にアタッチする。 ②FW1号機のethernet1/3のアドレス(10.1.0.20)をデタッチし、 FW2号機のethernet1/3にアタッチする。 Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(手動) 手順③ IF付け替え後、AWSのEC2インスタンスの詳細にて想定通りの結果になっていることを確認する。 Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(手動) 手順④ vm-fw-2(FW2号機) DEVICE ＞セットアップ ＞操作 [デバイスの再起動]をクリックし、FWを再起動する。 Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(手動) 結果 ※ログの記載時間はUTC +9時間でJST 07:50:17にてログが途切れ、07:58:33からログが再開している。 この間に1号機→2号機へ通信が変わったと考えられる。 通信経路が切り替わってから再開までにかかった時間は8分16秒。 Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(手動) 結果 2号機VMFWログ ～16:50:25までは1号機にて通信ログが確認できた。 1号機を一時停止後、ログが一旦途切れてからは、16:58:45以降のping通信ログが2号機にて確認できた。 通信経路が切り替わってから再開までにかかった時間は8分20秒。 1号機VMFWログ 後から1号機を再起動してログを確認し、ログの出力が16:50:25で止まっていたことを確認できた。 Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(手動) 確認 2号機VMFW 再起動後のVMFW2号機にて、IFの状態が想定通りになっていることを確認できた。 Copyright(c)2025 NID All Rights Reserved
検証②-2障害発生時の接続切り替え(自動) Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(自動) 自動付け替え 自動付け替え ①Active-passiveでHA構成を組み、フェールオーバーモードをinterface moveにて設定。 ②FW VMをデプロイしているEC2インスタンスにて、新規IAMロールを割り当てる。 ③EC2からの連続ping疎通を開始。 ④1号機(active)を手動で停止。 ⑤pingのログを注視し、ログの出力が一時停止し、その後再開することを確認。 ⑥1号機のWebUIにてVMFW側で該当通信のログ出力が止まっていること、また、2号機のWebUIにてVMFW 側で該当通信のログが出力されていることを確認。 ⑦1号機に割り当てられていたインタフェースが、2号機に付け替えることをAWS、VMFWの両方で確認。 Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(自動) 手順① 1号機VMFW 2号機VMFW WebUIにて、FW1号機、FW2号機にてHAの設定を行い有効化する。 Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(自動) 手順② CLIにて、上記コマンドでフェールオーバーモードをinterface moveに変更する。 DPDK(Data Plane Development Kit) をoffにする。 (DPDKはinterface moveではサポート対象外のため) Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(自動) 手順③ AWSにて、VMFWをデプロイしているEC2インスタンス2台に、 上記の許可ポリシーを持ったIAMロールを作成し割り当てる。 Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(自動) 手順④ ■vm-fw-1(FW1号機) VMFWデプロイしているEC2インスタンスを停止する。 Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(自動) 結果 疎通用インスタンスのpingログ ※ログの記載時間はUTC +9時間でJST 11:03:37にてログが途切れ、11:04:57からログが再開している。 この間に1号機→2号機へ通信が変わったと考えられる。 通信経路が切り替わってから再開までにかかった時間は1分20秒。 Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(自動) 結果 1号機VMFWログ 2号機VMFWログ ～20:02:57までは1号機にて通信ログが確認できた。 1号機を一時停止後、ログが一旦途切れてからは、 10:04:25以降のping通信ログが2号機にて確認できた。 通信経路が切り替わってから再開までにかかった時間は1分28秒。 Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(自動) 確認 手動での切り替えを行った際と同様に、AWSのEC2インスタンスの詳細を見ると、 IFが付け替えられていることが確認できた。 Copyright(c)2025 NID All Rights Reserved
検証②障害発生時の接続切り替え(自動) 確認 1号機VMFW 2号機VMFW WebUI上でも、手動での切り替えを行った際と同様にIFの状態が想定通りになっていることを確認できた。 Copyright(c)2025 NID All Rights Reserved
今後の展望 ⚫ 一貫したソリューションの提供 接続先毎の環境に合わせた専用の中継環境を用意するのではなく、ハブ環境を導入するこ とで個別の中継環境構築が不要となる。 ⚫ コントローラビリティに優れた環境の提供 重要度の高い通信が行われる環境や、トラブル発生時に迅速かつ確実な対応を求められる 場合、仮想FWアプライアンスとIPsec-VPNを用いることで、AWS Site-to-Site VPNを利用す る場合よりもコントローラビリティに優れた提案を行うことが可能となる。(AWS側でのデ バッグ不可、アップデートや影響調査のタイミングがコントロールできない等の懸念が無 くなる) Copyright(c)2025 NID All Rights Reserved
今後の課題 ⚫ Palo AltoのクラウドコンソールであるStrata Cloud Managerのライセンスをいただいたに もかかわらず、Strata Cloud Managerを用いたFW管理まで検証を行うことができなかっ たため、クラウドコンソール上でのFW管理やFW設定方法についての検証を行う。 ⚫ 手動での切り替えについて、設定反映のためにFWの再起動をした結果8分以上もかかっ てしまったため、短縮可能な方法を考え更なる検証を行う。(CLIにてコマンドでの設定更 新や、WebUI上でのIF再設定等) ⚫ NIF自体の付け替えではなく、EIPの関連付け先を変更することで通信の切り替えを行う 検証を進める。 Copyright(c)2025 NID All Rights Reserved
躓いたところ • SG、ルートテーブルの設定考慮漏れによる疎通不可 • ネットワークACLでの通信制御 • VMFWにてインタフェースがUPにならない • GREトンネルの設定 • 各サービスの用語の違いによる設定項目の判断 • IPsecトンネルの設定 Copyright(c)2025 NID All Rights Reserved
躓いたところ ・SG、ルートテーブルの設定考慮漏れによる疎通不可 【事象】 検証開始前、疎通確認用(vm-sotsu)の端末からVMFW1号 機、2号機へのpingによる疎通不可。 【原因】 インスタンスのSGによりICMPトラフィックの通信が許可 されていなかった。また、ルートテーブルにて、行きの 通信と帰りの通信のルーティング設定が適切にされてい なかった。 【解決方法】 SGにICMPプロトコルの許可設定を入れる。 各VPCにTGW向けのルーティング設定を入れる。 Copyright(c)2025 NID All Rights Reserved
躓いたところ ・ネットワークACLでの通信制御 【事象】 特定のIPアドレスにてネットワークACLをdeny設定した が、pingが通ってしまう。 【原因】 deny設定されたIPアドレスを持つNIFについて、このNIF が属するサブネットがネットワークACLに関連付けられ ておらず、ネットワークACLが機能していなかった。 【解決方法】 該当のサブネットをネットワークACL に関連付け、再度 pingを送信したところ、ネットワークACLにて制御され ていることを確認した。 Copyright(c)2025 NID All Rights Reserved 目的のサブネットが関連付けの中にない
躓いたところ ・VMFWにてインタフェースがUPにならない 【事象】 EC2インスタンス EC2インスタンス側では正常に割り当てられているものの、 VMFW上でインタフェースがUPにならない。 【原因】 インタフェースのインデックスが、EC2インスタンスと VMFWで異なっていた。 【解決方法】 EC2インスタンスでは、NIFを割り当てた順でインデック スが付与されるため、それに合わせてVMFW側のIFとIPア ドレスを設定する。 Copyright(c)2025 NID All Rights Reserved VMFW
躓いたところ ・GREトンネルの設定 【事象】 GREトンネルのトンネルインタフェースがUPせず、BGP セッションも確立されないため、TGWとVMFW間の通信が できない 【原因】 VMFW側にて、AWS TGW向けスタティックルートのネク ストホップの設定が間違っていた。 【解決方法】 ネクストホップには、GREトンネルの出入口として指定 したインタフェースが属するサブネットにおける、AWS 側の予約IPアドレス(VPCルーター用)を指定する必要が あった。ethernet1/2(10.1.0.53/28)を出入口のインタ フェースに指定したため、10.1.0.49をネクストホップと Copyright(c)2025 NID All Rights Reserved して指定した。
躓いたところ ・各サービスの用語の違いによる設定項目の判断 【事象】 AWSとGoogle Cloudにて事前に作成したGREトンネルと IPsecトンネルのパラメータを元に、Palo Alto VMFWの設 定をしていくが、名称が違うためにどの項目にどのパラ メータを入れるべきかの判断が困難であった。 【原因】 GREトンネルやIPsecトンネルのパラメータに関する知識 が不足しており、トンネルの仕組みが理解できていな かったため。 【解決方法】 トンネルの仕組みについて勉強し直し、それぞれのサー ビスの名称で対応するものと、該当するパラメータを図 にして整理した。 Copyright(c)2025 NID All Rights Reserved
躓いたところ ・IPsecトンネルの設定 【事象】 IPsecトンネルの構築において、IKEプロファイルやIPsec プロファイルの設定は正しくできているがIPsecトンネル がUPにならない。 【原因】 VMFW側にて、IPsecトンネル用のethernet1/3に割り当て るIPアドレスが間違っていた。プライベートIPアドレスで はなく、グローバルIPアドレスを割り当ててしまっていた。 【解決方法】 Ethernet1/3に割り当てるIPアドレスをグローバルIPアドレ スからプライベートIPアドレス(10.1.0.20)に修正した。 Copyright(c)2025 NID All Rights Reserved IKEゲートウェイの作成時にこのインタフェー スを参照するよう設定するので、間違っている とIKEネゴシエーションができない。
Appendix Copyright(c)2025 NID All Rights Reserved
技術要素 - GREトンネル General Routing Encapsulation トンネル ネットワークトラフィックを暗号化せずに、異なるプロトコルやネットワーク間でのデー タ転送を行うための技術。 ●プロトコルの柔軟性：複数のプロトコル（IP、非IPトラフィック）のトンネリングをサポート。 ●簡単なカプセル化：パケットのカプセル化がシンプルで、オーバーヘッドが少ない。 ●セキュリティ：追加のセキュリティプロトコル（例：IPsec）と組み合わせて使用することが一般的。 ●互換性：異なるネットワーク間の互換性を確保し、互いに接続できないネットワークを結びつける。 ●効率：ネットワークパフォーマンスに与える影響が少なく、高速なデータ転送が可能。 Copyright(c)2025 NID All Rights Reserved
技術要素 - BGP インターネットにおいて、ISPなどの相互接続時にお互いの経路情報をやり取りするため に使われる経路制御プロトコルのこと。 内部で使用するiBGPと、外部で使用するeBGPの大きく2つに分類できる。 iBGP eBGP iBGP iBGP iBGP Copyright(c)2025 NID All Rights Reserved
技術要素 - IPsec VPN Internet Protocol Security Virtual Private Network IPsec VPNは、インターネット上に仮想専用線を作り、高セキュアな通信を行う 方法の1つ。 ●暗号化：送受信されるデータを暗号化して、盗聴や改ざんを防ぐ。 ●認証：通信する両端のデバイスを相互に認証し、信頼性を確保。 ●整合性チェック：データが途中で変更されていないことを確認するための手段を提供。 IPsec VPN Act(HA) VM-Series Internet (VPN) Hot Sby(HA) VM-Series AZ-a Copyright(c)2025 NID All Rights Reserved Cloud VPN GW
技術要素 - DPDK Data Plane Development Kit データプレーン開発キット。 ネットワークデバイスのパフォーマンスを最適化するためのソフトウェアライブラリ とフレームワーク。 ●ネットワークデータの高速処理： カーネルの機能を頼ることなく必要最低限の処理を作り組むことで高速化を実現。 ●効率的なパケット転送： ネットワークカード(NIC)の利用、ハードウェアデバイスに直接アクセスできるため、効率的なパケット処理を実現。 ※NICを利用するため、専用のネットワークインタフェースを用意する必要がある。 ⇒高トラフィックな環境での利用 Copyright(c)2025 NID All Rights Reserved 参考①：https://www.intel.co.jp/content/www/jp/ja/content-details/634832/data-plane-development-kit-dpdk-video.html 参考②： https://www.lr-link.com/jp/newsdetail/669.html
商標に関する注記 • 「AWS」、「Amazon Web Services」および関連サービス名は、Amazon.com, Inc. またはその関連会社の商標です。 • 「Google Cloud」「Cloud VPN」などは、Google LLCの商標または登録商標です。 • 「Palo Alto Networks」および「VM-Series」は、Palo Alto Networks, Inc.の商標 または登録商標です。 • 本資料中の「Palo Alto」および「VMFW」は便宜上の略称であり、正式な製品名と は異なります。 Copyright(c)2025 NID All Rights Reserved
閲覧いただき、ありがとうございました。 Copyright(c)2025 NID All Rights Reserved