相互接続できる拠点間VPNゲートウェイの選び方
拠点間VPNに同一ブランドは不要です。プロトコルの機能、実際のファームウェアのリリース、暗号化スループットを確認し、そのうえでルーティングポリシーを決めます。
異なるベンダーの拠点ゲートウェイ同士でも、実装が折衝するパラメーターで一致していればトンネルは確立します。同一ブランドは必須条件ではなく、ブランドが揃っていても保証にはなりません。互換性の論点は機能とリリースにあり、容量の論点は機器がソフトウェアで担う仕事にあります。この順序で、二つの確認として扱ってください。
一覧を順にたどり、答えのない最初の項目で止めてください。
ブランドではなく、プロトコルの機能から始める
これから動かすプロトコルについて、認証方式、合意する暗号化と完全性の提案、インターフェースまたは保護トラフィックの構成、ルーティングモード、どちらかの側が NAT の背後にあるかどうかという設計要件を列挙します。いずれも実装が支えなければならない機能であり、製品ページのチェック項目ではありません。
AWS のカスタマーゲートウェイ要件は、契約をプロトコルとルーティングの義務の集合として示しているため、AWS に接続しない場合でも有用なひな型です。特定モデル向けのベンダー提供のサンプルファイルは、誰かがその組み合わせを試したという相応の証拠になります。IPsec 対応をうたう一般的なラベルは、バージョンもポリシーモデルも証明しません。マーケティングの要約ではなくリリースノートを読んでください。
データシートのラベルではなく、リリースを確認する
IKEv2 の相互接続性は折衝されたパラメーターで決まるため、問いは現在のファームウェアがどの提案を提示し受理するかです。プロトコルを一般に支える機器でも、相手側が主張する特定の組み合わせを拒否することがあります。バージョン文字列と提案一覧を両側で確認してください。
ある機能が後のファームウェア系列で入ったという注記はよくあるもので、独自のチェック項目にする価値があります。
容量は別の問いとして扱う
暗号化には処理コストがかかり、その大きさはアルゴリズムと同じくらい実装に依存します。加速経路の一部は特定のアルゴリズムや特定の転送経路にしか適用されないため、ある構成では速く、別の構成では遅いことがあります。通常の WAN スループットは暗号化トンネルのスループットではありません。実際に保護するトラフィックに合わせて機器を選定してください。
パケットサイズも重要で、カプセル化と付加的なオーバーヘッドが各パケットの運ぶペイロードを減らします。
ルーティングポリシーを明示的に決める
拠点間だからといって、選んだトラフィックだけがトンネルを使えるわけでも、すべてを通さなければならないわけでもありません。設計は特定のプライベートプレフィックスを運ぶことも、既定ルートをゲートウェイ経由にすることもできます。両端で広告するものと受理するものが一致しなければならないため、どちらかを選んで書き留めてください。ここが食い違うと、トンネルは上がっているのにネットワークが半分しか届かない状態になります。
動的ルーティングの設計では、両端でのルーティングプロトコルの対応 という条件がもう一つ加わります。
購入前に比較する項目
更新の頻度、相互接続性の証拠、構成の復旧、想定されるフェイルオーバー動作を、ピーク転送レートと並べて比較します。古い構成のまま機器が再起動したら何が起きるかを尋ねてください。使う予定の相手にExactly な相互接続性リストをベンダーが公開しているかを尋ねてください。ファームウェア更新が既定の提案を変えたとき、変更の責任が誰にあるかを尋ねてください。
ハードウェア保証は、これらのどれへの答えにもなりません。
そのうえで、群全体に広げる前に一対で試してください。トンネル一本、実際の提案、実際のルーティングモード、業務に近い転送を試すほうが、どんな仕様表よりも多くを語ります。