

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWS Site-to-Site VPN カスタマーゲートウェイデバイス
<a name="your-cgw"></a>

*カスタマーゲートウェイデバイス*は、オンプレミスネットワーク (Site-to-Site VPN 接続のユーザー側) で所有または管理している物理アプライアンスまたはソフトウェアアプライアンスです。ユーザーまたはネットワーク管理者は、Site-to-Site VPN 接続で動作するようにデバイスを設定する必要があります。

次の図は、ネットワーク、カスタマーゲートウェイデバイス、および VPC にアタッチされている仮想プライベートゲートウェイへの VPN 接続を示しています。カスタマーゲートウェイと仮想プライベートゲートウェイ間の 2 つの線は、VPN 接続のトンネルを表しています。内にデバイス障害が発生した場合 AWS、VPN 接続は自動的に 2 番目のトンネルにフェイルオーバーされ、アクセスが中断されることはありません。は、VPN 接続の定期メンテナンス AWS も随時実行します。これにより、VPN 接続の 2 つのトンネルのいずれかが一時的に無効になる場合があります。詳細については、「[AWS Site-to-Site VPN トンネルエンドポイントの置き換え](endpoint-replacements.md)」を参照してください。したがって、カスタマーゲートウェイデバイスを設定するときは、両方のトンネルを使用するように設定することが重要です。

![\[高レベルのカスタマーゲートウェイの概要\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/cgw-high-level.png)


VPN 接続を設定するステップについては、「[の使用を開始する AWS Site-to-Site VPN](SetUpVPNConnections.md)」を参照してください。このプロセス中に、 でカスタマーゲートウェイリソースを作成します。このリソースは AWS、パブリック IP アドレスなど、デバイス AWS に関する情報を に提供します。詳細については、「[AWS Site-to-Site VPN 接続のカスタマーゲートウェイのオプション](cgw-options.md)」を参照してください。のカスタマーゲートウェイリソース AWS は、カスタマーゲートウェイデバイスを設定または作成しません。このデバイスは、自分で設定する必要があります。

[AWS Marketplace](https://aws.amazon.com/marketplace/search/results/ref=brs_navgno_search_box?searchTerms=vpn) でソフトウェア VPN アプライアンスを検索することもできます。

# AWS Site-to-Site VPN カスタマーゲートウェイデバイスの要件
<a name="CGRequirements"></a>

 AWS は、ダウンロード可能な設定ファイルを提供する Site-to-Site VPN カスタマーゲートウェイデバイスを多数サポートしています。サポートされているデバイスのリスト、および設定ファイルをダウンロードする手順については、「[静的および動的ルーティング設定ファイル](example-configuration-files.md)」を参照してください。

このセクションでは、サポート対象デバイスの一覧にないデバイスを使用している場合に、そのデバイスを使用して Site-to-Site VPN 接続を確立するために満たす必要のあるデバイスの要件について説明します。

カスタマーゲートウェイデバイスの設定には、4 つの主要部分があります。次の記号は、構成の各部分を表しています。


|  |  | 
| --- |--- |
|  ![\[インターネットキー交換記号\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/IKE.png)  |  インターネットキー交換 (IKE) セキュリティアソシエーション。IPsec セキュリティアソシエーションを確立するために使用されるキーの交換に必要です。  | 
|  ![\[インターネットプロトコルのセキュリティ\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/IPsec.png)  |  IPsec セキュリティアソシエーション。これは、トンネルの暗号化、認証などを処理します。  | 
|  ![\[トンネルインターフェイス記号\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/Tunnel.png)  |  トンネルインターフェイス。トンネルを通じて送受信されるトラフィックを受け取ります。  | 
|  ![\[ボーダーゲートウェイプロトコル\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/BGP.png)  |  (オプション) Border Gateway Protocol (BGP) ピア接続。BGP を使用するデバイスの場合、カスタマーゲートウェイデバイスと仮想プライベートゲートウェイ間でルートを交換します。  | 

次の表は、カスタマーゲートウェイデバイスの要件、関連する RFC (参照用)、および要件に関するコメントの一覧です。

各 VPN 接続は 2 つの個別のトンネルで構成されています。各トンネルには、IKE セキュリティアソシエーション、IPsec セキュリティアソシエーション、および BGP ピア接続が含まれています。トンネルごとに 1 つの一意のセキュリティアソシエーション (SA) ペア (受信用に 1 つと送信用に 1 つ) に制限されるため、2 つのトンネルで合計 2 つの一意の SA ペア (4 つの SA) になります。一部のデバイスは、ポリシーベースの VPN を使用して、ACL エントリと同数の SA を作成します。そのため、不要なトラフィックを許可しないように、ルールを統合してからフィルタリングする必要がある場合があります。

デフォルトでは、トラフィックが生成され、VPN 接続のユーザー側から IKE ネゴシエーションが開始されると、VPN トンネルが開始されます。代わりに、接続の AWS 側から IKE ネゴシエーションを開始するように VPN 接続を設定できます。詳細については、「[AWS Site-to-Site VPN トンネル開始オプション](initiate-vpn-tunnels.md)」を参照してください。

VPN エンドポイントはキー再生成をサポートしており、カスタマーゲートウェイデバイスが再ネゴシエーショントラフィックを送信しなくなってフェーズ 1 の期限が切れそうになると、再ネゴシエーションを開始できます。


|  要件  |  RFC |  コメント | 
| --- | --- | --- | 
|  IKE セキュリティアソシエーションを確立する   ![\[IKE\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/IKE.png)   |  [RFC 2409](https://datatracker.ietf.org/doc/html/rfc2409)  [RFC 7296](https://datatracker.ietf.org/doc/html/rfc7296)  |  IKE セキュリティの関連付けは、 がオーセンティケーター AWS Private Certificate Authority として使用する事前共有キーまたはプライベート証明書を使用して、仮想プライベートゲートウェイとカスタマーゲートウェイデバイスの間で最初に確立されます。IKE は確立されると、一時キーをネゴシエートして今後の IKE メッセージを保護します。暗号化パラメータや認証パラメータなど、パラメータ間で完全な合意が必要です。 で VPN 接続を作成するときに AWS、トンネルごとに独自の事前共有キーを指定するか、 で AWS 生成できます。または、 を使用してカスタマーゲートウェイデバイス AWS Private Certificate Authority に使用するプライベート証明書を指定することもできます。VPN トンネルの設定の詳細については、「[AWS Site-to-Site VPN 接続のトンネルオプション](VPNTunnels.md)」を参照してください。 IKEv1 および IKEv2 バージョンがサポートされています。 メインモードは IKEv1 でのみサポートされています。 Site-to-Site VPN サービスは、ルートベースのソリューションです。ポリシーベースの設定を使用する場合は、設定を 1 つのセキュリティアソシエーション (SA) に制限する必要があります。  | 
|  トンネルモードで IPsec セキュリティアソシエーションを確立する  ![\[IPsec\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/IPsec.png)   |   [RFC 4301](https://datatracker.ietf.org/doc/html/rfc4301)   |  IKE の一時キーを使用すると、IPsec セキュリティアソシエーション (SA) を形成するために、仮想プライベートゲートウェイとカスタマーゲートウェイデバイス間でキーが確立されます。この SA を使用して、ゲートウェイ間のトラフィックの暗号化および暗号化の解除を行います。IPsec SA 内のトラフィックの暗号化に使用される一時キーは、通信の機密性を確保するために、定期的なローテーションで IKE によって自動的に変更されます。  | 
|  AES 128 ビット暗号化または AES 256 ビット暗号化関数を使用する  |   [RFC 3602](https://datatracker.ietf.org/doc/html/rfc3602)   |  この暗号化機能は、IKE と IPsec の両方のセキュリティアソシエーションでプライバシーを確保するために使用されます。  | 
|  SHA-1 または SHA-2 (256) ハッシュ関数を使用する  |   [RFC 2404](https://datatracker.ietf.org/doc/html/rfc2404)   |  このハッシュ関数は、IKE と IPsec の両方のセキュリティアソシエーションを認証するために使用されます。  | 
|  Diffie-Hellman Perfect Forward Secrecy を使用する。  |   [RFC 2409](https://datatracker.ietf.org/doc/html/rfc2409)   |  IKE は、カスタマーゲートウェイデバイスと仮想プライベートゲートウェイ間のすべての通信を保護するために、Diffie-Hellman を使用して一時キーを確立します。 以下のグループがサポートされます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/CGRequirements.html)  | 
|  (動的にルーティングされた VPN 接続) IPsec Dead Peer Detection を使用する  |   [RFC 3706](https://datatracker.ietf.org/doc/html/rfc3706)   |  Dead Peer Detection を使用すると、VPN デバイスは、ネットワークの状態によりインターネットでのパケット配信が妨げられていることをすばやく特定できます。この場合、ゲートウェイはセキュリティアソシエーションを削除し、新しいアソシエーションを作成しようとします。このプロセス中、可能であれば、代わりの IPsec トンネルが使用されます。  | 
|  (動的にルーティングされた VPN 接続) トンネルを論理インターフェイスにバインドする (ルートベースの VPN)  ![\[Tunnel\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/Tunnel.png)   |   なし   |  デバイスは、IPsec トンネルを論理インターフェイスにバインドできる必要があります。論理インターフェイスには、仮想プライベートゲートウェイへの BGP ピア接続を確立するために使用される IP アドレスが含まれています。この論理インターフェイスは、追加のカプセル化 (たとえば、GRE、IP in IP) を実行しないでください。インターフェイスは、1399 バイトの最大送信単位 (MTU) に設定する必要があります。  | 
|  (動的にルーティングされた VPN 接続) BGP ピア接続を確立する  ![\[BGP\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/BGP.png)   |   [RFC 4271](https://datatracker.ietf.org/doc/html/rfc4271)   |  BGP は、カスタマーゲートウェイデバイスと BGP を使用するデバイスの仮想プライベートゲートウェイ間でルートを交換するために使用されます。すべての BGP トラフィックは、IPsec Security Association を通じて暗号化され、送信されます。BGP は、両方のゲートウェイが IPsec SA を通じて到達可能な IP プレフィックスを交換するために必要です。  | 

 AWS VPN 接続は、パス MTU 検出 ([RFC 1191) ](https://datatracker.ietf.org/doc/html/rfc1191)をサポートしていません。

カスタマーゲートウェイデバイスとインターネット間にファイアウォールがある場合は、「[AWS Site-to-Site VPN カスタマーゲートウェイデバイスのファイアウォールルール](FirewallRules.md)」を参照してください。

# AWS Site-to-Site VPN カスタマーゲートウェイデバイスのベストプラクティス
<a name="cgw-best-practice"></a>

**IKEv2 を使用する**  
Site-to-Site VPN 接続に IKEv2 を使用することを強くお勧めします。IKEv2 は、IKEv1 よりもシンプルで堅牢、安全なプロトコルです。カスタマーゲートウェイデバイスが IKEv2 をサポートしていない場合にのみ、IKEv1 を使用してください。IKEv1 と IKEv2 の違いの詳細については、「[RFC7296 の付録 A](https://www.rfc-editor.org/rfc/rfc7296#appendix-A)」を参照してください。

**パケットの [フラグメント化しない] フラグをリセットする**  
一部のパケットには、フラグメント化しない (DF) と呼ばれるフラグがあり、パケットがフラグメント化されないように指示することができます。パケットにフラグが設定されていれば、ゲートウェイは ICMP Path MTU Exceeded メッセージを生成します。場合によっては、これらの ICMP メッセージを処理し、各パケットで送信されるデータの量を削減するための適切な仕組みがアプリケーションに備わっていません。一部の VPN デバイスでは、必要に応じて DF フラグをオーバーライドし、無条件でパケットをフラグメント化できます。カスタマーゲートウェイデバイスにこの機能がある場合は、必要に応じてこの機能を使用することをお勧めします。詳細については「[RFC 791](https://datatracker.ietf.org/doc/html/rfc791)」を参照してください。

**暗号化前に IP パケットをフラグメント化する**  
Site-to-Site VPN 接続経由で送信されるパケットが MTU サイズを超える場合は、フラグメント化する必要があります。パフォーマンスの低下を避けるため、パケットが暗号化される*前に*、パケットをフラグメント化するようにカスタマーゲートウェイデバイスを設定することをお勧めします。Site-to-Site VPN は、フラグメント化されたパケットを次の宛先に転送する前に再アセンブルし、 AWS ネットワークを通過する packet-per-secondフローを増やします。詳細については「[RFC 4459](https://datatracker.ietf.org/doc/html/rfc4459)」を参照してください。

**送信先ネットワークのパケットサイズが MTU を超えないようにする**  
Site-to-Site VPN は、次の送信先に転送する前にカスタマーゲートウェイデバイスから受信したフラグメント化されたパケットを再アセンブルするため、これらのパケットが次に転送される送信先ネットワークでは、オーバーなどのパケットサイズ/MTU に関する考慮事項や Direct Connect、Radius などの特定のプロトコルに関する考慮事項がある場合があります。

**使用中のアルゴリズムに従って MTU および MSS サイズを調整する**  
多くの場合、TCP パケットは IPsec トンネル間で最も一般的なタイプのパケットです。Site-to-Site VPN は 1446 バイトの最大伝送ユニット（MTU）と 1406 バイトの対応する最大セグメントサイズ（MSS）をサポートします。ただし、暗号化アルゴリズムにはさまざまなヘッダーサイズがあり、これらの最大値を達成できない可能性があります。フラグメンテーションを回避して最適なパフォーマンスを得るには、使用するアルゴリズムに基づいて MTU と MSS を設定することをお勧めします。

次の表を使用して、フラグメンテーションを回避し、最適なパフォーマンスを実現するように MTU/MSS を設定します。


| 暗号化アルゴリズム | ハッシュ生成アルゴリズム | NAT トラバーサル | MTU | MSS (IPv4) | MSS (IPv6-in-IPv4) | 
| --- | --- | --- | --- | --- | --- | 
|  AES-GCM-16  |  該当なし  |  無効  |  1446  |  1406  |  1386  | 
|  AES-GCM-16  |  該当なし  |  有効  |  1438  |  1398  |  1378  | 
|  AES-CBC  |  SHA1/SHA2-256  |  無効  |  1438  |  1398  |  1378  | 
|  AES-CBC  |  SHA1/SHA2-256  |  有効  |  1422  |  1382  |  1362  | 
|  AES-CBC  |  SHA2-384  |  無効  |  1422  |  1382  |  1362  | 
|  AES-CBC  |  SHA2-384  |  有効  |  1422  |  1382  |  1362  | 
|  AES-CBC  |  SHA2-512  |  無効  |  1422  |  1382  |  1362  | 
|  AES-CBC  |  SHA2-512  |  有効  |  1406  |  1366  |  1346  | 

**注記**  
AES-GCM アルゴリズムは暗号化と認証の両方をカバーするため、MTU に影響する明確な認証アルゴリズムの選択はありません。

**IKE の一意の ID を無効にする**  
一部のカスタマーゲートウェイデバイスは、トンネル設定ごとに最大 1 つのフェーズ 1 セキュリティ関連付けが存在するようにする設定をサポートしています。この設定により、VPN ピア間でフェーズ 2 の状態が一致しない可能性があります。カスタマーゲートウェイデバイスがこの設定をサポートしている場合は、無効にすることをお勧めします。

# AWS Site-to-Site VPN カスタマーゲートウェイデバイスのファイアウォールルール
<a name="FirewallRules"></a>

カスタマーゲートウェイデバイスをエンドポイントに接続する IPsec トンネルのエンドポイントとして使用する静的 IP アドレスが必要です。 AWS Site-to-Site VPN ファイアウォールが AWS とカスタマーゲートウェイデバイスの間にある場合、IPsec トンネルを確立するために、次の表のルールを設定する必要があります。 AWS側の IP アドレスは設定ファイルにあります。


**インバウンド (インターネットから)**  

| 
| 
|  入力ルール I1  | 
| --- |
|  [Source IP] (送信元 IP)  |  Tunnel1 外部 IP  | 
|  送信先 IP  |  カスタマーゲートウェイ  | 
|  プロトコル  |  UDP  | 
|  ソースポート  |  500  | 
|  送信先  |  500  | 
|  入力ルール I2  | 
| --- |
|  [Source IP] (送信元 IP)  |  Tunnel2 外部 IP  | 
|  送信先 IP  |  カスタマーゲートウェイ  | 
|  プロトコル  |  UDP  | 
|  ソースポート  |  500  | 
|  発信先ポート  |  500  | 
|  入力ルール I3  | 
| --- |
|  [Source IP] (送信元 IP)  |  Tunnel1 外部 IP  | 
|  送信先 IP  |  カスタマーゲートウェイ  | 
|  プロトコル  |  IP 50 (ESP)  | 
|  入力ルール I4  | 
| --- |
|  [Source IP] (送信元 IP)  |  Tunnel2 外部 IP  | 
|  送信先 IP  |  カスタマーゲートウェイ  | 
|  プロトコル  |  IP 50 (ESP)  | 


**アウトバウンド (インターネットへ)**  

| 
| 
|  出力ルール O1  | 
| --- |
|  [Source IP] (送信元 IP)  |  カスタマーゲートウェイ  | 
|  送信先 IP  |  Tunnel1 外部 IP  | 
|  プロトコル  |  UDP  | 
|  ソースポート  |  500  | 
|  発信先ポート  |  500  | 
|  出力ルール O2  | 
| --- |
|  [Source IP] (送信元 IP)  |  カスタマーゲートウェイ  | 
|  送信先 IP  |  Tunnel2 外部 IP  | 
|  プロトコル  |  UDP  | 
|  ソースポート  |  500  | 
|  発信先ポート  |  500  | 
|  出力ルール O3  | 
| --- |
|  [Source IP] (送信元 IP)  |  カスタマーゲートウェイ  | 
|  送信先 IP  |  Tunnel1 外部 IP  | 
|  プロトコル  |  IP 50 (ESP)   | 
|  出力ルール O4  | 
| --- |
|  [Source IP] (送信元 IP)  |  カスタマーゲートウェイ  | 
|  送信先 IP  |  Tunnel2 外部 IP  | 
|  プロトコル  |  IP 50 (ESP)  | 

ルール I1、I2、O1、および O2 は、IKE パケットの送信を有効にします。ルール I3、I4、O3、および O4 は、暗号化されたネットワークトラフィックを含む IPsec パケットの送信を有効にします。

**注記**  
デバイスで NAT トラバーサル (NAT-T) を使用している場合は、ポート 4500 の UDP トラフィックもネットワークと AWS Site-to-Site VPN エンドポイント間で通過できることを確認してください。デバイスが NAT-T をアドバタイズしているかどうかを確認します。

# AWS Site-to-Site VPN カスタマーゲートウェイデバイスの静的および動的設定ファイル
<a name="example-configuration-files"></a>

VPN 接続を作成すると、Amazon VPC コンソールから、または EC2 API を使用して、 AWSが提供するサンプル設定ファイルをダウンロードするオプションが追加されます。詳細については「[ステップ 6: 設定ファイルをダウンロードする](SetUpVPNConnections.md#vpn-download-config)」を参照してください。静的ルーティングと動的ルーティング専用のサンプル設定の.zip ファイルをそれぞれのページでダウンロードすることもできます。

 AWSが提供するサンプル設定ファイルには、カスタマーゲートウェイデバイスの設定に使用できる VPN 接続に固有の情報が含まれています。場合によっては、AWS でテスト済みのデバイス用に、デバイス固有の設定ファイルが用意されています。特定のカスタマーゲートウェイデバイスが一覧に表示されていない場合は、汎用設定ファイルをダウンロードして開始できます。

**重要**  
この設定ファイルはあくまでも一例です。お客様が想定する Site-to-Site VPN 接続設定とは一致しない場合があります。ほとんどの AWS リージョンで AES128, SHA1、および Diffie-Hellman グループ 2、 AWS GovCloud リージョンで AES128, SHA2、および Diffie-Hellman グループ 14 の Site-to-Site VPN 接続の最小要件を指定します。また、認証用の事前共有キーも指定します。追加のセキュリティアルゴリズム、Diffie-Hellman グループ、プライベート証明書、IPv6 トラフィックを活用するには、サンプル設定ファイルを変更する必要があります。

**注記**  
これらのデバイス固有の設定ファイルは、ベストエフォートベース AWS で から提供されます。によってテストされていますが AWS、このテストは制限されています。設定ファイルに問題がある場合は、特定のベンダーに問い合わせて、追加のサポートを依頼する必要があります。

次の表に、IKEv2 をサポートするように更新された、ダウンロード可能な設定ファイルの例があるデバイスのリストを示します。多くの一般的なカスタマーゲートウェイデバイスの設定ファイルに IKEv2 サポートが導入されており、時間の経過とともにファイルを追加していきます。このリストは、設定ファイルの例が追加されると更新されます。


| Vendor | プラットフォーム | ソフトウェア | 
| --- | --- | --- | 
|  AXGATE  |  NF  |  AOS 3.2 以降  | 
|  AXGATE  |  UTM  |  AOS 2.1 以降  | 
|  Checkpoint  |  Gaia  |  R80.10\$1  | 
|  Cisco Meraki  |  MX シリーズ  |  15.12\$1 (WebUI)  | 
|  Cisco Systems, Inc。  |  ASA 5500 シリーズ  |  ASA 9.7\$1 VTI  | 
|  Cisco Systems, Inc。  |  CSRv AMI  |  IOS 12.4 以降  | 
|  Fortinet  |  FortiGate 40\$1 シリーズ  |  FortiOS 6.4.4\$1 (GUI)  | 
|  Juniper Networks, Inc。  |  J シリーズルーター  |  JunOS 9.5 以降  | 
|  Juniper Networks, Inc。  |  SRX ルーター  |  JunOS 11.0 以降  | 
|  Mikrotik  |  RouterOS  |  6.44.3  | 
|  Palo Alto Networks  |  PA シリーズ  |  PANOS 7.0 以降  | 
|  SonicWall  |  NSA、TZ  |  OS 6.5  | 
|  Sophos  |  Sophos ファイアウォール  |  v19\$1  | 
|  Strongswan  |  Ubuntu 16.04  |  Strongswan 5.5.1\$1  | 
|  Yamaha  |  RTX ルーター  |  Rev.10.01.16 以降  | 

# AWS Site-to-Site VPN カスタマーゲートウェイデバイスのダウンロード可能な静的ルーティング設定ファイル
<a name="cgw-static-routing-examples"></a>

Site-to-Site VPN 接続設定に固有の値を含むサンプル設定ファイルをダウンロードするには、Amazon VPC コンソール、 AWS コマンドライン、または Amazon EC2 API を使用します。詳細については、「[ステップ 6: 設定ファイルをダウンロードする](SetUpVPNConnections.md#vpn-download-config)」を参照してください。

また、Site-to-Site VPN 接続設定に固有の値を含まないスタティックルーティング用の汎用設定ファイルの例をダウンロードすることもできます。[static-routing-examples.zip](samples/static-routing-examples.zip) 

これらのファイルは、一部のコンポーネントにプレースホルダー値を使用します。たとえば、以下を使用します。
+ VPN 接続 ID 、カスタマーゲートウェイ ID および仮想プライベートゲートウェイ ID の値の例
+ リモート (外部) IP アドレス AWS エンドポイントのプレースホルダー (*AWS\$1ENDPOINT\$11* および *AWS\$1ENDPOINT\$12*)
+ カスタマーゲートウェイデバイスのインターネットルーティング可能な外部インターフェイスの IP アドレスのプレースホルダー (*your-cgw-ip-address*)
+ 事前共有キー値のプレースホルダ (事前共有キー)
+ トンネルの内部 IP アドレスの値の例。
+ MTU 設定の値の例。

**注記**  
サンプルコンフィギュレーションファイルで提供されている MTU 設定は、例にすぎません。状況に応じた最適な MTU 値の設定については、「[AWS Site-to-Site VPN カスタマーゲートウェイデバイスのベストプラクティス](cgw-best-practice.md)」を参照してください。

プレースホルダー値を指定することに加えて、ファイルはほとんどの AWS リージョンで AES128, SHA1、および Diffie-Hellman グループ 2 の Site-to-Site VPN 接続、 AWS GovCloud リージョンで AES128, SHA2、および Diffie-Hellman グループ 14 の最小要件を指定します。また、[認証](vpn-tunnel-authentication-options.md)用の事前共有キーも指定します。追加のセキュリティアルゴリズム、Diffie-Hellman グループ、プライベート証明書、IPv6 トラフィックを活用するには、サンプル設定ファイルを変更する必要があります。

次の図は、カスタマーゲートウェイデバイスに設定されているさまざまなコンポーネントの概要を示しています。これには、トンネルインターフェイスの IP アドレスの値の例が含まれます。

![\[静的ルーティングを使用するカスタマーゲートウェイデバイス\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/cgw-static-routing.png)


# AWS Site-to-Site VPN カスタマーゲートウェイデバイスの静的ルーティングを設定する
<a name="cgw-static-routing-example-interface"></a>

以下は、ユーザーインターフェイス (使用可能な場合) を使用してカスタマーゲートウェイデバイスを設定する手順の例です。

------
#### [ Check Point ]

以下は、デバイスが R77.10 以降を実行する Check Point Security Gateway デバイスで、デバイスが Gaia オペレーティングシステムと Check Point SmartDashboard を使用している場合に、カスタマーゲートウェイデバイスを設定するステップです。Check Point Support Center の [Check Point Security Gateway IPsec VPN to Amazon Web Services VPC](https://support.checkpoint.com/results/sk/sk100726) の記事も参照できます。

**トンネルインターフェイスを設定するには**

最初のステップは、VPN トンネルを作成し、各トンネル用のカスタマーゲートウェイと仮想プライベートゲートウェイのプライベート (内部) IP アドレスを提供することです。最初のトンネルを作成するには、設定ファイルの `IPSec Tunnel #1` セクションで提供される情報を使用します。2 番目のトンネルを作成するには、設定ファイルの `IPSec Tunnel #2` セクションで提供される値を使用します。

1. Check Point Security Gateway デバイスの Gaia ポータルを開きます。

1. [**Network Interfaces**]、[**Add**]、[**VPN tunnel**] の順に選択します。

1. ダイアログボックスで次のように設定し、完了したら [**OK**] を選択します。
   + [**VPN Tunnel ID**] には、1 など一意の値を入力します。
   + [**Peer**] には、`AWS_VPC_Tunnel_1` または `AWS_VPC_Tunnel_2` など、トンネル用の一意の名前を入力します。
   + [**Numbered**] が選択されていることを確認して、[**Local Address (ローカルアドレス)**] に設定ファイルの `CGW Tunnel IP` で指定されている IP アドレス (例: `169.254.44.234`) を入力します。
   + [**Remote Address**] には、設定ファイルの `VGW Tunnel IP` に指定された IP アドレス (例: `169.254.44.233`) を入力します。  
![\[Check Point の [Add VPN Tunnel] ダイアログボックス\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/check-point-create-tunnel.png)

1. SSH でセキュリティゲートウェイに接続します。デフォルト以外のシェルを使用している場合は、次のコマンドを実行して、clish に変更します。`clish`

1. トンネル 1 の場合は、次のコマンドを実行します。

   ```
   set interface vpnt1 mtu 1436
   ```

   トンネル 2 の場合は、次のコマンドを実行します。

   ```
   set interface vpnt2 mtu 1436
   ```

1. 2 番目のトンネルを作成するには、設定ファイルの `IPSec Tunnel #2` セクション内の情報を使用して、ステップを繰り返します。

**静的ルートを設定するには**

このステップでは、各トンネルで VPC のサブネットへの静的ルートを指定し、トラフィックをトンネルインターフェイス経由で送信できるようにします。2 番目のトンネルにより、最初のトンネルに問題がある場合のフェイルオーバーが可能になります。問題が検出されると、ポリシーベースの静的ルートがルーティングテーブルから削除され、2 番目のルートが有効化されます。また、トンネルのもう一方の端に ping を打ち、トンネルが稼働しているかどうかを確認するために、Check Point ゲートウェイを有効にする必要があります。

1. Gaia ポータルで、[**IPv4 Static Routes**]、[**Add**] の順に選択します。

1. サブネットの CIDR (例: `10.28.13.0/24`) を指定します。

1. [**Add Gateway**]、[**IP Address**] の順に選択します。

1. 設定ファイルの `VGW Tunnel IP` に指定された IP アドレス (例: `169.254.44.233`) を入力し、優先順位を 1 にします。

1. [**Ping**] を選択します。

1. 2 つめのトンネルに対して、設定ファイルの `VGW Tunnel IP` セクションにある `IPSec Tunnel #2` の値を使用してステップ 3 および 4 を繰り返します。優先順位を 2 にします。  
![\[Check Point の [Edit Destination Route] ダイアログボックス\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/check-point-static-routes.png)

1. **[保存]** を選択します。

クラスターを使用している場合は、クラスターの他のメンバーで上記のステップを繰り返します。

**新しいネットワークオブジェクトを定義するには**

このステップでは、仮想プライベートゲートウェイのパブリック (外部) IP アドレスを指定することで各 VPN トンネル用のネットワークオブジェクトを作成します。後で、VPN コミュニティのサテライトゲートウェイとしてこれらのオブジェクトを追加します。また、VPN ドメインのプレースホルダーとして機能する空グループを作成する必要があります。

1. Check Point SmartDashboard を開きます。

1. [**Groups**] では、コンテキストメニューを開き、[**Groups**]、[**Simple Group**] の順に選択します。各ネットワークオブジェクトに対して同じグループを使用できます。

1. [**Network Objects**] では、コンテキストメニュー (右クリック) を開き、[**New**]、[**Interoperable Device**] の順に選択します。

1. [**Name (名前)**] には、トンネル用に指定した名前 (例: `AWS_VPC_Tunnel_1` または `AWS_VPC_Tunnel_2`) を入力します。

1. [**IPv4 Address**] には、設定ファイルで提供される仮想プライベートゲートウェイの外部 IP アドレス (例: `54.84.169.196`) を入力します。設定を保存して、このダイアログボックスを閉じます。  
![\[Check Point の [Interoperable Device] ダイアログボックス\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/check-point-network-device.png)

1. SmartDashboard でゲートウェイのプロパティを開き、カテゴリーペインで [**Topology**] を選択します。

1. インターフェイス設定を取得するには、[**Get Topology**] を選択します。

1. [**VPN Domain (VPN ドメイン)**] セクションで、[**Manually defined (手動で定義)**] を選択し、ステップ 2 で作成した空のシンプルなグループを参照して選択します。[**OK**] を選択してください。
**注記**  
設定済みの既存の VPN ドメインは保持できます。ただし、特に VPN ドメインが自動的に取得されている場合は、新しい VPN 接続で使用または提供されるドメインとホストがその VPN ドメインで宣言されていないことを確認してください。

1. 2 番目のネットワークオブジェクトを作成するには、設定ファイルの `IPSec Tunnel #2` セクション内の情報を使用して、ステップを繰り返します。

**注記**  
クラスターを使用している場合は、トポロジーを編集してインターフェイスをクラスターインターフェイスとして定義します。設定ファイルで指定された IP アドレスを使用します。

**VPN コミュニティ、IKE、および IPsec 設定の作成と設定**

このステップでは、Check Point ゲートウェイに VPN コミュニティを作成し、そこに各トンネルのネットワークオブジェクト (相互運用デバイス) を追加します。また、Internet Key Exchange (IKE) および IPsec を設定します。

1. ゲートウェイのプロパティから、カテゴリーペインの [**IPSec VPN**] を選択します。

1. [**Communities**]、[**New**]、[**Star Community**] の順に選択します。

1. コミュニティの名前 (例: `AWS_VPN_Star`) を指定し、カテゴリーペインの [**Center Gateways**] を選択します。

1. [**Add**] を選択して、ゲートウェイまたはクラスターを参加ゲートウェイのリストに追加します。

1. カテゴリーペインで、[**Satellite Gateways**]、[**Add (追加)**] の順に選択し、先に作成した相互運用デバイス (`AWS_VPC_Tunnel_1` および `AWS_VPC_Tunnel_2`) を参加ゲートウェイのリストに追加します。

1. カテゴリーペインで、[**Encryption**] を選択します。[**Encryption Method**] セクションで、[**IKEv1 only**] を選択します。[**Encryption Suite**] セクションで、[**Custom**]、[**Custom Encryption**] の順に選択します。

1. ダイアログボックスで次のように暗号化プロパティを設定し、完了したら [**OK**] を選択します。
   + IKE Security Association (フェーズ 1) のプロパティ
     + **Perform key exchange encryption with**: AES-128
     + **Perform data integrity with**: SHA-1
   + IPsec Security Association (フェーズ 2) のプロパティ
     + **Perform IPsec data encryption with**: AES-128
     + **Perform data integrity with**: SHA-1

1. カテゴリーペインで [**Tunnel Management**] を選択します。[**Set Permanent Tunnels**]、[**On all tunnels in the community**] の順に選択します。[**VPN Tunnel Sharing**] セクションで、[**One VPN tunnel per Gateway pair**] を選択します。

1. カテゴリーペインで [**Advanced Settings**] を展開し、[**Shared Secret**] を選択します。

1. 最初のトンネルのピア名を選択し、[**Edit (編集)**] を選択して、設定ファイルの `IPSec Tunnel #1` セクションで指定されている事前共有キーを入力します。

1. 2 番目のトンネルのピア名を選択し、[**Edit (編集)**] を選択して、設定ファイルの `IPSec Tunnel #2` セクションで指定されている事前共有キーを入力します。  
![\[Check Point の [Interoperable Shared Secret] ダイアログボックス\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/check-point-shared-secret.png)

1. さらに [**Advanced Settings (詳細設定)**] カテゴリで [**Advanced VPN Properties (詳細な VPN プロパティ)**] を選択し、プロパティを次のように設定して、完了したら [**OK**] を選択します。
   + IKE (フェーズ 1):
     + **Use Diffie-Hellman group**: `Group 2`
     + **Renegotiate IKE security associations every** `480` **minutes**
   + IPsec (フェーズ 2):
     + [**Use Perfect Forward Secrecy**] を選択します。
     + **Use Diffie-Hellman group**: `Group 2`
     + **Renegotiate IPsec security associations every** `3600` **seconds**

**ファイアウォールルールを作成するには**

このステップでは、ファイアウォールルールとディレクショナルマッチルールを使用し、VPC とローカルネットワーク間での通信を許可するポリシーを設定します。その後、ゲートウェイにポリシーをインストールします。

1. SmartDashboard で、ゲートウェイの [**Global Properties**] を選択します。カテゴリーペインで [**VPN**] を展開し、[**Advanced**] を選択します。

1. [**Enable VPN Directional Match in VPN Column**] を選択し、変更を保存します。

1. SmartDashboard で [**Firewall**] を選択し、次のルールでポリシーを作成します。
   + VPC サブネットに対して必須プロトコル経由でのローカルネットワークとの通信を許可する。
   + ローカルネットワークに対して必須プロトコル経由での VPC サブネットとの通信を許可する。

1. VPN 列のセルのコンテキストメニューを開いて、[**Edit Cell**] を選択します。

1. [**VPN Match Conditions**] ダイアログボックスで、[**Match traffic in this direction only**] を選択します。それぞれで [**Add**] を選択してディレクショナルマッチルールを作成し、完了したら [**OK**] を選択します。
   + `internal_clear` > VPN コミュニティ (先に作成した VPN スターコミュニティ。例: `AWS_VPN_Star`)
   + VPN コミュニティ > VPN コミュニティ
   + VPN コミュニティ > `internal_clear`

1. SmartDashboard で、[**Policy**]、[**Install**] の順に選択します。

1. ダイアログボックスでゲートウェイを選択し、[**OK**] を選択してポリシーをインストールします。

**tunnel\$1keepalive\$1method プロパティを変更するには**

Check Point ゲートウェイでは、IKE の関連付けが停止したときに Dead Peer Detection (DPD) を使用して識別できます。永続トンネルの DPD を設定するには、永続トンネルを AWS VPN コミュニティで設定する必要があります (ステップ 8 を参照）。

デフォルトでは、VPN ゲートウェイの `tunnel_keepalive_method` プロパティは `tunnel_test` に設定されます。この値を `dpd` に変更する必要があります。DPD モニタリングが必要な VPN コミュニティ内の各 VPN ゲートウェイは、サードパーティー製 VPN ゲートウェイを含め、`tunnel_keepalive_method` プロパティで設定する必要があります。同じゲートウェイに対して異なるモニタリングメカニズムを設定することはできません。

GuiDBedit ツールを使用して `tunnel_keepalive_method` プロパティを更新できます。

1. Check Point SmartDashboard を開き、[**Security Management Server**]、[**Domain Management Server**] の順に選択します。

1. [**File**]、[**Database Revision Control...**] の順に選択し、リビジョンのスナップショットを作成します。

1. SmartDashboard、SmartView Tracker、SmartView Monitor など、すべての SmartConsole ウィンドウを閉じます。

1. GuiBDedit ツールを起動します。詳細については、Check Point サポートセンターの「[Check Point Database Tool](https://support.checkpoint.com/results/sk/sk13009)」という記事を参照してください。

1. [**Security Management Server**]、[**Domain Management Server**] の順に選択します。

1. 左上のペインで、[**Table**]、[**Network Objects**]、[**network\$1objects**] の順に選択します。

1. 右上のペインで、関連する [**Security Gateway**]、[**Cluster**] オブジェクトを選択します。

1. Ctrl\$1F キーを押すか、[**Search**] メニューを使用して以下を検索します。`tunnel_keepalive_method`

1. 下のペインで、[`tunnel_keepalive_method`] のコンテキストメニューを開き、[**Edit... (編集...)**] を選択します。[**dpd**] を選択し、[**OK**] を選択します。

1.  AWS VPN コミュニティの一部である各ゲートウェイに対して、ステップ 7～9 を繰り返します。

1. [**File**]、[**Save All**] の順に選択します。

1. GuiDBedit ツールを閉じます。

1. Check Point SmartDashboard を開き、[**Security Management Server**]、[**Domain Management Server**] の順に選択します。

1. 関連する [**Security Gateway**]、[**Cluster**] オブジェクトにポリシーをインストールします。

詳細については、Check Point Support Center の「[New VPN features in R77.10](https://support.checkpoint.com/results/sk/sk97746)」という記事を参照してください。

**TCP MSS クランプを有効にするには**

TCP MSS クランプは TCP パケットの最大セグメントサイズを小さくしてパケット断片化を防ぎます。

1. 次のディレクトリに移動します。`C:\Program Files (x86)\CheckPoint\SmartConsole\R77.10\PROGRAM\`

1. `GuiDBEdit.exe` ファイルを実行して Check Point Database Tool を開きます。

1. [**Table**]、[**Global Properties**]、[**properties**] の順に選択します。

1. `fw_clamp_tcp_mss` で、[**Edit**] を選択します。値を `true` に変更し、[**OK**] を選択します。

**トンネルのステータスを確認するには**  
エキスパートモードのコマンドラインツールから次のコマンドを実行して、トンネルの状態を確認できます。

```
vpn tunnelutil
```

表示されたオプションで、IKE 関連付けを検証するには [**1**] を、IPsec 関連付けを検証するには [**2**] を選択します。

また、Check Point Smart Tracker Log を使用して、接続内のパケットが暗号化されていることを検証できます。たとえば次のログは、VPC へのパケットがトンネル 1 経由で送信され、暗号化されていることを示します。

![\[Check Point ログファイル\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/check-point-log.png)


------
#### [ SonicWALL ]

次の手順では、SonicOS 管理インターフェイスを使用して SonicWALL デバイスに VPN トンネルを設定する方法を説明します。

**トンネルを設定するには**

1. SonicWALL SonicOS 管理インターフェイスを開きます。

1. 左側のペインで、[**VPN**]、[**Settings**] の順に選択します。[**VPN Policies**] の下で、[**Add...**] を選択します。

1. [**General**] タブの VPN ポリシーウィンドウで、次の情報を入力します。
   + [**Policy Type**: [**Tunnel Interface**] を選択します。
   + [**Authentication Method**]: [**IKE using Preshared Secret**] を選択します。
   + [**Name**]: VPN ポリシーの名前を入力します。設定ファイルに記載されている通り、VPN ID 名を使用することをお勧めします。
   + **IPsec Primary Gateway Name or Address**: 設定ファイルに記載されている通り、仮想プライベートゲートウェイの IP アドレス (例: `72.21.209.193`) を入力します。
   + **IPsec Secondary Gateway Name or Address**: デフォルト値のままにします。
   + **Shared Secret**: 設定ファイルに記載されている通りに事前共有キーを入力後、[**Confirm Shared Secret**] で再入力します。
   + **Local IKE ID**: カスタマーゲートウェイ (SonicWALL デバイス) の IPv4 アドレスを入力します。
   + **Peer IKE ID**: 仮想プライベートゲートウェイの IPv4 アドレスを入力します。

1. [**Network**] タブで、次の情報を入力します。
   + [**Local Networks**] で、[**Any address**] を選択します。このオプションを使用して、ローカルネットワーク接続の問題を防ぐことをお勧めします。
   + [**Remote Networks**] で、[**Choose a destination network from list**] を選択します。 AWS内に VPC の CIDR を持つアドレスオブジェクトを作成します。

1. [**Proposals (提案)**] タブで、次の情報を入力します。
   + [**IKE (Phase 1) Proposal**] で、以下の作業を行います。
     + **Exchange**: [**Main Mode**] を選択します。
     + **DH Group**: Diffie-Hellman Group の値 (例: `2`) を入力します。
     + **Encryption**: [**AES-128**] または [**AES-256**] を選択します。
     + **Authentication**: [**SHA1**] または [**SHA256**] を選択します。
     + **Life Time**: `28800` と入力します。
   + [**IKE (Phase 2) Proposal**] で、以下の作業を行います。
     + **Protocol**: [**ESP**] を選択します。
     + **Encryption**: [**AES-128**] または [**AES-256**] を選択します。
     + **Authentication**: [**SHA1**] または [**SHA256**] を選択します。
     + [**Enable Perfect Forward Secrecy**] チェックボックスをオンにし、Diffie-Hellman group を選択します。
     + **Life Time**: `3600` と入力します。
**重要**  
仮想プライベートゲートウェイを作成したのが 2015 年 10 月より前の場合は、両方のフェーズで Diffie-Hellman group 2、AES-128、SHA1 を指定する必要があります。

1. [**Advanced**] タブで、次の情報を入力します。
   + [**Enable Keep Alive**] を選択します。
   + [**Enable Phase2 Dead Peer Detection**] を選択し、次のように入力します。
     + [**Dead Peer Detection Interval**] に、`60` (SonicWALL デバイスで入力可能な最小値) と入力します。
     + [**Failure Trigger Level**] で、`3` と入力します。
   + [**VPN Policy bound to**] で、[**Interface X1**] を選択します。パブリック IP アドレスで一般的に指定されたインターフェイスです。

1. [**OK**] を選択してください。[**Settings**] ページで、トンネルの [**Enable**] チェックボックスをデフォルトでオンにします。緑の点は、トンネルが稼働していることを表します。

------

## Cisco デバイス: 追加情報
<a name="cgw-static-routing-examples-cisco"></a>

一部の Cisco ASA ではアクティブ/スタンバイモードのみがサポートされています。これらの Cisco ASA を使用する場合は、アクティブなトンネルを一度に 1 個のみ保持できます。最初のトンネルが利用不可になった場合は、他方のスタンバイトンネルがアクティブになります。この冗長化では、常にいずれかのトンネルを経由して VPC への接続を保持する必要があります。

バージョン 9.7.1 以降の Cisco ASA は、アクティブ/アクティブモードをサポートします。これらの Cisco ASA を使用する場合は、両方のトンネルを同時にアクティブにすることができます。この冗長化では、常にいずれかのトンネルを経由して VPC への接続を保持する必要があります。

Cisco デバイスの場合は、次の作業を行う必要があります。
+ 外部インターフェイスを設定します。
+ Crypto ISAKMP Policy Sequence の数値が一意であることを確認します。
+ Crypto List Policy Sequence の数値が一意であることを確認します。
+ Crypto IPsec Transform Set および Crypto ISAKMP Policy Sequence と、デバイスに設定された他のすべての IPsec トンネルの整合性が確保されていることを確認します。
+ SLA モニタリング番号が一意であることを確認します。
+ カスタマーゲートウェイデバイスとローカルネットワークとの間でトラフィックを動かす内部ルーティングをすべて設定します。

# AWS Site-to-Site VPN カスタマーゲートウェイデバイスのダウンロード可能な動的ルーティング設定ファイル
<a name="cgw-dynamic-routing-examples"></a>

Site-to-Site VPN 接続設定に固有の値を含むサンプル設定ファイルをダウンロードするには、Amazon VPC コンソール、 AWS コマンドライン、または Amazon EC2 API を使用します。詳細については、「[ステップ 6: 設定ファイルをダウンロードする](SetUpVPNConnections.md#vpn-download-config)」を参照してください。

また、Site-to-Site VPN 接続設定に固有の値を含まないダイナミックルーティング用の汎用設定ファイルの例をダウンロードすることもできます。[dynamic-routing-examples.zip](samples/dynamic-routing-examples.zip)

これらのファイルは、一部のコンポーネントにプレースホルダー値を使用します。たとえば、以下を使用します。
+ VPN 接続 ID 、カスタマーゲートウェイ ID および仮想プライベートゲートウェイ ID の値の例
+ リモート (外部) IP アドレス AWS エンドポイントのプレースホルダー (*AWS\$1ENDPOINT\$11* および *AWS\$1ENDPOINT\$12*)
+ カスタマーゲートウェイデバイスのインターネットルーティング可能な外部インターフェイスの IP アドレスのプレースホルダー (*your-cgw-ip-address*)
+ 事前共有キー値のプレースホルダ (事前共有キー)
+ トンネルの内部 IP アドレスの値の例。
+ MTU 設定の値の例。

**注記**  
サンプルコンフィギュレーションファイルで提供されている MTU 設定は、例にすぎません。状況に応じた最適な MTU 値の設定については、「[AWS Site-to-Site VPN カスタマーゲートウェイデバイスのベストプラクティス](cgw-best-practice.md)」を参照してください。

プレースホルダー値を指定することに加えて、ファイルはほとんどの AWS リージョンで AES128, SHA1、および Diffie-Hellman グループ 2 の Site-to-Site VPN 接続、 AWS GovCloud リージョンで AES128, SHA2、および Diffie-Hellman グループ 14 の最小要件を指定します。また、[認証](vpn-tunnel-authentication-options.md)用の事前共有キーも指定します。追加のセキュリティアルゴリズム、Diffie-Hellman グループ、プライベート証明書、IPv6 トラフィックを活用するには、サンプル設定ファイルを変更する必要があります。

次の図は、カスタマーゲートウェイデバイスに設定されているさまざまなコンポーネントの概要を示しています。これには、トンネルインターフェイスの IP アドレスの値の例が含まれます。

![\[動的ルーティングを使用するカスタマーゲートウェイデバイス\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/cgw-bgp.png)


# AWS Virtual Private Network カスタマーゲートウェイデバイスの動的ルーティングを設定する
<a name="cgw-dynamic-routing-example-interface"></a>

以下は、ユーザーインターフェイス (使用可能な場合) を使用してカスタマーゲートウェイデバイスを設定する手順の例です。

------
#### [ Check Point ]

以下は、Gaia ウェブポータルと Check Point SmartDashboard を使用して、R77.10 以降を実行する Check Point Security Gateway デバイスを設定するステップです。また、Check Point Support Center の [Amazon Web Services (AWS) VPN BGP](https://support.checkpoint.com/results/sk/sk108958) の記事も参照してください。

**トンネルインターフェイスを設定するには**

最初のステップは、VPN トンネルを作成し、各トンネル用のカスタマーゲートウェイと仮想プライベートゲートウェイのプライベート (内部) IP アドレスを提供することです。最初のトンネルを作成するには、設定ファイルの `IPSec Tunnel #1` セクションで提供される情報を使用します。2 番目のトンネルを作成するには、設定ファイルの `IPSec Tunnel #2` セクションで提供される値を使用します。

1. SSH でセキュリティゲートウェイに接続します。デフォルト以外のシェルを使用している場合は、次のコマンドを実行して、clish に変更します。`clish`

1. 次のコマンドを実行して、カスタマーゲートウェイ ASN (カスタマーゲートウェイの作成時に提供された ASN AWS) を設定します。

   ```
   set as 65000
   ```

1. 設定ファイルの `IPSec Tunnel #1` セクションで提供されている情報を使用して、最初のトンネル用のトンネルインターフェイスを作成します。`AWS_VPC_Tunnel_1` など、トンネルに一意の名前をつけます。

   ```
   add vpn tunnel 1 type numbered local 169.254.44.234 remote 169.254.44.233 peer AWS_VPC_Tunnel_1 
   set interface vpnt1 state on 
   set interface vpnt1 mtu 1436
   ```

1. 2 番目のトンネルを作成するには、設定ファイルの `IPSec Tunnel #2` セクションで提供されている情報を使用して、コマンドを繰り返します。`AWS_VPC_Tunnel_2` など、トンネルに一意の名前をつけます。

   ```
   add vpn tunnel 1 type numbered local 169.254.44.38 remote 169.254.44.37 peer AWS_VPC_Tunnel_2 
   set interface vpnt2 state on 
   set interface vpnt2 mtu 1436
   ```

1. 仮想プライベートゲートウェイ ASN を設定します。

   ```
   set bgp external remote-as 7224 on 
   ```

1. 最初のトンネルの BGP を、設定ファイルの `IPSec Tunnel #1` セクションで提供される情報を使用して設定します。

   ```
   set bgp external remote-as 7224 peer 169.254.44.233 on 
   set bgp external remote-as 7224 peer 169.254.44.233 holdtime 30
   set bgp external remote-as 7224 peer 169.254.44.233 keepalive 10
   ```

1. 2 番目のトンネルの BGP を、設定ファイルの `IPSec Tunnel #2` セクションで提供される情報を使用して設定します。

   ```
   set bgp external remote-as 7224 peer 169.254.44.37 on 
   set bgp external remote-as 7224 peer 169.254.44.37 holdtime 30
   set bgp external remote-as 7224 peer 169.254.44.37 keepalive 10
   ```

1. 設定を保存します。

   ```
   save config
   ```

**BGP ポリシーを作成するには**

次に、 AWSによってアドバタイズされたルートのインポートを許可する BGP ポリシーを作成します。次に、ローカルルートを AWSにアドバタイズするようにカスタマーゲートウェイを設定します。

1. Gaia WebUI で、[**Advanced Routing**]、[**Inbound Route Filters**] を選択します。[**Add**] を選択し、[**Add BGP Policy (Based on AS)**] を選択します。

1. [**Add BGP Policy (BGP ポリシーの追加)**] の最初のフィールドで 512 から 1024 までの範囲の値を選択し、2 番目のフィールドに仮想プライベートゲートウェイ ASN (例: `7224`) を入力します。

1. **[保存]** を選択します。

**ローカルルートをアドバタイズするには**

次のステップは、ローカルインターフェイスルートを分散するためのものです。また、静的ルーティングや、動的ルーティングプロトコルによって得られたルーティングなど、さまざまなソースからのルートを再分散できます。詳細については、「[Gaia Advanced Routing R77 Versions Administration Guide](https://sc1.checkpoint.com/documents/R77/CP_R77_Gaia_Advanced_Routing_WebAdminGuide/html_frameset.htm)」を参照してください。

1. Gaia WebUI で、[**Advanced Routing**]、[**Routing Redistribution**] の順に選択します。[**Add Redistribution From**]、[**Interface (インターフェイス)**] の順に選択します。

1. [**To Protocol**] で、仮想プライベートゲートウェイ ASN; (例: `7224`) を選択します。

1. [**Interface**] では内部インターフェイスを選択します。**[保存]** を選択します。

**新しいネットワークオブジェクトを定義するには**

次に、仮想プライベートゲートウェイのパブリック (外部) IP アドレスを指定して、各 VPN トンネル用のネットワークオブジェクトを作成します。後で、VPN コミュニティのサテライトゲートウェイとしてこれらのオブジェクトを追加します。また、VPN ドメインのプレースホルダーとして機能する空グループを作成する必要があります。

1. Check Point SmartDashboard を開きます。

1. [**Groups**] では、コンテキストメニューを開き、[**Groups**]、[**Simple Group**] の順に選択します。各ネットワークオブジェクトに対して同じグループを使用できます。

1. [**Network Objects**] では、コンテキストメニュー (右クリック) を開き、[**New**]、[**Interoperable Device**] の順に選択します。

1. [**Name (名前)**] には、ステップ 1 でトンネル用に指定した名前 (例: `AWS_VPC_Tunnel_1` または `AWS_VPC_Tunnel_2`) を入力します。

1. [**IPv4 Address**] には、設定ファイルで提供される仮想プライベートゲートウェイの外部 IP アドレス (例: `54.84.169.196`) を入力します。設定を保存して、このダイアログボックスを閉じます。  
![\[Check Point の [Interoperable Device] ダイアログボックス\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/check-point-network-device.png)

1. 左のカテゴリーペインで、[**Topology**] を選択します。

1. [**VPN Domain (VPN ドメイン)**] セクションで、[**Manually defined (手動で定義)**] を選択し、ステップ 2 で作成した空のシンプルなグループを参照して選択します。[**OK**] を選択してください。

1. 2 番目のネットワークオブジェクトを作成するには、設定ファイルの `IPSec Tunnel #2` セクション内の情報を使用して、ステップを繰り返します。

1. ゲートウェイネットワークオブジェクトに移動してゲートウェイまたはクラスターオブジェクトを開き、[**Topology**] を選択します。

1. [**VPN Domain (VPN ドメイン)**] セクションで、[**Manually defined (手動で定義)**] を選択し、ステップ 2 で作成した空のシンプルなグループを参照して選択します。[**OK**] を選択してください。
**注記**  
設定済みの既存の VPN ドメインは保持できます。ただし、特に VPN ドメインが自動的に取得されている場合は、新しい VPN 接続で使用または提供されるドメインとホストがその VPN ドメインで宣言されていないことを確認してください。

**注記**  
クラスターを使用している場合は、トポロジーを編集してインターフェイスをクラスターインターフェイスとして定義します。設定ファイルで指定された IP アドレスを使用します。

**VPN コミュニティ、IKE、および IPsec 設定の作成と設定**

次に、Check Point ゲートウェイに VPN コミュニティを作成し、そこに各トンネルのネットワークオブジェクト (相互運用デバイス) を追加します。また、Internet Key Exchange (IKE) および IPsec を設定します。

1. ゲートウェイのプロパティから、カテゴリーペインの [**IPSec VPN**] を選択します。

1. [**Communities**]、[**New**]、[**Star Community**] の順に選択します。

1. コミュニティの名前 (例: `AWS_VPN_Star`) を指定し、カテゴリーペインの [**Center Gateways**] を選択します。

1. [**Add**] を選択して、ゲートウェイまたはクラスターを参加ゲートウェイのリストに追加します。

1. カテゴリーペインで、[**Satellite Gateways**]、[**Add (追加)**] の順に選択し、先に作成した相互運用デバイス (`AWS_VPC_Tunnel_1` および `AWS_VPC_Tunnel_2`) を参加ゲートウェイのリストに追加します。

1. カテゴリーペインで、[**Encryption**] を選択します。[**Encryption Method**] セクションで、[**IKEv1 for IPv4 and IKEv2 for IPv6**] を選択します。[**Encryption Suite**] セクションで、[**Custom**]、[**Custom Encryption**] の順に選択します。
**注記**  
IKEv1 機能の [**IKEv1 for IPv4 and IKEv2 for IPv6**] オプションを選択します。

1. ダイアログボックスで次のように暗号化プロパティを設定し、完了したら [**OK**] を選択します。
   + IKE Security Association (フェーズ 1) のプロパティ
     + **Perform key exchange encryption with**: AES-128
     + **Perform data integrity with**: SHA-1
   + IPsec Security Association (フェーズ 2) のプロパティ
     + **Perform IPsec data encryption with**: AES-128
     + **Perform data integrity with**: SHA-1

1. カテゴリーペインで [**Tunnel Management**] を選択します。[**Set Permanent Tunnels**]、[**On all tunnels in the community**] の順に選択します。[**VPN Tunnel Sharing**] セクションで、[**One VPN tunnel per Gateway pair**] を選択します。

1. カテゴリーペインで [**Advanced Settings**] を展開し、[**Shared Secret**] を選択します。

1. 最初のトンネルのピア名を選択し、[**Edit (編集)**] を選択して、設定ファイルの `IPSec Tunnel #1` セクションで指定されている事前共有キーを入力します。

1. 2 番目のトンネルのピア名を選択し、[**Edit (編集)**] を選択して、設定ファイルの `IPSec Tunnel #2` セクションで指定されている事前共有キーを入力します。  
![\[Check Point の [Interoperable Shared Secret] ダイアログボックス\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/check-point-shared-secret.png)

1. さらに [**Advanced Settings (詳細設定)**] カテゴリで [**Advanced VPN Properties (詳細な VPN プロパティ)**] を選択し、プロパティを次のように設定して、完了したら [**OK**] を選択します。
   + IKE (フェーズ 1):
     + **Use Diffie-Hellman group**: `Group 2 (1024 bit)`
     + **Renegotiate IKE security associations every** `480` **minutes**
   + IPsec (フェーズ 2):
     + [**Use Perfect Forward Secrecy**] を選択します。
     + **Use Diffie-Hellman group**: `Group 2 (1024 bit)`
     + **Renegotiate IPsec security associations every** `3600` **seconds**

**ファイアウォールルールを作成するには**

次に、ファイアウォールルールとディレクショナルマッチルールを使用し、VPC とローカルネットワーク間での通信を許可するポリシーを設定します。その後、ゲートウェイにポリシーをインストールします。

1. SmartDashboard で、ゲートウェイの [**Global Properties**] を選択します。カテゴリーペインで [**VPN**] を展開し、[**Advanced**] を選択します。

1. [**Enable VPN Directional Match in VPN Column**] を選択し、[**OK**] を選択します。

1. SmartDashboard で [**Firewall**] を選択し、次のルールでポリシーを作成します。
   + VPC サブネットに対して必須プロトコル経由でのローカルネットワークとの通信を許可する。
   + ローカルネットワークに対して必須プロトコル経由での VPC サブネットとの通信を許可する。

1. VPN 列のセルのコンテキストメニューを開いて、[**Edit Cell**] を選択します。

1. [**VPN Match Conditions**] ダイアログボックスで、[**Match traffic in this direction only**] を選択します。それぞれで [**Add (追加)**] を選択して以下のディレクショナルマッチルールを作成し、完了したら [**OK**] を選択します。
   + `internal_clear` > VPN コミュニティ (先に作成した VPN スターコミュニティ。例: `AWS_VPN_Star`)
   + VPN コミュニティ > VPN コミュニティ
   + VPN コミュニティ > `internal_clear`

1. SmartDashboard で、[**Policy**]、[**Install**] の順に選択します。

1. ダイアログボックスでゲートウェイを選択し、[**OK**] を選択してポリシーをインストールします。

**tunnel\$1keepalive\$1method プロパティを変更するには**

Check Point ゲートウェイでは、IKE の関連付けが停止したときに Dead Peer Detection (DPD) を使用して識別できます。永続トンネルの DPD を設定するには、永続トンネルを AWS VPN コミュニティで設定する必要があります。

デフォルトでは、VPN ゲートウェイの `tunnel_keepalive_method` プロパティは `tunnel_test` に設定されます。この値を `dpd` に変更する必要があります。DPD モニタリングが必要な VPN コミュニティ内の各 VPN ゲートウェイは、サードパーティー製 VPN ゲートウェイを含め、`tunnel_keepalive_method` プロパティで設定する必要があります。同じゲートウェイに対して異なるモニタリングメカニズムを設定することはできません。

GuiDBedit ツールを使用して `tunnel_keepalive_method` プロパティを更新できます。

1. Check Point SmartDashboard を開き、[**Security Management Server**]、[**Domain Management Server**] の順に選択します。

1. [**File**]、[**Database Revision Control...**] の順に選択し、リビジョンのスナップショットを作成します。

1. SmartDashboard、SmartView Tracker、SmartView Monitor など、すべての SmartConsole ウィンドウを閉じます。

1. GuiBDedit ツールを起動します。詳細については、Check Point サポートセンターの「[Check Point Database Tool](https://support.checkpoint.com/results/sk/sk13009)」という記事を参照してください。

1. [**Security Management Server**]、[**Domain Management Server**] の順に選択します。

1. 左上のペインで、[**Table**]、[**Network Objects**]、[**network\$1objects**] の順に選択します。

1. 右上のペインで、関連する [**Security Gateway**]、[**Cluster**] オブジェクトを選択します。

1. Ctrl\$1F キーを押すか、[**Search**] メニューを使用して以下を検索します。`tunnel_keepalive_method`

1. 下のペインで、[`tunnel_keepalive_method`] のコンテキストメニューを開き、[**Edit...**] を選択します。[**dpd**]、[**OK**] の順に選択します。

1.  AWS VPN コミュニティの一部である各ゲートウェイに対して、ステップ 7～9 を繰り返します。

1. [**File**]、[**Save All**] の順に選択します。

1. GuiDBedit ツールを閉じます。

1. Check Point SmartDashboard を開き、[**Security Management Server**]、[**Domain Management Server**] の順に選択します。

1. 関連する [**Security Gateway**]、[**Cluster**] オブジェクトにポリシーをインストールします。

詳細については、Check Point Support Center の「[New VPN features in R77.10](https://support.checkpoint.com/results/sk/sk97746)」という記事を参照してください。

**TCP MSS クランプを有効にするには**

TCP MSS クランプは TCP パケットの最大セグメントサイズを小さくしてパケット断片化を防ぎます。

1. 次のディレクトリに移動します。`C:\Program Files (x86)\CheckPoint\SmartConsole\R77.10\PROGRAM\`

1. `GuiDBEdit.exe` ファイルを実行して Check Point Database Tool を開きます。

1. [**Table**]、[**Global Properties**]、[**properties**] の順に選択します。

1. `fw_clamp_tcp_mss` で、[**Edit**] を選択します。値を `true` に変更し、[**OK**] を選択します。

**トンネルのステータスを確認するには**  
エキスパートモードのコマンドラインツールから次のコマンドを実行して、トンネルの状態を確認できます。

```
vpn tunnelutil
```

表示されたオプションで、IKE 関連付けを検証するには [**1**] を、IPsec 関連付けを検証するには [**2**] を選択します。

また、Check Point Smart Tracker Log を使用して、接続内のパケットが暗号化されていることを検証できます。たとえば次のログは、VPC へのパケットがトンネル 1 経由で送信され、暗号化されていることを示します。

![\[Check Point ログファイル\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/check-point-log.png)


------
#### [ SonicWALL ]

SonicOS 管理インターフェイスを使用して SonicWALL デバイスを設定できます。トンネルの設定方法の詳細については、「[AWS Site-to-Site VPN カスタマーゲートウェイデバイスの静的ルーティングを設定する](cgw-static-routing-example-interface.md)」を参照してください。

このSonicOS 管理インターフェイスを使用して、デバイスの BGP を設定することはできません。代わりに、設定ファイル例の [**BGP**] というセクションの下にあるコマンドライン手順を使用します。

------

## Cisco デバイス: 追加情報
<a name="cgw-dynamic-routing-examples-cisco"></a>

一部の Cisco ASA ではアクティブ/スタンバイモードのみがサポートされています。これらの Cisco ASA を使用する場合は、アクティブなトンネルを一度に 1 個のみ保持できます。最初のトンネルが利用不可になった場合は、他方のスタンバイトンネルがアクティブになります。この冗長化では、常にいずれかのトンネルを経由して VPC への接続を保持する必要があります。

バージョン 9.7.1 以降の Cisco ASA は、アクティブ/アクティブモードをサポートします。これらの Cisco ASA を使用する場合は、両方のトンネルを同時にアクティブにすることができます。この冗長化では、常にいずれかのトンネルを経由して VPC への接続を保持する必要があります。

Cisco デバイスの場合は、次の作業を行う必要があります。
+ 外部インターフェイスを設定します。
+ Crypto ISAKMP Policy Sequence の数値が一意であることを確認します。
+ Crypto List Policy Sequence の数値が一意であることを確認します。
+ Crypto IPsec Transform Set および Crypto ISAKMP Policy Sequence と、デバイスに設定された他のすべての IPsec トンネルの整合性が確保されていることを確認します。
+ SLA モニタリング番号が一意であることを確認します。
+ カスタマーゲートウェイデバイスとローカルネットワークとの間でトラフィックを動かす内部ルーティングをすべて設定します。

## Juniper デバイス: 追加情報
<a name="cgw-dynamic-routing-examples-juniper"></a>

次の情報は、Juniper J シリーズおよび SRX カスタマーゲートウェイデバイスの設定ファイルの例に適用されます。
+ 外部インターフェイスは *ge-0/0/0.0* と呼ばれます。
+ トンネルインターフェイス ID は *st0.1* および *st0.2* と呼ばれます。
+ アップリンクインターフェイスのセキュリティゾーンを確実に特定します (設定情報ではデフォルトゾーンの 'untrust' を使用します)。
+ 内部インターフェイスのセキュリティゾーンを確実に特定します (設定情報ではデフォルトゾーンの 'trust' を使用します)。

# Windows Server を AWS Site-to-Site VPN カスタマーゲートウェイデバイスとして設定する
<a name="customer-gateway-device-windows"></a>

Windows Server を実行するサーバーを VPC のカスタマーゲートウェイデバイスとして設定できます。Windows Server を VPC 内の EC2 インスタンスで実行しているか独自のサーバーで実行しているかに関わらず、次のプロセスを使用します。次の手順は、Windows Server 2012 R2 以降に適用されます。

**Topics**
+ [Windows インスタンスの設定](#cgw-device-windows-server-configure-instance)
+ [ステップ 1: VPN 接続を作成し、VPC を設定する](#cgw-device-windows-server-vpn)
+ [ステップ 2: VPN 接続の設定ファイルをダウンロードする](#cgw-device-windows-server-config)
+ [ステップ 3: Windows Server を設定する](#cgw-device-windows-server-configure)
+ [ステップ 4: VPN トンネルを設定する](#cgw-device-windows-server-setup-tunnel)
+ [ステップ 5: 停止しているゲートウェイの検出を有効にする](#cgw-device-windows-server-gateway-detection)
+ [ステップ 6: VPN 接続をテストする](#cgw-device-windows-server-test-connection)

## Windows インスタンスの設定
<a name="cgw-device-windows-server-configure-instance"></a>

Windows AMI から起動した EC2 インスタンスで Windows Server を設定する場合は、次の手順を実行します。
+ インスタンスの送信元/送信先チェックを無効にします。

  1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。

  1. Windows Server インスタンスを選択して、[**Actions**]、[**Networking**]、[**Change source/destination check**] と選択します。[**Stop**] を選択してから、[**Save**] を選択します。
+ 他のインスタンスからトラフィックをルーティングできるように、アダプタの設定を更新します。

  1. Windows インスタンスに接続します。詳細については、「[Windows インスタンスへの接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html)」を参照してください。

  1. [コントロールパネル] を開き、[デバイスマネージャー] を起動します。

  1. [**ネットワークアダプター**] ノードを展開します。

  1. ネットワークアダプタ (インスタンスタイプに応じて、Amazon Elastic ネットワークアダプタまたは Intel 82599 仮想関数) を選択し、[** Action **]、[** Properties**] の順に選択します。

  1. [**詳細設定**] タブで、[**IPv4 Checksum Offload**]、[**TCP Checksum Offload (IPv4)**]、および [**UDP Checksum Offload (IPv4)**] の各プロパティを無効にし、[**OK**] を選択します。
+ Elastic IP アドレスをアカウントに割り当てて、インスタンスに関連付けます。詳細については、「*Amazon EC2 ユーザーガイド*」の「[Elastic IP アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)」を参照してください。このアドレスは書き留めておきます。カスタマーゲートウェイを作成するときに必要になります。
+ インスタンスのセキュリティグループのルールでアウトバウンドの IPsec トラフィックが許可されていることを確認します。デフォルトでは、セキュリティグループは、すべてのアウトバウンドトラフィックを許可します。ただし、セキュリティグループのアウトバウンドルールが元の状態から変更されている場合、IPsec トラフィック用にアウトバウンドのカスタムプロトコルルール (IP プロトコル 50、IP プロトコル 51、UDP 500) を作成する必要があります。

Windows インスタンスが配置されているネットワークの CIDR 範囲 (`172.31.0.0/16` など) を書き留めます。

## ステップ 1: VPN 接続を作成し、VPC を設定する
<a name="cgw-device-windows-server-vpn"></a>

VPC から VPN 接続を作成するには、次の手順を実行します。

1.  仮想プライベートゲートウェイを作成し、VPC にアタッチします。詳細については、「[仮想プライベートゲートウェイの作成](SetUpVPNConnections.md#vpn-create-vpg)」を参照してください。

1. VPN 接続と新しいカスタマーゲートウェイを作成します。カスタマーゲートウェイの場合、Windows Server のパブリック IP アドレスを指定します。VPN 接続の場合は、静的ルーティングを選択し、Windows Server が配置されているネットワークの CIDR 範囲 (例: `172.31.0.0/16`) を入力します。詳細については、「[ステップ 5: VPN 接続を作成する](SetUpVPNConnections.md#vpn-create-vpn-connection)」を参照してください。

VPN 接続を作成したら、VPN 接続を介した通信を有効にするように VPC を設定します。

**VPC を設定するには**
+ Windows Server と通信するインスタンスを起動するためのプライベートサブネットを VPC で作成します (まだ、ない場合)。詳細については、「[VPC でサブネットを作成する](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html#AddaSubnet)」を参照してください。
**注記**  
プライベートサブネットは、インターネットゲートウェイへのルートがないサブネットです。このサブネットのルーティングについては、次の項目で説明します。
+ VPN 接続のルートテーブルを更新します。
  + 仮想プライベートゲートウェイをターゲットに指定し、Windows Server のネットワーク (CIDR 範囲) を宛先に指定して、プライベートサブネットのルートテーブルにルートを追加します。詳細については、「*Amazon VPC ユーザーガイド*」の「[ルートテーブルでルートを追加および削除する](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes)」を参照してください。
  + 仮想プライベートゲートウェイのルート伝達を有効にします。詳細については、「[(仮想プライベートゲートウェイ) ルートテーブルでルート伝播を有効にする](SetUpVPNConnections.md#vpn-configure-routing)」を参照してください。
+ VPC とネットワーク間の通信を許可する、インスタンスのセキュリティグループを作成します。
  + ネットワークからのインバウンド RDP または SSH アクセスを許可するルールを追加します。これにより、ネットワークから VPC のインスタンスに接続できます。たとえば、ネットワークのコンピュータが VPC 内の Linux インスタンスにアクセスできるようにするには、SSH タイプのインバウンドルールを作成し、ソースをネットワークの CIDR 範囲 (例: `172.31.0.0/16`) に設定します。詳細については、*Amazon VPC ユーザーガイド*の「[VPC のセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)」を参照してください。
  + ネットワークからのインバウンド ICMP アクセスを許可するルールを追加します。これにより、Windows Server から VPC 内のインスタンスへの ping を実行して、VPN 接続をテストできます。

## ステップ 2: VPN 接続の設定ファイルをダウンロードする
<a name="cgw-device-windows-server-config"></a>

Amazon VPC コンソールを使用して、VPN 接続用の Windows Server 設定ファイルをダウンロードできます。

**設定ファイルをダウンロードするには**

1. Amazon VPC コンソール ([https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)) を開きます。

1. ナビゲーションペインで、[**Site-to-Site VPN Connections (Site-to-Site VPN 接続)**] を選択します。

1. VPN 接続を選択してから、[**設定のダウンロード**] を選択します。

1. ベンダーとして [**Microsoft**]、プラットフォームとして [**Windows Server**]、ソフトウェアとして [**2012 R2**] を選択します。[**ダウンロード**] を選択します。ファイルを開くか保存できます。

設定ファイルには、次の例のような情報のセクションが含まれています。この情報はトンネルごとに 1 回ずつ 2 回表示されます。

```
vgw-1a2b3c4d Tunnel1
--------------------------------------------------------------------	
Local Tunnel Endpoint:       203.0.113.1
Remote Tunnel Endpoint:      203.83.222.237
Endpoint 1:                  [Your_Static_Route_IP_Prefix]
Endpoint 2:                  [Your_VPC_CIDR_Block]
Preshared key:               xCjNLsLoCmKsakwcdoR9yX6GsEXAMPLE
```

`Local Tunnel Endpoint`  
VPN 接続の作成時にカスタマーゲートウェイ用に指定した IP アドレスです。

`Remote Tunnel Endpoint`  
接続の AWS 側で VPN 接続を終了する仮想プライベートゲートウェイの 2 つの IP アドレスのいずれか。

`Endpoint 1`  
VPN 接続を作成したときに静的ルートとして指定した IP プレフィックスです。VPN 接続を使用して VPC にアクセスすることを許可された、ネットワークの IP アドレスです。

`Endpoint 2`  
仮想プライベートゲートウェイにアタッチされた VPC の IP アドレス範囲 (CIDR ブロック) (例: 10.0.0.0/16) です。

`Preshared key`  
`Local Tunnel Endpoint` と `Remote Tunnel Endpoint` との間で IPsec VPN 接続を確立するために使用される事前共有キーです。

VPN 接続の一部として両方のトンネルを設定することをお勧めします。 各トンネルは、VPN 接続の Amazon 側の個別の Site-to-Site VPN コンセントレータに接続します。一度に起動できるトンネルは 1 つだけですが、1 番目のトンネルが停止すると、2 番目のトンネルが自動的に接続を確立します。冗長トンネルを設定すると、デバイスが故障した場合でも継続的な可用性を確保できます。一度に使用できるトンネルは 1 つだけであるため、その 1 つのトンネルが停止したことが VPC コンソールに表示されます。これは予期されている動作のため、お客様が操作を行う必要はありません。

2 つのトンネルを設定すると、デバイス障害が発生した場合 AWS、VPN 接続は数分以内に仮想プライベートゲートウェイの 2 番目のトンネルに自動的にフェイルオーバーします。カスタマーゲートウェイデバイスを設定するときは、両方のトンネルを設定することが重要です。

**注記**  
は、仮想プライベートゲートウェイで定期メンテナンスを随時 AWS 実行します。このメンテナンスにより、VPN 接続 の 2 つのトンネルのうち 1 つが短時間無効になることがあります。このメンテナンスの実行中、VPN 接続は自動的に 2 番目のトンネルにフェイルオーバーします。

Internet Key Exchange (IKE) および IPsec Security Associations (SA) についての追加情報が、ダウンロードした設定ファイルに記述されています。

```
MainModeSecMethods:        DHGroup2-AES128-SHA1
MainModeKeyLifetime:       480min,0sess
QuickModeSecMethods:       ESP:SHA1-AES128+60min+100000kb
QuickModePFS:              DHGroup2
```

`MainModeSecMethods`  
IKE SA 用の暗号化および認証のアルゴリズムです。これらは、VPN 接続用の推奨設定と、Windows Server IPsec VPN 接続用のデフォルト設定です。

`MainModeKeyLifetime`  
IKE SA キーの有効期間です。  これは VPN 接続用の推奨設定であり、Windows Server IPsec VPN 接続用のデフォルト設定です。

`QuickModeSecMethods`  
IPsec SA 用の暗号化および認証のアルゴリズムです。これらは、VPN 接続用の推奨設定と、Windows Server IPsec VPN 接続用のデフォルト設定です。

`QuickModePFS`  
 IPsec セッションにはマスターキー PFS (Perfect Forward Secrecy) を使用することを推奨します。

## ステップ 3: Windows Server を設定する
<a name="cgw-device-windows-server-configure"></a>

VPN トンネルを設定する前に、Windows Server でルーティングとリモートアクセスサービスをインストールして設定する必要があります。これにより、リモートユーザーがお客様のネットワーク上のリソースにアクセスできるようになります。

**ルーティングおよびリモートアクセスサービスをインストールするには**

1. Windows Server にログオンします。

1. [**Start**] メニューに移動し、[**Server Manager**] を選択します。

1. ルーティングおよびリモートアクセスサービスをインストールします。

   1. [**Manage**]メニューから、[**Add Roles and Features**] を選択します。

   1. [**Before You Begin**] ページで、サーバーが前提条件を満たしていることを確認し、[**Next**] を選択します。

   1. [**Role-based or feature-based installation**] を選択し、次に [**Next**] を選択します。

   1. [**Select a server from the server pool**] を選択し、Windows Server を選択して [**Next**] を選択します。

   1. リストで [**Network Policy and Access Services**] を選択します。表示されるダイアログボックスで、[**Add Features**] を選択してこのロールに必要な機能を確認します。

   1. 同じリストで、[**リモート アクセス**]、[**次へ**] の順に選択します。

   1. **[Select features]** (機能を選択) ページで、**[Next]** (次へ) を選択します。

   1. [**Network Policy and Access Services**] ページで、[**Next**] を選択します。

   1. [**Remote Access**] ページで、[**Next**] を選択します。次のページで、[**DirectAccess and VPN (RAS)**] を選択します。表示されるダイアログボックスで、[**Add Features**] を選択してこのロールサービスに必要な機能を確認します。同じリストで、[**Routing**] を選択し、次に [**Next**] を選択します。

   1. [**Web Server Role (IIS)**] ページで、[**Next**] を選択します。デフォルトの選択のまま残して、[**Next**] を選択します。

   1. **[インストール]** を選択します。インストールが完了したら、[**Close**] を選択してください。

**ルーティングおよびリモートアクセスサーバーを設定して有効にするには**

1. ダッシュボードで、[**Notifications**] (フラグのアイコン) を選択します。デプロイ後の設定を完了するためのタスクが必要になる場合があります。[**Open the Getting Started Wizard**] リンクを選択します。

1. [**Deploy VPN only**] を選択します。

1. [**Routing and Remote Access**] ダイアログボックスで、サーバー名を選択します。さらに [**アクション**] を選択して [**Configure and Enable Routing and Remote Access (Routing and Remote Access の設定と有効化)**] を選択します。

1. [**Routing and Remote Access Server Setup Wizard**] の最初のページで、[**Next**] を選択します。

1. [**構成**] ページで、[**カスタム構成**]、[**次へ**] の順に選択します。

1. [**LAN ルーティング**]、[**次へ**]、[**完了**] の順に選択します。

1. [**Routing and Remote Access**] ダイアログボックスにメッセージが表示されたら、[**Start service**] を選択します。

## ステップ 4: VPN トンネルを設定する
<a name="cgw-device-windows-server-setup-tunnel"></a>

ダウンロードした設定ファイルに含まれている netsh スクリプトを実行するか、Windows Server のユーザーインターフェイスを使用して、VPN トンネルを設定できます。

**重要**  
IPsec セッションにはマスターキーの完全前方秘匿性 (PFS) を使用することをお勧めします。netsh スクリプトを実行する場合は、PFS (`qmpfs=dhgroup2`) を有効にするパラメータが含まれます。Windows のユーザーインターフェイスを使用して PFS を有効にすることはできません。コマンドラインを使用して有効にする必要があります。

**Topics**
+ [オプション 1: netsh スクリプトを実行する](#cgw-device-windows-server-run-netsh)
+ [オプション 2: Windows Server ユーザーインターフェイスを使用する](#cgw-device-windows-server-ui)

### オプション 1: netsh スクリプトを実行する
<a name="cgw-device-windows-server-run-netsh"></a>

ダウンロードした設定ファイルから netsh スクリプトをコピーし、変数を置き換えます。スクリプトの例を次に示します。

```
netsh advfirewall consec add rule Name="vgw-1a2b3c4d Tunnel 1" ^
Enable=Yes Profile=any Type=Static Mode=Tunnel ^
LocalTunnelEndpoint=Windows_Server_Private_IP_address ^
RemoteTunnelEndpoint=203.83.222.236 Endpoint1=Your_Static_Route_IP_Prefix ^
Endpoint2=Your_VPC_CIDR_Block Protocol=Any Action=RequireInClearOut ^
Auth1=ComputerPSK Auth1PSK=xCjNLsLoCmKsakwcdoR9yX6GsEXAMPLE ^
QMSecMethods=ESP:SHA1-AES128+60min+100000kb ^
ExemptIPsecProtectedConnections=No ApplyAuthz=No QMPFS=dhgroup2
```

[**Name**]: 推奨された名前 (`vgw-1a2b3c4d Tunnel 1)`) を選択した名前で置き換えることができます。

[**LocalTunnelEndpoint**]: ネットワークの Windows Server のプライベート IP アドレスを入力します。

[**Endpoint1**]: Windows Server が存在するネットワークの CIDR ブロック (たとえば、`172.31.0.0/16`) です。この値を二重引用符 (") で囲みます。

[**Endpoint2**]: VPC または VPC のサブネットの CIDR ブロック (たとえば、`10.0.0.0/16`) です。この値を二重引用符 (") で囲みます。

更新したスクリプトを Windows Server のコマンドプロンプトウィンドウで実行します。(^ を使用すると、コマンド行で折り返しテキストの切り取りと貼り付けができます)。この VPN 接続に 2 番目の VPN トンネルを設定するには、設定ファイルにある 2 番目の netsh スクリプトを使用してこのプロセスを繰り返します。

作業が終了したら、「[Windows ファイアウォールを設定する](#cgw-device-windows-server-firewall)」を参照してください。

netsh パラメータの詳細については、「*Microsoft TechNet ライブラリ*」の「[Netsh AdvFirewall Consec Commands](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd736198(v=ws.10)?redirectedfrom=MSDN#BKMK_2_set)」を参照してください。

### オプション 2: Windows Server ユーザーインターフェイスを使用する
<a name="cgw-device-windows-server-ui"></a>

Windows Server ユーザーインターフェイスを使用して VPN トンネルを設定することもできます。

**重要**  
Windows Server ユーザーインターフェイスを使用してマスターキー PFS (Perfect Forward Secrecy) を有効にすることはできません。PFS を有効にするには、「[マスターキー PFS (Perfect Forward Secrecy) を有効にする](#cgw-device-windows-server-enable-pfs)」で説明されているように、コマンドラインを使う必要があります。

**Topics**
+ [VPN トンネル用のセキュリティルールを設定する](#cgw-device-windows-server-security-rule)
+ [トンネルの設定を確認する](#cgw-device-windows-server-confirm-tunnel)
+ [マスターキー PFS (Perfect Forward Secrecy) を有効にする](#cgw-device-windows-server-enable-pfs)
+ [Windows ファイアウォールを設定する](#cgw-device-windows-server-firewall)

#### VPN トンネル用のセキュリティルールを設定する
<a name="cgw-device-windows-server-security-rule"></a>

このセクションでは、Windows Server のセキュリティルールを設定して VPN トンネルを作成します。

**VPN トンネル用のセキュリティルールを設定するには**

1. Server Manager を開き、[**Tools**] を選択し、[**Windows Defender Firewall with Advanced Security**] を選択します。

1. [**Connection Security Rules**] を選択し、[**Action**] を選択して [**New Rule**] を選択します。

1. [**New Connection Security Rule**] ウィザードの [**Rule Type**] ページで、[**Tunnel**] を選択し、[**Next**] を選択します。

1. [**Tunnel Type**] ページの [**What type of tunnel would you like to create**] で、[**Custom Configuration**] を選択します。[**Would you like to exempt IPsec-protected connections from this tunnel**] で、デフォルト値を選択したまま ([**No. Send all network traffic that matches this connection security rule through the tunnel**]) にして、[**Next**] を選択します。

1. **[要件]** ページで、**[インバウンド接続の認証情報を要求する] を選択します。[アウトバウンド接続のトンネルを確立しない]** を選択し、**[次へ]** を選択します。

1. [**Tunnel Endpoints (トンネルエンドポイント)**] ページの [**Which computers are in Endpoint 1 (Endpoint 1 のコンピュータ)**] で、[**Add (追加)**] を選択します。ネットワーク (Windows Server カスタマーゲートウェイデバイスの背後にある) の CIDR 範囲 (`172.31.0.0/16` など) を入力し、[**OK**] を選択します。この範囲にはカスタマーゲートウェイデバイスの IP アドレスを含めることができます。

1. [**What is the local tunnel endpoint (closest to computer in Endpoint 1)**] で、[**Edit**] を選択します。[**IPv4 address**] フィールドに Windows Server のプライベート IP アドレスを入力し、[**OK**] を選択します。

1. [**What is the remote tunnel endpoint (closest to computers in Endpoint 2)**] で、[**Edit**] を選択します。[**IPv4 address**] フィールドに、設定ファイルにあるトンネル 1 の仮想プライベートゲートウェイの IP アドレス (「`Remote Tunnel Endpoint`」を参照) を入力し、[**OK**] を選択します。
**重要**  
トンネル 2 に対してこの手順を繰り返す場合は、トンネル 2 のエンドポイントを選択してください。

1. [**Which computers are in Endpoint 2**] で、[**Add**] を選択します。[**This IP address or subnet field**] に VPC の CIDR ブロックを入力して、[**OK**] を選択します。
**重要**  
[**Which computers are in Endpoint 2**] が表示されるまでダイアログボックスをスクロールします。このステップが完了するまで、[**Next**] を選択しないでください。サーバーに接続できなくなります。  
![\[新しい接続セキュリティのルールウィザード: トンネルエンドポイント\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/tunnelendpoints_complete_win2012.png)

1. 指定したすべての設定が正しいことを確認し、[**次へ**] を選択します。

1. [**認証方法**] ページで、[**詳細設定**]、[**カスタマイズ**] の順に選択します。

1. [**First authentication methods**] で、[**Add**] を選択します。

1. [**Preshared key (事前共有キー)**] を選択し、設定ファイルにある事前共有キーの値を入力して、[**OK**] を選択します。
**重要**  
トンネル 2 に対してこの手順を繰り返す場合は、トンネル 2 の事前共有キーを選択してください。

1. [**First authentication is optional**] が選択されていないことを確認し、[**OK**] を選択します。

1. [**次へ**] を選択します。

1. [**プロファイル**] ページで、[**ドメイン**]、[**プライベート**]、[**パブリック**] の 3 つのチェックボックスをすべてオンにします。[**次へ**] を選択します。

1. [**Name**] ページで、接続ルールの名前 (`VPN to Tunnel 1` など) を入力し、[**完了**] を選択します。

上記の手順を繰り返し、設定ファイルにあるトンネル 2 のデータを指定します。

完了すると、VPN 接続に 2 つのトンネルが設定されます。

#### トンネルの設定を確認する
<a name="cgw-device-windows-server-confirm-tunnel"></a>

**トンネルの設定を確認するには**

1. Server Manager を開き、[**Tools**] を選択して、[**Windows Firewall with Advanced Security**] を選択します。次に [**Connection Security Rules**] を選択します。

1. 両方のトンネルについて次の設定を確認します。
   + [**Enabled**] は `Yes`。
   + [**Endpoint 1**] はネットワークの CIDR ブロックです。
   + [**Endpoint 2**] は VPC の CIDR ブロックです。
   + **認証モード** は `Require inbound and clear outbound` です
   + [**Authentication method**] は `Custom`。
   + [**Endpoint 1 port**] は `Any`。
   + [**Endpoint 2 port**] は `Any`。
   + [**Protocol**] は `Any`。

1. 最初のルールを選択し、[**Properties**] を選択します。

1. [**Authentication (認証)**] タブの [**Method (方法)**] で、[**Customize (カスタマイズ)**] を選択します。[**First authentication methods (最初の認証方法)**] に、設定ファイルにあるトンネルの正しい事前共有キーが指定されていることを確認し、[**OK**] を選択します。

1. [詳細] タブで、[ドメイン]、[プライベート]、および [パブリック] がすべて選択されていることを確認します。

1. [**IPsec tunneling**] の [**Customize**] を選択します。IPsec トンネリングが次のように設定されていることを確認して [**OK**] を選択します。再度 [**OK**] を選択してダイアログボックスを閉じます。
   + [**Use IPsec tunneling**] が選択されている。
   + [**Local tunnel endpoint (closest to Endpoint 1)**] に、Windows Server の IP アドレスが設定されている。カスタマーゲートウェイデバイスが EC2 インスタンスである場合、これはインスタンスのプライベート IP アドレスです。
   + [**Remote tunnel endpoint (closest to Endpoint 2)**] に、このトンネルの仮想プライベートゲートウェイの IP アドレスが設定されている。

1. 2 番目のトンネルのプロパティを開きます。このトンネルに対してステップ 4 から 7 までを繰り返します。

#### マスターキー PFS (Perfect Forward Secrecy) を有効にする
<a name="cgw-device-windows-server-enable-pfs"></a>

マスターキー PFS (Perfect Forward Secrecy) を有効にするにはコマンドラインを使用できます。ユーザーインターフェイスを使用してこの機能を有効にすることはできません。

**マスターキー PFS (Perfect Forward Secrecy) を有効にするには**

1. Windows Server で、新しいコマンドプロンプトウィンドウを開きます。

1. 次のコマンドを入力します。`rule_name` は最初の接続ルールに指定した名前に置き換えます。

   ```
   netsh advfirewall consec set rule name="rule_name" new QMPFS=dhgroup2 QMSecMethods=ESP:SHA1-AES128+60min+100000kb
   ```

1. 2 番目のトンネルにステップ 2 を繰り返します。今回は `rule_name` を 2 番目の接続ルールに指定した名前に置き換えます。

#### Windows ファイアウォールを設定する
<a name="cgw-device-windows-server-firewall"></a>

サーバーのセキュリティルールを設定した後、仮想プライベートゲートウェイと連動するように基本的な IPsec 設定を行います。

**Windows ファイアウォールを設定するには**

1. Server Manager を開き、[**Tools**] を選択して [**Windows Defender Firewall with Advanced Security**] を選択します。次に [**Properties**] を選択します。

1. [**IPsec Settings**] タブの [**IPsec exemptions**] で、[**Exempt ICMP from IPsec**] が [**No (default)**] になっていることを確認します。[**IPsec tunnel authorization**] が [**None**] であることを確認します。

1. [**IPsec defaults**] の [**Customize**] を選択します。

1. [**Key exchange (Main Mode)**] の [**Advanced**] を選択し、[**Customize**] を選択します。

1. [**Customize Advanced Key Exchange Settings (キー交換の詳細設定のカスタマイズ)**] の [**Security Method (セキュリティメソッド)**] で、最初のエントリに次のデフォルト値が使用されていることを確認します。
   + 整合性: SHA-1
   + 暗号化: AES-CBC 128
   + キー交換アルゴリズム: Diffie-Hellman Group 2
   + [**Key lifetimes**] で、[**Minutes**] が `480` で [**Sessions**] が `0` であることを確認します。

   これらの設定は、設定ファイルの次のエントリに対応します。

   ```
   MainModeSecMethods: DHGroup2-AES128-SHA1,DHGroup2-3DES-SHA1
   MainModeKeyLifetime: 480min,0sec
   ```

1. [**Key exchange options**] の [**Use Diffie-Hellman for enhanced security**] を選択し、[**OK**] を選択します。

1. [**Data protection (Quick Mode)**] の [**Advanced**] を選択し、[**Customize**] を選択します。

1. [**Require encryption for all connection security rules that use these settings**] を選択します。

1. [**Data integrity and encryption **] は次のようにデフォルト値のままにします。
   + プロトコル: ESP
   + 整合性: SHA-1
   + 暗号化: AES-CBC 128
   + 有効期間: 60 分

   これらの値は設定ファイルの以下のエントリに対応します。

   ```
   QuickModeSecMethods: 
   ESP:SHA1-AES128+60min+100000kb
   ```

1. [**OK**] を選択して [**IPsec の設定のカスタマイズ**] ダイアログボックスに戻り、再度 [**OK**] を選択して設定を保存します。

## ステップ 5: 停止しているゲートウェイの検出を有効にする
<a name="cgw-device-windows-server-gateway-detection"></a>

次に、ゲートウェイが使用できなくなったら検出するように TCP を設定します。それには、レジストリキー `HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters` を変更します。このステップは、これより前のセクションを完了してから実行してください。レジストリキーの変更後、サーバーを再起動する必要があります。

**停止しているゲートウェイを検出するには**

1. Windows Server でコマンドプロンプトまたは PowerShell セッションを起動し、**regedit** と入力してレジストリエディタを起動します。

1. [**HKEY\$1LOCAL\$1MACHINE**]、[**SYSTEM**]、[**CurrentControlSet**]、[**Services**]、[**Tcpip**]、[**Parameters**] の順に展開します。

1. [**Edit**] メニューの [**New**] を選択し、[**DWORD (32-bit) Value**] を選択します。

1. 名前として [**EnableDeadGWDetect**] を入力します。

1. **[EnableDeadGWDetect]** を選択してから、**[編集]**、**[変更]** を選択します。

1. [**Value data**] に「**1**」と入力し、[**OK**] を選択します。

1. レジストリエディタを終了し、サーバーを再起動します。

詳細については、「*Microsoft TechNet ライブラリ*」の「[EnableDeadGWDetect](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc960464(v=technet.10)?redirectedfrom=MSDN)」を参照してください。

## ステップ 6: VPN 接続をテストする
<a name="cgw-device-windows-server-test-connection"></a>

VPN 接続が正常に動作していることテストするには、インスタンスを VPC 内で起動し、インターネットに接続されていないことを確認します。インスタンスを起動した後、Windows Server からプライベート IP アドレスに対して ping を実行します。VPN トンネルは、カスタマーゲートウェイデバイスからトラフィックが生成されるときに開始されます。したがって、ping コマンドも VPN 接続を開始します。

VPN 接続をテストするステップについては、「[AWS Site-to-Site VPN 接続をテストする](HowToTestEndToEnd_Linux.md)」を参照してください。

`ping` コマンドが失敗した場合、次の情報を確認します。
+ VPC 内のインスタンスに対して ICMP が許容されるように、セキュリティグループのルールが設定されていることを確認します。Windows Server が EC2 インスタンスである場合は、セキュリティグループのアウトバウンドルールで IPsec トラフィックが許可されていることを確認します。詳細については、「[Windows インスタンスの設定](#cgw-device-windows-server-configure-instance)」を参照してください。
+ ping 対象のインスタンスのオペレーティングシステムが ICMP に応答するように設定されていることを確認します。Amazon Linux AMI のいずれかを使用することをお勧めします。
+ ping 対象のインスタンスが Windows インスタンスである場合は、そのインスタンスに接続し、Windows ファイアウォールでインバウンド ICMPv4 を有効にします。
+ VPC またはサブネットのルートテーブルが正しく設定されていることを確認します。詳細については、「[ステップ 1: VPN 接続を作成し、VPC を設定する](#cgw-device-windows-server-vpn)」を参照してください。
+ カスタマーゲートウェイデバイスが EC2 インスタンスである場合は、インスタンスに対して送信元/送信先チェックが無効になっていることを確認します。詳細については、「[Windows インスタンスの設定](#cgw-device-windows-server-configure-instance)」を参照してください。

Amazon VPC コンソールの [**VPN Connections**] ページで、使用している VPN 接続を選択します。1 番目のトンネルは起動状態です。2 番目のトンネルは、最初のトンネルが停止するまで使用されませんが、設定は必要です。暗号化されたトンネルを確立するのに数分かかることがあります。

# AWS Site-to-Site VPN カスタマーゲートウェイデバイスのトラブルシューティング
<a name="Troubleshooting"></a>

カスタマーゲートウェイデバイスの問題をトラブルシューティングするときは、構造化されたアプローチを取ることが重要です。このセクションの最初の 2 つのトピックでは、動的ルーティング用に設定されたデバイス (BGP が有効) と静的ルーティング用に設定されたデバイス (BGP が有効でない) をそれぞれ使用する際の問題をトラブルシューティングするための一般的なフローチャートを提供します。これらのトピックでは、Cisco、Juniper、および Yamaha カスタマーゲートウェイデバイス向けのデバイス固有のトラブルシューティングガイドについて説明します。

このセクションのトピック以外にも、[AWS Site-to-Site VPN ログ](monitoring-logs.md) を有効にすると、VPN 接続の問題のトラブルシューティングや解決に非常に役立つ場合があります。一般的なテストの説明については、「[AWS Site-to-Site VPN 接続をテストする](HowToTestEndToEnd_Linux.md)」も参照してください。



**Topics**
+ [BGP を使用するデバイス](Generic_Troubleshooting.md)
+ [BGP なしのデバイス](Generic_Troubleshooting_noBGP.md)
+ [Cisco ASA](Cisco_ASA_Troubleshooting.md)
+ [Cisco IOS](Cisco_Troubleshooting.md)
+ [BGP なしの Cisco IOS](Cisco_Troubleshooting_NoBGP.md)
+ [Juniper JunOS](Juniper_Troubleshooting.md)
+ [Juniper ScreenOS](Juniper_ScreenOs_Troubleshooting.md)
+ [Yamaha](Yamaha_Troubleshooting.md)

**その他のリソース**
+ [Amazon VPC フォーラム](https://repost.aws/tags/TATGuEiYydTVCPMhSnXFN6gA/amazon-vpc)

# ボーダーゲートウェイプロトコルを使用する際 AWS Site-to-Site VPN の接続のトラブルシューティング
<a name="Generic_Troubleshooting"></a>

次の図と表は、ボーダーゲートウェイプロトコル (BGP) を使用するカスタマーゲートウェイデバイスをトラブルシューティングする、一般的な手順を示しています。また、デバイスのデバッグ機能を有効にすることをお勧めします。詳細については、ゲートウェイデバイスのベンダーに問い合わせてください。

![\[一般的なカスタマーゲートウェイデバイスをトラブルシューティングするためのフローチャート\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/troubleshooting-cgw-flow-diagram.png)



|  |  | 
| --- |--- |
| IKE |  IKE Security Association が存在するかどうかを確認します。 IKE Security Association は、IPsec Security Association を確立するために使用されるキーの交換に必要です。 IKE Security Association がない場合は、IKE 設定を確認します。設定ファイルに示されている、暗号化、認証、Perfect Forward Secrecy、およびモードのパラメータを設定する必要があります。 IKE Security Association が存在する場合は、「IPsec」に進みます。  | 
| IPsec |  IPsec Security Association (SA) が存在するかどうかを確認します。 IPsec SA はトンネル自体です。カスタマーゲートウェイデバイスにクエリを実行し、IPsec SA がアクティブかどうかを確認します。設定ファイルに示されている、暗号化、認証、Perfect Forward Secrecy、およびモードのパラメータが設定されていることを確認します。 IPsec SA が存在しない場合は、IPsec 設定を確認します。 IPsec SA が存在する場合は、「トンネル」に進みます。  | 
| トンネル |  必須のファイアウォールルールがセットアップされていることを確認します (ルールのリストについては、「[AWS Site-to-Site VPN カスタマーゲートウェイデバイスのファイアウォールルール](FirewallRules.md)」を参照)。セットアップされている場合は、次に進みます。 トンネル経由の IP 接続があるかどうかを確認します。 トンネルのそれぞれの側に、設定ファイルで指定された IP アドレスが含まれます。仮想プライベートゲートウェイアドレスは、BGP ネイバーアドレスとして使用されます。カスタマーゲートウェイデバイスから、このアドレスに対する ping を実行し、IP トラフィックが正しく暗号化および復号化されているかどうかを確認します。 ping が失敗した場合は、トンネルインターフェイス設定を確認し、正しい IP アドレスが設定されていることを確認します。 ping が成功した場合は、「BGP」に進みます。  | 
| BGP |  BGP ピアリングセッションがアクティブかどうかを確認します。 各トンネルについて、以下を実行します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/Generic_Troubleshooting.html) トンネルがこの状態にない場合は、BGP 設定を確認します。 BGP ピアが確立された場合は、プレフィックスを受け取り、プレフィックスをアドバタイズして、トンネルが正しく設定されます。両方のトンネルがこの状態であることを確認します。  | 

# ボーダーゲートウェイプロトコルを使用しない AWS Site-to-Site VPN 接続のトラブルシューティング
<a name="Generic_Troubleshooting_noBGP"></a>

次の図と表は、ボーダーゲートウェイプロトコル (BGP) を使用しないカスタマーゲートウェイデバイスをトラブルシューティングする、一般的な手順を示しています。また、デバイスのデバッグ機能を有効にすることをお勧めします。詳細については、ゲートウェイデバイスのベンダーに問い合わせてください。

![\[一般的なカスタマーゲートウェイデバイスをトラブルシューティングするためのフローチャート\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/images/troubleshooting-cgw-flow-nobgp-diagram.png)



|  |  | 
| --- |--- |
| IKE |  IKE Security Association が存在するかどうかを確認します。 IKE Security Association は、IPsec Security Association を確立するために使用されるキーの交換に必要です。 IKE Security Association がない場合は、IKE 設定を確認します。設定ファイルに示されている、暗号化、認証、Perfect Forward Secrecy、およびモードのパラメータを設定する必要があります。 IKE Security Association が存在する場合は、「IPsec」に進みます。  | 
| IPsec |  IPsec Security Association (SA) が存在するかどうかを確認します。 IPsec SA はトンネル自体です。カスタマーゲートウェイデバイスにクエリを実行し、IPsec SA がアクティブかどうかを確認します。設定ファイルに示されている、暗号化、認証、Perfect Forward Secrecy、およびモードのパラメータが設定されていることを確認します。 IPsec SA が存在しない場合は、IPsec 設定を確認します。 IPsec SA が存在する場合は、「トンネル」に進みます。  | 
| トンネル |  必須のファイアウォールルールがセットアップされていることを確認します (ルールのリストについては、「[AWS Site-to-Site VPN カスタマーゲートウェイデバイスのファイアウォールルール](FirewallRules.md)」を参照)。セットアップされている場合は、次に進みます。 トンネル経由の IP 接続があるかどうかを確認します。 トンネルのそれぞれの側に、設定ファイルで指定された IP アドレスが含まれます。仮想プライベートゲートウェイアドレスは、BGP ネイバーアドレスとして使用されます。カスタマーゲートウェイデバイスから、このアドレスに対する ping を実行し、IP トラフィックが正しく暗号化および復号化されているかどうかを確認します。 ping が失敗した場合は、トンネルインターフェイス設定を確認し、正しい IP アドレスが設定されていることを確認します。 ping が成功した場合は、「静的ルート」に進みます。  | 
|  静的ルート  |  各トンネルについて、以下を実行します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/Generic_Troubleshooting_noBGP.html) トンネルがこの状態にない場合は、デバイス設定を確認します。 トンネルがいずれもこの状態であることを確認したら、終了です。  | 

# Cisco ASA カスタマーゲートウェイデバイスと AWS Site-to-Site VPN の接続のトラブルシューティング
<a name="Cisco_ASA_Troubleshooting"></a>

Cisco のカスタマーゲートウェイデバイスの接続をトラブルシューティングする場合は、IKE、IPsec、ルーティングを考慮します。これらの領域を任意の順序でトラブルシューティングできますが、IKE から (ネットワークスタックの下から) 開始して上に進むことをお勧めします。

**重要**  
一部の Cisco ASA ではアクティブ/スタンバイモードのみがサポートされています。これらの Cisco ASA を使用する場合は、アクティブなトンネルを一度に 1 個のみ保持できます。最初のトンネルが利用不可になった場合にのみ、他方のスタンバイトンネルがアクティブになります。スタンバイトンネルは、ログファイルで次のエラーを生成する場合がありますが、このエラーは無視できます。`Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface outside`

## IKE
<a name="ASA_IKE"></a>

次のコマンドを使用します。このレスポンスは、IKE が正しく設定されたカスタマーゲートウェイデバイスを示しています。

```
ciscoasa# show crypto isakmp sa
```

```
   Active SA: 2
   Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 2

1   IKE Peer: AWS_ENDPOINT_1
    Type    : L2L             Role    : initiator
    Rekey   : no              State   : MM_ACTIVE
```

トンネル内で指定されたリモートゲートウェイの `src` 値を含む 1 つ以上の行が表示されます。`state` は `MM_ACTIVE`、`status` は `ACTIVE` となります。エントリがない場合、またはエントリが別の状態になっている場合は、IKE が正しく設定されていないことを示しています。

さらにトラブルシューティングする場合は、次のコマンドを実行して診断情報を提供するログメッセージを有効にします。

```
router# term mon
router# debug crypto isakmp
```

デバッグを無効にするには、次のコマンドを使用します。

```
router# no debug crypto isakmp
```

## IPsec
<a name="ASA_IPsec"></a>

次のコマンドを使用します。このレスポンスは、IPsec が正しく設定されたカスタマーゲートウェイデバイスを示しています。

```
ciscoasa# show crypto ipsec sa
```

```
interface: outside
    Crypto map tag: VPN_crypto_map_name, seq num: 2, local addr: 172.25.50.101

      access-list integ-ppe-loopback extended permit ip any vpc_subnet subnet_mask
      local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
      remote ident (addr/mask/prot/port): (vpc_subnet/subnet_mask/0/0)
      current_peer: integ-ppe1

      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 172.25.50.101, remote crypto endpt.: AWS_ENDPOINT_1

      path mtu 1500, ipsec overhead 74, media mtu 1500
      current outbound spi: 6D9F8D3B
      current inbound spi : 48B456A6

    inbound esp sas:
      spi: 0x48B456A6 (1219778214)
         transform: esp-aes esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, }
         slot: 0, conn_id: 4710400, crypto-map: VPN_cry_map_1
         sa timing: remaining key lifetime (kB/sec): (4374000/3593)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001
    outbound esp sas:
      spi: 0x6D9F8D3B (1839172923)
         transform: esp-aes esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, }
         slot: 0, conn_id: 4710400, crypto-map: VPN_cry_map_1
         sa timing: remaining key lifetime (kB/sec): (4374000/3593)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
         0x00000000 0x00000001
```

各トンネルインターフェイスに対して、`inbound esp sas` と `outbound esp sas` がいずれも表示されます。これは、SA が示され (例: `spi: 0x48B456A6`)、IPsec が正しく設定されていることを前提としています。

Cisco ASA では、IPsec は、対象となるトラフィック (暗号化する必要があるトラフィック) が送信された場合にのみ表示されます。IPsec を常にアクティブにするには、SLA モニターを設定することをお勧めします。SLA モニターは、対象となるトラフィックを引き続き送信し、IPsec を常にアクティブにします。

また、次の ping コマンドを使用して、ネゴシエーションを開始して上に移動することを IPsec に強制することもできます。

```
ping ec2_instance_ip_address
```

```
Pinging ec2_instance_ip_address with 32 bytes of data:

Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128
Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128
Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128

Ping statistics for 10.0.0.4:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),

Approximate round trip times in milliseconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
```

さらにトラブルシューティングする場合は、次のコマンドを使用してデバッグを有効にします。

```
router# debug crypto ipsec
```

デバッグを無効にするには、次のコマンドを使用します。

```
router# no debug crypto ipsec
```

## ルーティング
<a name="ASA_Tunnel"></a>

トンネルのもう一方の端で ping を実行します。機能している場合は、IPsec を確立する必要があります。機能していない場合は、アクセスリストを確認し、前の IPsec セクションを参照します。

インスタンスに到達できない場合は、次の情報を確認します。

1. アクセスリストが、暗号化マップに関連付けられたトラフィックを許可するように設定されていることを確認します。

   これを行うには、次のコマンドを実行します。

   ```
   ciscoasa# show run crypto
   ```

   ```
   crypto ipsec transform-set transform-amzn esp-aes esp-sha-hmac
   crypto map VPN_crypto_map_name 1 match address access-list-name
   crypto map VPN_crypto_map_name 1 set pfs
   crypto map VPN_crypto_map_name 1 set peer AWS_ENDPOINT_1 AWS_ENDPOINT_2
   crypto map VPN_crypto_map_name 1 set transform-set transform-amzn
   crypto map VPN_crypto_map_name 1 set security-association lifetime seconds 3600
   ```

1. 次のコマンドを使用して、アクセスリストを確認します。

   ```
   ciscoasa# show run access-list access-list-name
   ```

   ```
   access-list access-list-name extended permit ip any vpc_subnet subnet_mask
   ```

1. アクセスリストが正しいことを確認します。次のアクセスリスト例では、VPC サブネット 10.0.0.0/16 へのすべての内部トラフィックを許可しています。

   ```
   access-list access-list-name extended permit ip any 10.0.0.0 255.255.0.0
   ```

1. Cisco ASA デバイスから traceroute を実行し、Amazon ルーター (たとえば、*AWS\$1ENDPOINT\$11*/*AWS\$1ENDPOINT\$12*) に到達するかどうかを確認します。

   これが Amazon ルーターに到達したら、Amazon VPC コンソールで追加した静的ルートと、特定のインスタンスのセキュリティグループを確認します。

1. さらにトラブルシューティングする場合は、設定を確認します。

## トンネルインターフェイスをバウンスする
<a name="ASA_Tunnel-bounce"></a>

トンネルが稼働しているように見えるものの、トラフィックが適切に流れていない場合、トンネルインターフェイスをバウンスする (無効化および再有効化する) と、接続の問題を解決できることがよくあります。Cisco ASA のトンネルインターフェイスをバウンスするには:

1. 下記を実行します。

   ```
   ciscoasa# conf t
   ciscoasa(config)# interface tunnel X  (where X is your tunnel ID)
   ciscoasa(config-if)# shutdown
   ciscoasa(config-if)# no shutdown
   ciscoasa(config-if)# end
   ```

   または、単一行コマンドを使用できます。

   ```
   ciscoasa# conf t ; interface tunnel X ; shutdown ; no shutdown ; end
   ```

1. インターフェイスをバウンスした後、VPN 接続が再確立されたかどうか、およびトラフィックが正しく流れているかどうかを確認します。

# Cisco IOS カスタマーゲートウェイデバイスと AWS Site-to-Site VPN の接続のトラブルシューティング
<a name="Cisco_Troubleshooting"></a>

Cisco のカスタマーゲートウェイデバイスの接続をトラブルシューティングする場合は、IKE、IPsec、トンネル、BGP の 4 つの要素を考慮します。これらの領域を任意の順序でトラブルシューティングできますが、IKE から (ネットワークスタックの下から) 開始して上に進むことをお勧めします。

## IKE
<a name="IKE"></a>

次のコマンドを使用します。このレスポンスは、IKE が正しく設定されたカスタマーゲートウェイデバイスを示しています。

```
router# show crypto isakmp sa
```

```
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
192.168.37.160  72.21.209.193   QM_IDLE           2001    0 ACTIVE
192.168.37.160  72.21.209.225   QM_IDLE           2002    0 ACTIVE
```

トンネル内で指定されたリモートゲートウェイの `src` 値を含む 1 つ以上の行が表示されます。`state` は `QM_IDLE`、`status` は `ACTIVE` となります。エントリがない場合、またはエントリが別の状態になっている場合は、IKE が正しく設定されていないことを示しています。

さらにトラブルシューティングする場合は、次のコマンドを実行して診断情報を提供するログメッセージを有効にします。

```
router# term mon
router# debug crypto isakmp
```

デバッグを無効にするには、次のコマンドを使用します。

```
router# no debug crypto isakmp
```

## IPsec
<a name="IPsec"></a>

次のコマンドを使用します。このレスポンスは、IPsec が正しく設定されたカスタマーゲートウェイデバイスを示しています。

```
router# show crypto ipsec sa
```

```
interface: Tunnel1
    Crypto map tag: Tunnel1-head-0, local addr 192.168.37.160

    protected vrf: (none)
    local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
    remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
    current_peer 72.21.209.225 port 500
     PERMIT, flags={origin_is_acl,}
     #pkts encaps: 149, #pkts encrypt: 149, #pkts digest: 149
     #pkts decaps: 146, #pkts decrypt: 146, #pkts verify: 146
     #pkts compressed: 0, #pkts decompressed: 0
     #pkts not compressed: 0, #pkts compr. failed: 0
     #pkts not decompressed: 0, #pkts decompress failed: 0
     #send errors 0, #recv errors 0

     local crypto endpt.: 174.78.144.73, remote crypto endpt.: 72.21.209.225
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
     current outbound spi: 0xB8357C22(3090512930)

     inbound esp sas:
      spi: 0x6ADB173(112046451)
       transform: esp-aes esp-sha-hmac ,
       in use settings ={Tunnel, }
       conn id: 1, flow_id: Motorola SEC 2.0:1, crypto map: Tunnel1-head-0
       sa timing: remaining key lifetime (k/sec): (4467148/3189)
       IV size: 16 bytes
       replay detection support: Y  replay window size: 128
       Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xB8357C22(3090512930)
       transform: esp-aes esp-sha-hmac ,
       in use settings ={Tunnel, }
       conn id: 2, flow_id: Motorola SEC 2.0:2, crypto map: Tunnel1-head-0
       sa timing: remaining key lifetime (k/sec): (4467148/3189)
       IV size: 16 bytes
       replay detection support: Y  replay window size: 128
       Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:

interface: Tunnel2
     Crypto map tag: Tunnel2-head-0, local addr 174.78.144.73

     protected vrf: (none)
     local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
     remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
     current_peer 72.21.209.193 port 500
      PERMIT, flags={origin_is_acl,}
     #pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26
     #pkts decaps: 24, #pkts decrypt: 24, #pkts verify: 24
     #pkts compressed: 0, #pkts decompressed: 0
     #pkts not compressed: 0, #pkts compr. failed: 0
     #pkts not decompressed: 0, #pkts decompress failed: 0
     #send errors 0, #recv errors 0

     local crypto endpt.: 174.78.144.73, remote crypto endpt.: 72.21.209.193
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
     current outbound spi: 0xF59A3FF6(4120526838)

     inbound esp sas:
      spi: 0xB6720137(3060924727)
       transform: esp-aes esp-sha-hmac ,
       in use settings ={Tunnel, }
       conn id: 3, flow_id: Motorola SEC 2.0:3, crypto map: Tunnel2-head-0
       sa timing: remaining key lifetime (k/sec): (4387273/3492)
       IV size: 16 bytes
       replay detection support: Y  replay window size: 128
       Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xF59A3FF6(4120526838)
       transform: esp-aes esp-sha-hmac ,
       in use settings ={Tunnel, }
       conn id: 4, flow_id: Motorola SEC 2.0:4, crypto map: Tunnel2-head-0
       sa timing: remaining key lifetime (k/sec): (4387273/3492)
       IV size: 16 bytes
       replay detection support: Y  replay window size: 128
       Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:
```

各トンネルインターフェイスに対して、`inbound esp sas` と `outbound esp sas` がいずれも表示されます。SA が示され (例: `spi: 0xF95D2F3C`)、`Status` が `ACTIVE` となっていれば、IPsec は正しく設定されています。

さらにトラブルシューティングする場合は、次のコマンドを使用してデバッグを有効にします。

```
router# debug crypto ipsec
```

次のコマンドを使用して、デバッグを無効にします。

```
router# no debug crypto ipsec
```

## トンネル
<a name="Tunnel"></a>

最初に、必要なファイアウォールルールがあることを確認します。詳細については、「[AWS Site-to-Site VPN カスタマーゲートウェイデバイスのファイアウォールルール](FirewallRules.md)」を参照してください。

ファイアウォールルールが正しくセットアップされた場合は、次のコマンドでトラブルシューティングを継続します。

```
router# show interfaces tun1
```

```
Tunnel1 is up, line protocol is up 
  Hardware is Tunnel
  Internet address is 169.254.255.2/30
  MTU 17867 bytes, BW 100 Kbit/sec, DLY 50000 usec, 
    reliability 255/255, txload 2/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 174.78.144.73, destination 72.21.209.225
  Tunnel protocol/transport IPSEC/IP
  Tunnel TTL 255
  Tunnel transport MTU 1427 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Tunnel protection via IPSec (profile "ipsec-vpn-92df3bfb-0")
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 1 packets/sec
  5 minute output rate 1000 bits/sec, 1 packets/sec
    407 packets input, 30010 bytes, 0 no buffer
    Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
```

`line protocol` が実行されていることを確認します。トンネルのソース IP アドレス、ソースインターフェイス、および宛先がそれぞれ、IP アドレス外部のカスタマーゲートウェイデバイス、インターフェイス、および IP アドレス外部の仮想プライベートゲートウェイのトンネル設定に対応することを確認します。`Tunnel protection via IPSec` が存在することを確認します。両方のトンネルインターフェイスでコマンドを実行します。問題を解決するには、設定を確認し、カスタマーゲートウェイデバイスへの物理的な接続を確認します。

また、次のコマンドを使用して、`169.254.255.1` を仮想プライベートゲートウェイの内部 IP アドレスで置き換えます。

```
router# ping 169.254.255.1 df-bit size 1410
```

```
Type escape sequence to abort.
Sending 5, 1410-byte ICMP Echos to 169.254.255.1, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
```

5 個の感嘆符が表示されます。

さらにトラブルシューティングする場合は、設定を確認します。

## BGP
<a name="BGP"></a>

次のコマンドを使用します。

```
router# show ip bgp summary
```

```
BGP router identifier 192.168.37.160, local AS number 65000
BGP table version is 8, main routing table version 8
2 network entries using 312 bytes of memory
2 path entries using 136 bytes of memory
3/1 BGP path/bestpath attribute entries using 444 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 948 total bytes of memory
BGP activity 4/1 prefixes, 4/1 paths, scan interval 15 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
169.254.255.1   4  7224     363     323        8    0    0 00:54:21        1
169.254.255.5   4  7224     364     323        8    0    0 00:00:24        1
```

両方のネイバーが表示されます。それぞれに対して、`1` の `State/PfxRcd` 値が表示されます。

BGP ピアリングが起動している場合は、カスタマーゲートウェイデバイスが VPC へのデフォルトルート (0.0.0.0/0) をアドバタイズしていることを確認します。

```
router# show bgp all neighbors 169.254.255.1 advertised-routes
```

```
For address family: IPv4 Unicast
BGP table version is 3, local router ID is 174.78.144.73
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
     r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

Network             Next Hop            Metric   LocPrf Weight Path
*> 10.120.0.0/16    169.254.255.1          100        0   7224    i

Total number of prefixes 1
```

さらに、VPC に対応するプレフィックスを仮想プライベートゲートウェイから受け取っていることを確認します。

```
router# show ip route bgp
```

```
	10.0.0.0/16 is subnetted, 1 subnets
B       10.255.0.0 [20/0] via 169.254.255.1, 00:00:20
```

さらにトラブルシューティングする場合は、設定を確認します。

# ボーダーゲートウェイプロトコルを使用しない Cisco IOS カスタマーゲートウェイデバイス AWS Site-to-Site VPN への接続のトラブルシューティング
<a name="Cisco_Troubleshooting_NoBGP"></a>

Cisco のカスタマーゲートウェイデバイスの接続をトラブルシューティングする場合は、IKE、IPsec、トンネルの 3 つの要素を考慮します。これらの領域を任意の順序でトラブルシューティングできますが、IKE から (ネットワークスタックの下から) 開始して上に進むことをお勧めします。

## IKE
<a name="IOS_NoBGP_IKE"></a>

次のコマンドを使用します。このレスポンスは、IKE が正しく設定されたカスタマーゲートウェイデバイスを示しています。

```
router# show crypto isakmp sa
```

```
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
174.78.144.73 205.251.233.121 QM_IDLE           2001    0 ACTIVE
174.78.144.73 205.251.233.122 QM_IDLE           2002    0 ACTIVE
```

トンネル内で指定されたリモートゲートウェイの `src` 値を含む 1 つ以上の行が表示されます。`state` は `QM_IDLE`、`status` は `ACTIVE` となります。エントリがない場合、またはエントリが別の状態になっている場合は、IKE が正しく設定されていないことを示しています。

さらにトラブルシューティングする場合は、次のコマンドを実行して診断情報を提供するログメッセージを有効にします。

```
router# term mon
router# debug crypto isakmp
```

デバッグを無効にするには、次のコマンドを使用します。

```
router# no debug crypto isakmp
```

## IPsec
<a name="IOS_NoBGP_IPsec"></a>

次のコマンドを使用します。このレスポンスは、IPsec が正しく設定されたカスタマーゲートウェイデバイスを示しています。

```
router# show crypto ipsec sa
```

```
interface: Tunnel1
    Crypto map tag: Tunnel1-head-0, local addr 174.78.144.73

    protected vrf: (none)
    local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
    remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
    current_peer 72.21.209.225 port 500
     PERMIT, flags={origin_is_acl,}
     #pkts encaps: 149, #pkts encrypt: 149, #pkts digest: 149
     #pkts decaps: 146, #pkts decrypt: 146, #pkts verify: 146
     #pkts compressed: 0, #pkts decompressed: 0
     #pkts not compressed: 0, #pkts compr. failed: 0
     #pkts not decompressed: 0, #pkts decompress failed: 0
     #send errors 0, #recv errors 0

     local crypto endpt.: 174.78.144.73, remote crypto endpt.:205.251.233.121
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
     current outbound spi: 0xB8357C22(3090512930)

     inbound esp sas:
      spi: 0x6ADB173(112046451)
       transform: esp-aes esp-sha-hmac ,
       in use settings ={Tunnel, }
       conn id: 1, flow_id: Motorola SEC 2.0:1, crypto map: Tunnel1-head-0
       sa timing: remaining key lifetime (k/sec): (4467148/3189)
       IV size: 16 bytes
       replay detection support: Y  replay window size: 128
       Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xB8357C22(3090512930)
       transform: esp-aes esp-sha-hmac ,
       in use settings ={Tunnel, }
       conn id: 2, flow_id: Motorola SEC 2.0:2, crypto map: Tunnel1-head-0
       sa timing: remaining key lifetime (k/sec): (4467148/3189)
       IV size: 16 bytes
       replay detection support: Y  replay window size: 128
       Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:

interface: Tunnel2
     Crypto map tag: Tunnel2-head-0, local addr 205.251.233.122

     protected vrf: (none)
     local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
     remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
     current_peer 72.21.209.193 port 500
      PERMIT, flags={origin_is_acl,}
     #pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26
     #pkts decaps: 24, #pkts decrypt: 24, #pkts verify: 24
     #pkts compressed: 0, #pkts decompressed: 0
     #pkts not compressed: 0, #pkts compr. failed: 0
     #pkts not decompressed: 0, #pkts decompress failed: 0
     #send errors 0, #recv errors 0

     local crypto endpt.: 174.78.144.73, remote crypto endpt.:205.251.233.122
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
     current outbound spi: 0xF59A3FF6(4120526838)

     inbound esp sas:
      spi: 0xB6720137(3060924727)
       transform: esp-aes esp-sha-hmac ,
       in use settings ={Tunnel, }
       conn id: 3, flow_id: Motorola SEC 2.0:3, crypto map: Tunnel2-head-0
       sa timing: remaining key lifetime (k/sec): (4387273/3492)
       IV size: 16 bytes
       replay detection support: Y  replay window size: 128
       Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xF59A3FF6(4120526838)
       transform: esp-aes esp-sha-hmac ,
       in use settings ={Tunnel, }
       conn id: 4, flow_id: Motorola SEC 2.0:4, crypto map: Tunnel2-head-0
       sa timing: remaining key lifetime (k/sec): (4387273/3492)
       IV size: 16 bytes
       replay detection support: Y  replay window size: 128
       Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:
```

各トンネルインターフェイスに対して、インバウンドの `esp sas` とアウトバウンドの `esp sas` がいずれも表示されます。これは、SA が示され (例: `spi: 0x48B456A6`)、ステータスが `ACTIVE` で、IPsec が正しく設定されていることを前提としています。

さらにトラブルシューティングする場合は、次のコマンドを使用してデバッグを有効にします。

```
router# debug crypto ipsec
```

デバッグを無効にするには、次のコマンドを使用します。

```
router# no debug crypto ipsec
```

## トンネル
<a name="IOS_NoBGP_tunnel"></a>

最初に、必要なファイアウォールルールがあることを確認します。詳細については、「[AWS Site-to-Site VPN カスタマーゲートウェイデバイスのファイアウォールルール](FirewallRules.md)」を参照してください。

ファイアウォールルールが正しくセットアップされた場合は、次のコマンドでトラブルシューティングを継続します。

```
router# show interfaces tun1
```

```
Tunnel1 is up, line protocol is up 
  Hardware is Tunnel
  Internet address is 169.254.249.18/30
  MTU 17867 bytes, BW 100 Kbit/sec, DLY 50000 usec, 
    reliability 255/255, txload 2/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 174.78.144.73, destination 205.251.233.121
  Tunnel protocol/transport IPSEC/IP
  Tunnel TTL 255
  Tunnel transport MTU 1427 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Tunnel protection via IPSec (profile "ipsec-vpn-92df3bfb-0")
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 1 packets/sec
  5 minute output rate 1000 bits/sec, 1 packets/sec
    407 packets input, 30010 bytes, 0 no buffer
    Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
```

line protocol が実行されていることを確認します。トンネルのソース IP アドレス、ソースインターフェイス、および宛先がそれぞれ、IP アドレス外部のカスタマーゲートウェイデバイス、インターフェイス、および IP アドレス外部の仮想プライベートゲートウェイのトンネル設定に対応することを確認します。`Tunnel protection through IPSec` が存在することを確認します。両方のトンネルインターフェイスでコマンドを実行します。問題を解決するには、設定を確認し、カスタマーゲートウェイデバイスへの物理的な接続を確認します。

また、次のコマンドを使用して、`169.254.249.18` を仮想プライベートゲートウェイの内部 IP アドレスで置き換えます。

```
router# ping 169.254.249.18 df-bit size 1410
```

```
Type escape sequence to abort.
Sending 5, 1410-byte ICMP Echos to 169.254.249.18, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
```

5 個の感嘆符が表示されます。

### ルーティング
<a name="IOS_NoBGP_routing"></a>

静的ルートテーブルを表示するには、次のコマンドを使用します。

```
router# sh ip route static
```

```
     1.0.0.0/8 is variably subnetted
S       10.0.0.0/16 is directly connected, Tunnel1
is directly connected, Tunnel2
```

両方のトンネルを経由した VPC CIDR の静的ルートが存在していることを確認します。存在しない場合は、次に示すように静的ルートを追加します。

```
router# ip route 10.0.0.0 255.255.0.0 Tunnel1 track 100 
router# ip route 10.0.0.0 255.255.0.0 Tunnel2 track 200
```

### SLA モニターの確認
<a name="IOS_NoBGP_sla"></a>

```
router# show ip sla statistics 100
```

```
IPSLAs Latest Operation Statistics

IPSLA operation id: 100
        Latest RTT: 128 milliseconds
Latest operation start time: *18:08:02.155 UTC Wed Jul  15 2012
Latest operation return code: OK
Number of successes: 3
Number of failures: 0
Operation time to live: Forever
```

```
router# show ip sla statistics 200
```

```
IPSLAs Latest Operation Statistics

IPSLA operation id: 200
        Latest RTT: 128 milliseconds
Latest operation start time: *18:08:02.155 UTC Wed Jul  15 2012
Latest operation return code: OK
Number of successes: 3
Number of failures: 0
Operation time to live: Forever
```

`Number of successes` の値は、SLA モニターが正常にセットアップされたかどうかを示します。

さらにトラブルシューティングする場合は、設定を確認します。

# Juniper JunOS カスタマーゲートウェイデバイスと AWS Site-to-Site VPN の接続のトラブルシューティング
<a name="Juniper_Troubleshooting"></a>

Juniper のカスタマーゲートウェイデバイスの接続をトラブルシューティングする場合は、IKE、IPsec、トンネル、BGP の 4 つの要素を考慮します。これらの領域を任意の順序でトラブルシューティングできますが、IKE から (ネットワークスタックの下から) 開始して上に進むことをお勧めします。

## IKE
<a name="IKETroubleshooting"></a>

次のコマンドを使用します。このレスポンスは、IKE が正しく設定されたカスタマーゲートウェイデバイスを示しています。

```
user@router> show security ike security-associations
```

```
Index   Remote Address  State  Initiator cookie  Responder cookie  Mode
4       72.21.209.225   UP     c4cd953602568b74  0d6d194993328b02  Main
3       72.21.209.193   UP     b8c8fb7dc68d9173  ca7cb0abaedeb4bb  Main
```

トンネル内で指定されたリモートゲートウェイのリモートアドレスを含む 1 つ以上の行が表示されます。`State` は `UP` になっている必要があります。エントリがない場合、またはエントリが別の状態になっている場合 (`DOWN` など) は、IKE が正しく設定されていないことを示しています。

さらにトラブルシューティングする場合は、設定ファイルの例で推奨されているように、IKE トレースオプションを有効にします。次に、以下のコマンドを実行すると、さまざまなデバッグメッセージが画面に表示されます。

```
user@router> monitor start kmd
```

外部ホストから、次のコマンドでログファイル全体を取得できます。

```
scp username@router.hostname:/var/log/kmd
```

## IPsec
<a name="IPsecTroubleshooting"></a>

次のコマンドを使用します。このレスポンスは、IPsec が正しく設定されたカスタマーゲートウェイデバイスを示しています。

```
user@router> show security ipsec security-associations
```

```
Total active tunnels: 2
ID      Gateway        Port  Algorithm        SPI      Life:sec/kb Mon vsys
<131073 72.21.209.225  500   ESP:aes-128/sha1 df27aae4 326/ unlim   -   0
>131073 72.21.209.225  500   ESP:aes-128/sha1 5de29aa1 326/ unlim   -   0
<131074 72.21.209.193  500   ESP:aes-128/sha1 dd16c453 300/ unlim   -   0
>131074 72.21.209.193  500   ESP:aes-128/sha1 c1e0eb29 300/ unlim   -   0
```

具体的には、(リモートゲートウェイに対応する) ゲートウェイアドレスごとに 2 行以上が表示されます。各行の先頭にあるキャレット (< >) は、特定のエントリのトラフィックの方向を示しています。出力には、インバウンドトラフィック (仮想プライベートゲートウェイからこのカスタマーゲートウェイデバイスへのトラフィック、「<」で表されます) およびアウトバウンドトラフィック (「>」で表されます) が別々の行として含まれます。

さらにトラブルシューティングする場合は、IKE のトレースオプションを有効にします (詳細については、IKE に関する前のセクションを参照してください)。

## トンネル
<a name="TunnelTroubleshooting"></a>

最初に、必要なファイアウォールルールがあることをもう一度確認します。ルールのリストについては、「[AWS Site-to-Site VPN カスタマーゲートウェイデバイスのファイアウォールルール](FirewallRules.md)」を参照してください。

ファイアウォールルールが正しくセットアップされた場合は、次のコマンドでトラブルシューティングを継続します。

```
user@router> show interfaces st0.1
```

```
 Logical interface st0.1 (Index 70) (SNMP ifIndex 126)
    Flags: Point-To-Point SNMP-Traps Encapsulation: Secure-Tunnel
    Input packets : 8719
    Output packets: 41841
    Security: Zone: Trust
    Allowed host-inbound traffic : bgp ping ssh traceroute
    Protocol inet, MTU: 9192
      Flags: None
      Addresses, Flags: Is-Preferred Is-Primary
      Destination: 169.254.255.0/30, Local: 169.254.255.2
```

`Security: Zone` が正しいことを確認し、`Local` のアドレスがカスタマーゲートウェイデバイスのトンネル内部のアドレスと一致することを確認します。

次に、以下のコマンドを使用して、`169.254.255.1` を仮想プライベートゲートウェイの内部 IP アドレスで置き換えます。次に示すようなレスポンスが結果として返されます。

```
user@router> ping 169.254.255.1 size 1382 do-not-fragment
```

```
PING 169.254.255.1 (169.254.255.1): 1410 data bytes
64 bytes from 169.254.255.1: icmp_seq=0 ttl=64 time=71.080 ms
64 bytes from 169.254.255.1: icmp_seq=1 ttl=64 time=70.585 ms
```

さらにトラブルシューティングする場合は、設定を確認します。

## BGP
<a name="BGPTroubleshooting"></a>

以下のコマンドを実行してください。

```
user@router> show bgp summary
```

```
Groups: 1 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0                 2          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
169.254.255.1          7224          9         10       0       0        1:00 1/1/1/0              0/0/0/0
169.254.255.5          7224          8          9       0       0          56 0/1/1/0              0/0/0/0
```

さらにトラブルシューティングする場合は、次のコマンドを使用して、`169.254.255.1` を仮想プライベートゲートウェイの内部 IP アドレスで置き換えます。

```
user@router> show bgp neighbor 169.254.255.1
```

```
Peer: 169.254.255.1+179 AS 7224 Local: 169.254.255.2+57175 AS 65000
  Type: External    State: Established    Flags: <ImportEval Sync>
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Export: [ EXPORT-DEFAULT ] 
  Options: <Preference HoldTime PeerAS LocalAS Refresh>
  Holdtime: 30 Preference: 170 Local AS: 65000 Local System AS: 0
  Number of flaps: 0
  Peer ID: 169.254.255.1    Local ID: 10.50.0.10       Active Holdtime: 30
  Keepalive Interval: 10         Peer index: 0   
  BFD: disabled, down
  Local Interface: st0.1                            
  NLRI for restart configured on peer: inet-unicast
  NLRI advertised by peer: inet-unicast
  NLRI for this session: inet-unicast
  Peer supports Refresh capability (2)
  Restart time configured on the peer: 120
  Stale routes from peer are kept for: 300
  Restart time requested by this peer: 120
  NLRI that peer supports restart for: inet-unicast
  NLRI that restart is negotiated for: inet-unicast
  NLRI of received end-of-rib markers: inet-unicast
  NLRI of all end-of-rib markers sent: inet-unicast
  Peer supports 4 byte AS extension (peer-as 7224)
  Table inet.0 Bit: 10000
    RIB State: BGP restart is complete
    Send state: in sync
    Active prefixes:              1
    Received prefixes:            1
    Accepted prefixes:            1
    Suppressed due to damping:    0
    Advertised prefixes:          1
Last traffic (seconds): Received 4    Sent 8    Checked 4   
Input messages:  Total 24     Updates 2       Refreshes 0     Octets 505
Output messages: Total 26     Updates 1       Refreshes 0     Octets 582
Output Queue[0]: 0
```

ここでは、`Received prefixes` および `Advertised prefixes` がそれぞれ 1 になっています。これは、`Table inet.0` セクション内にあります。

`State` が `Established` でない場合は、`Last State` および `Last Error` を確認し、問題の修正に必要なことを詳しく確認します。

BGP ピアリングが起動している場合は、カスタマーゲートウェイデバイスが VPC へのデフォルトルート (0.0.0.0/0) をアドバタイズしていることを確認します。

```
user@router> show route advertising-protocol bgp 169.254.255.1
```

```
inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 0.0.0.0/0               Self                                    I
```

さらに、VPC に対応するプレフィックスを仮想プライベートゲートウェイから受け取っていることを確認します。

```
user@router> show route receive-protocol bgp 169.254.255.1
```

```
inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.110.0.0/16           169.254.255.1        100                7224 I
```

# Juniper ScreenOS カスタマーゲートウェイデバイスと AWS Site-to-Site VPN の接続のトラブルシューティング
<a name="Juniper_ScreenOs_Troubleshooting"></a>

Juniper ScreenOS ベースのカスタマーゲートウェイデバイスの接続をトラブルシューティングする場合は、IKE、IPsec、トンネル、BGP の 4 つの要素を考慮します。これらの領域を任意の順序でトラブルシューティングできますが、IKE から (ネットワークスタックの下から) 開始して上に進むことをお勧めします。

## IKE と IPsec
<a name="IKEIPsec"></a>

次のコマンドを使用します。このレスポンスは、IKE が正しく設定されたカスタマーゲートウェイデバイスを示しています。

```
ssg5-serial-> get sa
```

```
total configured sa: 2
HEX ID    Gateway         Port Algorithm     SPI      Life:sec kb Sta   PID vsys
00000002<   72.21.209.225  500 esp:a128/sha1 80041ca4  3385 unlim A/-    -1 0
00000002>   72.21.209.225  500 esp:a128/sha1 8cdd274a  3385 unlim A/-    -1 0
00000001<   72.21.209.193  500 esp:a128/sha1 ecf0bec7  3580 unlim A/-    -1 0
00000001>   72.21.209.193  500 esp:a128/sha1 14bf7894  3580 unlim A/-    -1 0
```

トンネル内で指定されたリモートゲートウェイのリモートアドレスを含む 1 つ以上の行が表示されます。`Sta` 値は `A/-`、`SPI` は `00000000` 以外の 16 進数になっている必要があります。その他の状態のエントリは、IKE が正しく設定されていないことを示しています。

さらにトラブルシューティングする場合は、設定ファイルの例で推奨されているように、IKE トレースオプションを有効にします。

## トンネル
<a name="TunnelFirewall"></a>

最初に、必要なファイアウォールルールがあることをもう一度確認します。ルールのリストについては、「[AWS Site-to-Site VPN カスタマーゲートウェイデバイスのファイアウォールルール](FirewallRules.md)」を参照してください。

ファイアウォールルールが正しくセットアップされた場合は、次のコマンドでトラブルシューティングを継続します。

```
ssg5-serial-> get interface tunnel.1
```

```
  Interface tunnel.1:
  description tunnel.1
  number 20, if_info 1768, if_index 1, mode route
  link ready
  vsys Root, zone Trust, vr trust-vr
  admin mtu 1500, operating mtu 1500, default mtu 1500
  *ip 169.254.255.2/30
  *manage ip 169.254.255.2
  route-deny disable
  bound vpn:
    IPSEC-1

  Next-Hop Tunnel Binding table
  Flag Status Next-Hop(IP)    tunnel-id  VPN

  pmtu-v4 disabled
  ping disabled, telnet disabled, SSH disabled, SNMP disabled
  web disabled, ident-reset disabled, SSL disabled

  OSPF disabled  BGP enabled  RIP disabled  RIPng disabled  mtrace disabled
  PIM: not configured  IGMP not configured
  NHRP disabled
  bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps]
             configured ingress mbw 0kbps, current bw 0kbps
             total allocated gbw 0kbps
```

`link:ready` が表示され、`IP` アドレスがカスタマーゲートウェイデバイスのトンネルの内部のアドレスと一致することを確認します。

次に、以下のコマンドを使用して、`169.254.255.1` を仮想プライベートゲートウェイの内部 IP アドレスで置き換えます。次に示すようなレスポンスが結果として返されます。

```
ssg5-serial-> ping 169.254.255.1
```

```
Type escape sequence to abort

Sending 5, 100-byte ICMP Echos to 169.254.255.1, timeout is 1 seconds
!!!!!
Success Rate is 100 percent (5/5), round-trip time min/avg/max=32/32/33 ms
```

さらにトラブルシューティングする場合は、設定を確認します。

## BGP
<a name="BGPCommand"></a>

以下のコマンドを実行してください。

```
ssg5-serial-> get vrouter trust-vr protocol bgp neighbor
```

```
Peer AS Remote IP       Local IP          Wt Status   State     ConnID Up/Down
--------------------------------------------------------------------------------
   7224 169.254.255.1   169.254.255.2    100 Enabled  ESTABLISH     10 00:01:01
   7224 169.254.255.5   169.254.255.6    100 Enabled  ESTABLISH     11 00:00:59
```

両方の BGP ピアの状態が `ESTABLISH` である必要があります。これは、仮想プライベートゲートウェイへの BGP 接続がアクティブであることを示します。

さらにトラブルシューティングする場合は、次のコマンドを使用して、`169.254.255.1` を仮想プライベートゲートウェイの内部 IP アドレスで置き換えます。

```
ssg5-serial-> get vr trust-vr prot bgp neigh 169.254.255.1
```

```
peer: 169.254.255.1,  remote AS: 7224, admin status: enable
type: EBGP, multihop: 0(disable), MED: node default(0)
connection state: ESTABLISH, connection id: 18 retry interval: node default(120s), cur retry time 15s
configured hold time: node default(90s), configured keepalive: node default(30s)
configured adv-interval: default(30s)
designated local IP: n/a
local IP address/port: 169.254.255.2/13946, remote IP address/port: 169.254.255.1/179
router ID of peer: 169.254.255.1, remote AS: 7224
negotiated hold time: 30s, negotiated keepalive interval: 10s
route map in name: , route map out name:
weight: 100 (default)
self as next hop: disable
send default route to peer: disable
ignore default route from peer: disable
send community path attribute: no
reflector client: no
Neighbor Capabilities:
  Route refresh: advertised and received
  Address family IPv4 Unicast:  advertised and received
force reconnect is disable
total messages to peer: 106, from peer: 106
update messages to peer: 6, from peer: 4
Tx queue length 0, Tx queue HWM: 1
route-refresh messages to peer: 0, from peer: 0
last reset 00:05:33 ago, due to BGP send Notification(Hold Timer Expired)(code 4 : subcode 0)
number of total successful connections: 4
connected: 2 minutes 6 seconds
Elapsed time since last update: 2 minutes 6 seconds
```

BGP ピアリングが起動している場合は、カスタマーゲートウェイデバイスが VPC へのデフォルトルート (0.0.0.0/0) をアドバタイズしていることを確認します。このコマンドは、ScreenOS バージョン 6.2.0 以降に適用されます。

```
ssg5-serial-> get vr trust-vr protocol bgp  rib neighbor 169.254.255.1 advertised
```

```
i: IBGP route, e: EBGP route, >: best route, *: valid route
               Prefix         Nexthop    Wt  Pref   Med Orig    AS-Path
--------------------------------------------------------------------------------------
>i          0.0.0.0/0         0.0.0.0 32768   100     0  IGP
Total IPv4 routes advertised: 1
```

さらに、VPC に対応するプレフィックスを仮想プライベートゲートウェイから受け取っていることを確認します。このコマンドは、ScreenOS バージョン 6.2.0 以降に適用されます。

```
ssg5-serial-> get vr trust-vr protocol bgp  rib neighbor 169.254.255.1 received
```

```
i: IBGP route, e: EBGP route, >: best route, *: valid route
               Prefix         Nexthop    Wt  Pref   Med Orig    AS-Path
--------------------------------------------------------------------------------------
>e*     10.0.0.0/16   169.254.255.1   100   100   100  IGP   7224
Total IPv4 routes received: 1
```

# Yamaha カスタマーゲートウェイデバイスと AWS Site-to-Site VPN の接続のトラブルシューティング
<a name="Yamaha_Troubleshooting"></a>

Yamaha のカスタマーゲートウェイデバイスの接続をトラブルシューティングする場合は、IKE、IPsec、トンネル、BGP の 4 つの要素を考慮します。これらの領域を任意の順序でトラブルシューティングできますが、IKE から (ネットワークスタックの下から) 開始して上に進むことをお勧めします。

**注記**  
IKE のフェーズ 2 で使用される `proxy ID` 設定は、Yamaha ルーターではデフォルトで無効になっています。これにより、Site-to-Site VPN への接続で問題が発生する可能性があります。`proxy ID` がルーターで設定されていない場合は、Yamaha が正しく設定できるように、 AWSが提供する設定ファイルの例を参照してください。

## IKE
<a name="YamahaIKE"></a>

以下のコマンドを実行してください。このレスポンスは、IKE が正しく設定されたカスタマーゲートウェイデバイスを示しています。

```
# show ipsec sa gateway 1
```

```
sgw  flags local-id                      remote-id        # of sa
--------------------------------------------------------------------------
1    U K   YOUR_LOCAL_NETWORK_ADDRESS     72.21.209.225    i:2 s:1 r:1
```

トンネル内で指定されたリモートゲートウェイの `remote-id` 値を含む行が表示されます。トンネル番号を省略すると、すべての Security Association (SA) を表示できます。

さらにトラブルシューティングする場合は、次のコマンドを実行して、診断情報を提供する DEBUG レベルログメッセージを有効にします。

```
# syslog debug on
# ipsec ike log message-info payload-info key-info
```

ログに記録された項目をキャンセルするには、次のコマンドを実行します。

```
# no ipsec ike log
# no syslog debug on
```

## IPsec
<a name="YamahaIPsec"></a>

以下のコマンドを実行してください。このレスポンスは、IPsec が正しく設定されたカスタマーゲートウェイデバイスを示しています。

```
# show ipsec sa gateway 1 detail
```

```
SA[1] Duration: 10675s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Protocol: IKE
Algorithm: AES-CBC, SHA-1, MODP 1024bit

SPI: 6b ce fd 8a d5 30 9b 02 0c f3 87 52 4a 87 6e 77 
Key: ** ** ** ** **  (confidential)   ** ** ** ** **
----------------------------------------------------
SA[2] Duration: 1719s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Direction: send
Protocol: ESP (Mode: tunnel)
Algorithm: AES-CBC (for Auth.: HMAC-SHA)
SPI: a6 67 47 47 
Key: ** ** ** ** **  (confidential)   ** ** ** ** **
----------------------------------------------------
SA[3] Duration: 1719s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Direction: receive
Protocol: ESP (Mode: tunnel)
Algorithm: AES-CBC (for Auth.: HMAC-SHA)
SPI: 6b 98 69 2b 
Key: ** ** ** ** **  (confidential)   ** ** ** ** **
----------------------------------------------------
SA[4] Duration: 10681s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Protocol: IKE
Algorithm: AES-CBC, SHA-1, MODP 1024bit
SPI: e8 45 55 38 90 45 3f 67 a8 74 ca 71 ba bb 75 ee 
Key: ** ** ** ** **  (confidential)   ** ** ** ** **
----------------------------------------------------
```

各トンネルインターフェイスに対して、`receive sas` と `send sas` がいずれも表示されます。

さらにトラブルシューティングする場合は、次のコマンドを使用してデバッグを有効にします。

```
# syslog debug on
# ipsec ike log message-info payload-info key-info
```

次のコマンドを実行して、デバッグを無効にします。

```
# no ipsec ike log
# no syslog debug on
```

## トンネル
<a name="YamahaTunnel"></a>

最初に、必要なファイアウォールルールがあることを確認します。ルールのリストについては、「[AWS Site-to-Site VPN カスタマーゲートウェイデバイスのファイアウォールルール](FirewallRules.md)」を参照してください。

ファイアウォールルールが正しくセットアップされた場合は、次のコマンドでトラブルシューティングを継続します。

```
# show status tunnel 1
```

```
TUNNEL[1]: 
Description: 
  Interface type: IPsec
  Current status is Online.
  from 2011/08/15 18:19:45.
  5 hours 7 minutes 58 seconds  connection.
  Received:    (IPv4) 3933 packets [244941 octets]
               (IPv6) 0 packet [0 octet]
  Transmitted: (IPv4) 3933 packets [241407 octets]
               (IPv6) 0 packet [0 octet]
```

`current status` 値がオンラインで `Interface type` が IPsec になっていることを確認します。両方のトンネルインターフェイスでコマンドを実行することを確認します。ここですべての問題を解決するには、設定を確認します。

## BGP
<a name="YamahaBGP"></a>

以下のコマンドを実行してください。

```
# show status bgp neighbor
```

```
BGP neighbor is 169.254.255.1, remote AS 7224, local AS 65000, external link
  BGP version 0, remote router ID 0.0.0.0
  BGP state = Active
  Last read 00:00:00, hold time is 0, keepalive interval is 0 seconds
  Received 0 messages, 0 notifications, 0 in queue
  Sent 0 messages, 0 notifications, 0 in queue
  Connection established 0; dropped 0
  Last reset never
Local host: unspecified
Foreign host: 169.254.255.1, Foreign port: 0

BGP neighbor is 169.254.255.5, remote AS 7224, local AS 65000, external link
  BGP version 0, remote router ID 0.0.0.0
  BGP state = Active
  Last read 00:00:00, hold time is 0, keepalive interval is 0 seconds
  Received 0 messages, 0 notifications, 0 in queue
  Sent 0 messages, 0 notifications, 0 in queue
  Connection established 0; dropped 0
  Last reset never
Local host: unspecified
Foreign host: 169.254.255.5, Foreign port:
```

両方のネイバーが表示されます。それぞれに対して、`Active` の `BGP state` 値が表示されます。

BGP ピアリングが起動している場合は、カスタマーゲートウェイデバイスが VPC へのデフォルトルート (0.0.0.0/0) をアドバタイズしていることを確認します。

```
# show status bgp neighbor 169.254.255.1 advertised-routes 
```

```
Total routes: 1
*: valid route
  Network            Next Hop        Metric LocPrf Path
* default            0.0.0.0              0        IGP
```

さらに、VPC に対応するプレフィックスを仮想プライベートゲートウェイから受け取っていることを確認します。

```
# show ip route
```

```
Destination         Gateway          Interface       Kind  Additional Info.
default             ***.***.***.***   LAN3(DHCP)    static  
10.0.0.0/16         169.254.255.1    TUNNEL[1]       BGP  path=10124
```

# AWS Site-to-Site VPN とゼロ統合
<a name="eero-integration"></a>

AWS Site-to-Site VPN は [eero](http://eero.com) と連携し、組織は数回クリックするだけでリモートサイトと AWS 間の安全な接続を簡単に簡単に簡単に確立できます。

このソリューションは、eero の WiFi アクセスポイントとネットワークゲートウェイを活用してローカル接続を提供します。eero のゲートウェイアプライアンスと Site-to-Site VPN を使用すると、顧客は VPN 接続を自動的に確立して、POS システムの支払いゲートウェイなど、AWS でホストされているアプリケーションに数回クリックするだけでアクセスできます。これにより、お客様は何百ものサイトにリモートサイト接続を簡単かつ迅速にスケーリングでき、ネットワークに関する専門知識を持つオンサイト技術者が接続をセットアップする必要がなくなります。このソリューションは、最大 500 のリモートオフィスを持つ分散型企業に適しています。各オフィスには最大 100 人のユーザーがいます。

 詳細なセットアップガイドなど、この統合の詳細については、[eero ドキュメント](https://support.eero.com/hc/en-us/articles/42827838351899-AWS-Account-and-VPN-Configuration)を参照してください。

**注記**  
この統合の一環として、AWS Site-to-Site VPN の機能に変更はありません。

**考慮事項**:
+ Transit Gateway または Cloud WAN にアタッチされた VPN 接続でのみ使用できます。Virtual Private Gateway アタッチメントではサポートされていません。
+ 5 Gbps トンネルはサポートされていません。
+ Site-to-Site VPN コンセントレータはサポートされていません。
+ Site-to-Site VPN [クォータ](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-limits.html)は、この統合では変更されません。