ぼくのかんがえたさいきょうのAWSとのインターネットVPN接続

世間はWindows OSの再起動事件で混乱していますね。
もはやWindows OSは社会(の重要)インフラに組み込まれており、更にそこに組み込まれるセキュリティ関連製品も社会のインフラの一部である、ということを改めて認識させられる事件でしたね。

先月我が家のメインルーターRTX1300が故障してしまい、起動しなくなりました。
現在予備機のRTX1210で運用しているのですが、これでAWSとインターネットVPNをTerraformで張りました。
以前の記事でしれっとAzureとインターネットVPN張っているので、これのAWS版ですね。
ざっと調べるとYAMAHA RTXシリーズとAWSのVPNはIKEv1の記事が多かったので、IKEv2でVPNを張る記事を書きたいと思います。

構成図

では早速構成図です。

はい。
こんな感じですね。
とってもシンプルです。

なんでIKEv1とIKEv2にこだわるの？

はい。
これもちゃんと理由があります。
IKEv2の方が新しい規格(といっても結構古く、RFC7296が書かれたのは2014年10月と、ほぼ10年前です)で、IKEv2よりも簡単で高速、セキュアになっています。
IKEv1だとメーカーや機種、ファームウェア単位で接続時に利用する必須パラメータが統一されていなかった(複雑であり、機器間で処理が異なる＝接続ごとにオーバーヘッド処理が発生し時間を要するため高速でない)り、PSKで接続する際に総当たり攻撃に対する脆弱性があったり(セキュアでない)と、冒頭の通り昨今の事情を鑑みると単に新しい規格だから安全だ、皆が採用しているから安全だということではなく、ちゃんと理由があってIKEv2を選択している、ということです。
読者の皆様の環境でもインターネットVPNをお使いの場合はIKEv1かv2を確認してもらい、v1の場合はそれ相応の理由があるかどうか確認してください。
また提案する立場の読者の皆様も今まで自分が提案してきた内容、パラメーターにそれ相応の理由があるかどうか今一度確認しましょう。

Terrafrom

はい。
では早速いってみましょう。

変数設定

variables.tf

# ---------------------------
# Variables - 変数設定
# ---------------------------

# region
# ap-northeast-1 東京リージョン
# ap-south-1 ムンバイリージョン
variable "region" {
  default = "ap-south-1"
}

# 環境種別(本番:prd,ステージング:stg,開発:dev)
variable "env_type" {
  default = "dev"
}

# システム名
variable "sys_name" {
  default = "vpn-test01"
}

# availability_zone
variable "availability_zone" {
  type = object({
    a = string
    b = string #ムンバイリージョンで利用
    c = string
  })
  default = {
    a = "ap-south-1a" # ムンバイ(インド)のアベイラビリティゾーン
    b = "ap-south-1b" # ムンバイ(インド)のアベイラビリティゾーン
    c = "ap-south-1c" # ムンバイ(インド)のアベイラビリティゾーン
  }
}

# ------------------------------
# VPC 関連
# ------------------------------

# vpc address
variable "vpc_address_pre" {
  default = "10.0."
}

variable "vpc_address_suf" {
  default = "0.0/23"
}

# private subnet suffix address01
variable "private_sn_address_suf01" {
  default = "1.0/24"
}

# public subnet suffix address01
variable "public_sn_address_suf01" {
  default = "0.0/24"
}

# VPC Endpoint
variable "vpc_endpoints" {
  type    = list(any)
  default = ["ssm", "ssmmessages", "ec2messages"]
}

# ------------------------------
# VPN (On-Premises Network) 関連
# ------------------------------

# RTX1300 Global IP Address
variable "rtx1300_gip_address" {
  default = "60.138.244.248"
}

# RTX1300 Local IP Address01
variable "rtx1300_local_address01" {
  type = string
  default = "192.168.11.0/24"
}

# RTX1300 Local IP Address02
variable "rtx1300_local_address02" {
  type = string
  default = "172.16.0.0/24"
}

# ------------------------------
# EC2 作成
# ------------------------------

# Linux EC2のインスタンスタイプ
variable "ec2_instance_type_lin" {
    default = "t2.micro"
}

# Windows EC2のインスタンスタイプ
variable "ec2_instance_type_win" {
    default = "m4.large"
}

今回はVPNを張るのでオンプレミス関連のパラメータが存在しますね。
リージョンは安定のムンバイです！

main

main.tf

# ---------------------------
# main
# ---------------------------

terraform {
  required_version = ">= 1.4" # Terraformのバージョンを1.4以上に指定
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "= 5.22.0" # AWSプロバイダのバージョンを5.22.0に固定
    }
  }
}

# プロバイダー設定
provider "aws" {
  region = var.region
}

いつも通りですね。

iam

iam.tf

# ---------------------------
# IAM
# ---------------------------

# IAM ROLE 定義
resource "aws_iam_role" "ec2_role" {
  name               = "${var.env_type}-${var.sys_name}-iam-role"
  assume_role_policy = data.aws_iam_policy_document.ec2_assume_role.json
}

# IAMポリシー定義
data "aws_iam_policy_document" "ec2_assume_role" {
  statement {
    actions = ["sts:AssumeRole"]

    principals {
      type        = "Service"
      identifiers = ["ec2.amazonaws.com"]
    }
  }
}

# IAM ROLEのインスタンスプロフィールの作成
resource "aws_iam_instance_profile" "instance_prof" {
  name = "${var.env_type}-${var.sys_name}-instance-profile-ssm"
  role = aws_iam_role.ec2_role.name
}

# ---------------------------
# FOR SSM
# ---------------------------
# SSM用ポリシーをEC2ロールに設定
resource "aws_iam_role_policy_attachment" "ssm_control" {
  role       = aws_iam_role.ec2_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

はい。
ここも安定のいつも通りですね。
SSMいらんかなとも思ったんですが、念のため付けておきます。

VPC

vpc.tf

# ---------------------------
# VPC 構築
# ---------------------------

resource "aws_vpc" "vpc" {
  cidr_block           = "${var.vpc_address_pre}${var.vpc_address_suf}"
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = {
    Name = "${var.env_type}-${var.sys_name}-vpc"
  }
}

# ---------------------------
# Public Subnet 構築
# ---------------------------

resource "aws_subnet" "sn_public_1a" {
  vpc_id            = aws_vpc.vpc.id
  cidr_block        = "${var.vpc_address_pre}${var.public_sn_address_suf01}"
  availability_zone = var.availability_zone.a
  tags = {
    Name = "${var.env_type}-${var.sys_name}-sn-public-1a"
  }
}

# ---------------------------
# Private Subnet 構築
# ---------------------------

resource "aws_subnet" "sn_private_1b" {
  vpc_id            = aws_vpc.vpc.id
  cidr_block        = "${var.vpc_address_pre}${var.private_sn_address_suf01}"
  availability_zone = var.availability_zone.b
  tags = {
    Name = "${var.env_type}-${var.sys_name}-sn-private-1b"
  }
}

# ---------------------------
# Internet Gateway 作成
# ---------------------------
resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.vpc.id
  tags = {
    Name = "${var.env_type}-${var.sys_name}-igw"
  }
}

# ---------------------------
# Route table 作成
# ---------------------------

# Public Subnet 用Route Table 作成
resource "aws_route_table" "rt_sn_public_1a" {
  vpc_id = aws_vpc.vpc.id
  # Default GatewayをInternet Gatewayに向ける
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
  tags = {
    Name = "${var.env_type}-${var.sys_name}-rt-sn-public-1a"
  }
}

# Private Subnet 用Route Table 作成
resource "aws_route_table" "rt_sn_private_1b" {
  vpc_id = aws_vpc.vpc.id
  # Default GatewayをInternet Gatewayに向ける
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
  route {
    cidr_block = "${var.rtx1300_local_address01}"
    gateway_id = aws_vpn_gateway.vgw.id
  }
  route {
    cidr_block = "${var.rtx1300_local_address02}"
    gateway_id = aws_vpn_gateway.vgw.id
  }
  tags = {
    Name = "${var.env_type}-${var.sys_name}-rt-sn-private-1b"
  }
}

# Public Subnet とDefault Route table の関連付け
resource "aws_route_table_association" "associate_rt_sn_public_1a_sn_public_1a" {
  subnet_id      = aws_subnet.sn_public_1a.id
  route_table_id = aws_route_table.rt_sn_public_1a.id
}

# Private Subnet とDefault Route table の関連付け
resource "aws_route_table_association" "associate_rt_sn_private_1b_sn_private_1b" {
  subnet_id      = aws_subnet.sn_private_1b.id
  route_table_id = aws_route_table.rt_sn_private_1b.id
}

今回はPublic SubnetをAvailability Zone Aとし、Private SubnetをAvailability Zone Bとしました。
Availability Zone Cも使ってよかったのですが、CだとSpot InstanceでEC2を構築できませんでした。
恐らく新しいZoneのためDCの総床面積が少なく、EC2を構築するために必要な各種リソースに余力ないのでしょう。
またVPNなんで念のため構成図にRoute Tableを記載しています。
これは当然TerraformでもPublic SubnetとPrivate SubnetとでRoute Tableに違いがありますので念のため分けて記載しました。

Security Group

security_group.tf

# ---------------------------
# Security Group
# ---------------------------

# ---------------------------
# EC2用 Security Group作成
# ---------------------------

#Linux EC2 用SG
resource "aws_security_group" "sg_ec2_linux01" {
  name   = "${var.env_type}-${var.sys_name}-sg-ec2-linux01"
  vpc_id = aws_vpc.vpc.id
  tags   = {
    Name = "${var.env_type}-${var.sys_name}-sg-ec2-linux01"
  }

  # インバウンドルール
  # from SSM
  ingress {
    description     = "AllowHttpsInBoundFromVPC for SSM"
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    cidr_blocks = ["${var.vpc_address_pre}${var.vpc_address_suf}"]
  }

  ingress {
    description     = "AllowICMPv4InBoundFromVPC"
    from_port       = -1
    to_port         = -1
    protocol        = "icmp"
    cidr_blocks = ["${var.vpc_address_pre}${var.vpc_address_suf}"]
  }

  ingress {
    description     = "AllowInBoundFromOn-Premises-General-Subnet"
    from_port       = 0
    to_port         = 0
    protocol        = "-1"
    cidr_blocks = ["${var.rtx1300_local_address01}"]
  }

  ingress {
    description     = "AllowInBoundFromOn-Premises-Server-Subnet"
    from_port       = 0
    to_port         = 0
    protocol        = "-1"
    cidr_blocks = ["${var.rtx1300_local_address02}"]
  }

  # アウトバウンドルール
  egress {
    description = "AllowAnyOutBound"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# Windows Server 用SG
resource "aws_security_group" "sg_ec2_windows01" {
  name   = "${var.env_type}-${var.sys_name}-sg-windows01"
  vpc_id = aws_vpc.vpc.id
  tags   = {
    Name = "${var.env_type}-${var.sys_name}-sg-windows01"
  }

  # インバウンドルール
  # from VPC ICMPv4
  ingress {
    description     = "AllowICMPv4InBoundFromVPC"
    from_port       = -1
    to_port         = -1
    protocol        = "icmp"
    cidr_blocks = ["${var.vpc_address_pre}${var.vpc_address_suf}"]
  }

  # For RDPアクセス
  ingress {
    description     = "AllowInBoundFromOn-Premises-General-Subnet"
    from_port       = 0
    to_port         = 0
    protocol        = "-1"
    cidr_blocks = ["${var.rtx1300_local_address01}"]
  }

  ingress {
    description     = "AllowInBoundFromOn-Premises-Server-Subnet"
    from_port       = 0
    to_port         = 0
    protocol        = "-1"
    cidr_blocks = ["${var.rtx1300_local_address02}"]
  }

  # アウトバウンドルール
  egress {
    description = "AllowAnyOutBound"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# ---------------------------
# SSM用 Vpc endpoint Security Group作成
# ---------------------------

resource "aws_security_group" "sg_ssm" {
  name   = "${var.env_type}-${var.sys_name}-sg-ssm"
  vpc_id = aws_vpc.vpc.id
  tags   = {
    Name = "${var.env_type}-${var.sys_name}-sg-ssm"
  }

  # インバウンドルール
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["${var.vpc_address_pre}${var.vpc_address_suf}"]
  }

  # アウトバウンドルール
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_security_group" "sg_ssmmessages" {
  name   = "${var.env_type}-${var.sys_name}-sg-ssmmessages"
  vpc_id = aws_vpc.vpc.id
  tags   = {
    Name = "${var.env_type}-${var.sys_name}-sg-ssmmessages"
  }

  # インバウンドルール
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["${var.vpc_address_pre}${var.vpc_address_suf}"]
  }

  # アウトバウンドルール
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_security_group" "sg_ec2messages" {
  name   = "${var.env_type}-${var.sys_name}-sg-ec2messages"
  vpc_id = aws_vpc.vpc.id
  tags   = {
    Name = "${var.env_type}-${var.sys_name}-sg-ec2messages"
  }

  # インバウンドルール
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["${var.vpc_address_pre}${var.vpc_address_suf}"]
  }

  # アウトバウンドルール
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

はい。
大したこと書いてないですね。
Azureとの違いを挙げるなら、NSGではVPN to VPNの通信をタグで許可すると、VPN接続先、今回だとオンプレミスのローカルネットワークアドレス帯が暗黙的にNSGのタグに含まれるため、追加でポリシーを記載する必要がありません。
AWSではそこは暗黙的に含まれない(ある意味当たり前)なので、明示的に開けています。
オンプレミスでFirewall機器やUTM機器を使ってVPNを張ったことがある方々であれば違和感なくご理解いただけるかなと思います。

VPNゲートウェイ関連

vpn.tf

# ---------------------------
# VPN Gateway 作成
# ---------------------------
resource "aws_vpn_gateway" "vgw" {
  vpc_id = aws_vpc.vpc.id
  tags = {
    Name = "${var.env_type}-${var.sys_name}-vgw"
  }
}

# ---------------------------
# Customer Gateway 作成 (On-Premises 側ルーター)
# ---------------------------
resource "aws_customer_gateway" "cgw" {
  bgp_asn    = 65000 # default 
  ip_address = "${var.rtx1300_gip_address}"
  type       = "ipsec.1"
  tags = {
    Name = "${var.env_type}-${var.sys_name}-cgw"
  }
}

はい。
ここも何の変哲もないVPN GatewayとCustomer Gatewayですね。

VPN接続

vpn_connection.tf

# ------------------------------
# VPN 接続作成
# ------------------------------

resource "aws_vpn_connection" "vpn_connection" {
  vpn_gateway_id           = aws_vpn_gateway.vgw.id
  customer_gateway_id      = aws_customer_gateway.cgw.id
  type                     = "ipsec.1"
  static_routes_only       = true
  tags = {
    Name = "${var.env_type}-${var.sys_name}-vpn-connection"
  }
}

resource "aws_vpn_connection_route" "on-premises-general-subnet" {
  destination_cidr_block = "${var.rtx1300_local_address01}"
  vpn_connection_id      = aws_vpn_connection.vpn_connection.id
}

resource "aws_vpn_connection_route" "on-premises-server-subnet" {
  destination_cidr_block = "${var.rtx1300_local_address02}"
  vpn_connection_id      = aws_vpn_connection.vpn_connection.id
}

はい。
ここも何の変哲もありませんが、我が家はネットワークが一般サブネットとサーバサブネットに分かれているので、変数やVPCのルートテーブルでも宣言している通りサブネット2つ接続しています。

EC2

ec2.tf

# -------------------------------
# EC2作成
# -------------------------------

# -------------------------------
# Amazon Linux EC2を作成
# -------------------------------

# Amazon Linux 2023 の最新版AMIを取得
data "aws_ssm_parameter" "al2023-ami-kernel-default-x86_64" {
  name = "/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64"
}

 resource "aws_spot_instance_request" "ec2_linux01" { #spot_priceを設定する。ムンバイリージョンではAvailability Zone CではSpot Instanceは使えない。
   spot_price                  = "0.0046"
   ami                         = data.aws_ssm_parameter.al2023-ami-kernel-default-x86_64.value
   instance_type               = var.ec2_instance_type_lin
   availability_zone           = var.availability_zone.b
   vpc_security_group_ids      = [aws_security_group.sg_ec2_linux01.id]
   subnet_id                   = aws_subnet.sn_private_1b.id
   associate_public_ip_address = "false"
   iam_instance_profile        = aws_iam_instance_profile.instance_prof.name
   user_data                   = <<-EOF
                                 #!/bin/bash
                                 sudo hostnamectl set-hostname ${var.env_type}-${var.sys_name}-ec2-linux01
                                 EOF

   root_block_device {
     volume_size = 30   # GB
     volume_type = "gp3" # 汎用SSD
     encrypted   = false
     tags        = {
       Snapshot = "false"      
     }
   }
   tags = {
     Name = "${var.env_type}-${var.sys_name}-ec2-amazon-linux01"
   }
      depends_on = [
    aws_route_table_association.associate_rt_sn_private_1b_sn_private_1b
   ]
 }

# -------------------------------
# Windows Server EC2を作成
# -------------------------------

# -------------------------------
# Windows Server 用のKey pair作成
# -------------------------------
variable "key_name" {
  default = "kp-ec2-01"
}
variable "key_path" {
  # - Windowsの場合はフォルダを"\\"で区切る（エスケープする必要がある）実行中のtfファイルと同じ場所にキーファイルを出力する
  default = ".\\"
}
resource "tls_private_key" "kp-windows-ec2-01" {
  algorithm = "RSA"
  rsa_bits  = 2048
}

# クライアントPCにKey pair（秘密鍵と公開鍵）を作成
# - Windowsの場合はフォルダを"\\"で区切る（エスケープする必要がある）
# - [terraform apply] 実行後はクライアントPCの公開鍵は自動削除される
locals {
  public_key_file  = "${var.key_path}\\${var.key_name}.id_rsa.pub"
  private_key_file = "${var.key_path}\\${var.key_name}.id_rsa"
}

resource "local_file" "kp_windows_ec2_01_pem" {
  filename = "${local.private_key_file}"
  content  = "${tls_private_key.kp-windows-ec2-01.private_key_pem}"
}

# 上記で作成した公開鍵をAWSのKey pairにインポート
resource "aws_key_pair" "kp_windows_ec2_01" {
  key_name   = "${var.key_name}"
  public_key = "${tls_private_key.kp-windows-ec2-01.public_key_openssh}"
}

#20240523時点のAMI
#Microsoft Windows Server 2022 Base:ami-0f346136f3b372267
#Microsoft Windows Server 2019 Base:ami-01bd28d73d0053a15
#Microsoft Windows Server 2016 Base:ami-063d3d00f8a97a6d1

 resource "aws_spot_instance_request" "ec2_windows01" { #spot_priceを設定する。ムンバイリージョンではAvailability Zone CではSpot Instanceは使えない。
   spot_price                  = "0.1318"
   ami                         = "ami-0f346136f3b372267" #Microsoft Windows Server 2022 Base
   instance_type               = var.ec2_instance_type_win
   availability_zone           = var.availability_zone.b
   vpc_security_group_ids      = [aws_security_group.sg_ec2_windows01.id]
   subnet_id                   = aws_subnet.sn_private_1b.id
   associate_public_ip_address = "false"
   key_name                    = "${var.key_name}"
   iam_instance_profile        = aws_iam_instance_profile.instance_prof.name
   root_block_device {
     volume_size = 50   # GB
     volume_type = "gp3" # 汎用SSD
     encrypted   = false
     tags        = {
       Snapshot = "false"      
     }
   }
   tags = {
     Name = "${var.env_type}-${var.sys_name}-ec2-windows01"
   }
   depends_on = [
    aws_route_table_association.associate_rt_sn_private_1b_sn_private_1b
   ]
 }

Windows EC2用の鍵ファイルの出力先をほんのちょっとだけ汎用的にしました。
そしてLinuxもWindowsもどっちもSpot Instanceで構築しています!
お金、大事ですもんね！(例のごとく自腹環境です)

output

output.tf

# ---------------------------
# Output
# ---------------------------

# 作成したWindows EC2 のパブリックIPアドレスを出力
output "aws_spot_instance_request_global_ips" {
   value = aws_spot_instance_request.ec2_windows01.*.public_ip
 }

WindowsのEC2のPublic IP Address(Elastic IP Address)を出力しようとしてるんですが、EC2のコードでPublic IPの項目をFalseにしてるんで出てきません。
このファイルも無いとコケるんでなんでも良いんですが、今回は適当にこれにしました。
NAT Gateway建ててるならそのPublic IP Addressとか出力すると良いですね。
今回はそこまでしてないのでこれでいっちゃいます。

Terraform実行結果

今回の検証で知ったんですけど、vs code内でコマンド実行できるんですね。
めっちゃ便利。
下の赤枠内です。

terraform plan実行して問題ないよ、って言われてるんで実行しちゃいましょう。
terraform applyからの

yesで！

こうやって何もない環境に

ゴリゴリとコードが走った後に

こうやって思った通りのマシンができると嬉しいですね！

はい。
完了しました。

AWSとのVPN(IKEv2)接続

はい。
では本記事の本懐いってみましょう。

設定のダウンロード

下画像の赤枠内の通りAWS ConsoleからVPC内の仮想プライベートネットワーク(VPN)配下にあるSite-to-Site VPN接続をクリックします。

画面が遷移したらTerraformで構築したリソースを選択し、設定をダウンロードするをクリックします。

やいのやいの指示を求める画面が出てくるので、指定しましょう。
今回は表題の通りYAMAHA RTXシリーズでIKEv2なので、以下の画像のようになりますね。

これでダウンロードをクリックします。
この機能、便利ですよね。
この機能はAzureにはありません！
さすがAWSさん！
素晴らしい！

AWS Consoleから出力されたConfigファイル

はい。
もうそのままはっちゃいましょう。

# Amazon Web Services
# Virtual Private Cloud

# AWS utilizes unique identifiers to manage the configuration of
# a VPN Connection. Each VPN Connection is assigned an identifier and is
# associated with two other identifiers, namely the
# Customer Gateway Identifier and Virtual Private Gateway Identifier.
#
# Your VPN Connection ID  		    : vpn-0eb6dd94c339ce48e
# Your Virtual Private Gateway ID           : vgw-015d6158a0d42bcda
# Your Customer Gateway ID 		    : cgw-0f51c42909c2b87d5
#
#
# This configuration consists of two tunnels. Both tunnels must be
# configured on your Customer Gateway.
#

# Before configuring the tunnels run the following command to enable the IPSec feature:
  ipsec use on

# --------------------------------------------------------------------------------
# IPSec Tunnel #1
# --------------------------------------------------------------------------------


# #1: Internet Key Exchange (IKE) Configuration
#
# A policy is established for the supported ISAKMP encryption,
# authentication, Diffie-Hellman, lifetime, and key parameters.
#
# Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2.
# Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
# You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH groups like 2, 14-18, 22, 23, and 24.
# NOTE: If you customized tunnel options when creating or modifying your VPN connection, you may need to modify these sample configurations to match the custom settings for your tunnels.
#
# Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".
# The address of the external interface for your customer gateway must be a static address.
# Your customer gateway may reside behind a device performing network address translation (NAT).
# To ensure that NAT traversal (NAT-T) can function, you must adjust your firewall !rules to unblock UDP port 4500.
# If not behind NAT, and you are not using an Accelerated VPN, we recommend disabling NAT-T. If you are using an Accelerated VPN, make sure that NAT-T is enabled.

tunnel select 1

# Note that there are a global list of IPSec policies, each identified by
# sequence number. This policy is defined as #201, which may conflict with
# an existing policy using the same number. If so, we recommend changing
# the sequence number to avoid conflicts.

 ipsec tunnel 201
  ipsec ike version 1 2
  ipsec ike duration isakmp-sa 1 28800
  ipsec ike encryption 1 aes-cbc
  ipsec ike group 1 modp1024
  ipsec ike hash 1 sha
  ipsec ike pre-shared-key 1 text _8033bndSGP6oQFGWoNDCqdWQpsAB_O6

# #2: IPSec Configuration

# The IPSec policy defines the encryption, authentication, and IPSec
# mode parameters.
# Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
# Please note, you may use these additionally supported IPSec parameters for encryption like AES256 and other DH groups like 2, 5, 14-18, 22, 23, and 24.
# NOTE: If you customized tunnel options when creating or modifying your VPN connection, you may need to modify these sample configurations to match the custom settings for your tunnels.
#
# Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".
#

  ipsec sa policy 201 1 esp aes-cbc sha-hmac
  ipsec ike duration ipsec-sa 1 3600
  ipsec ike pfs 1 on
  ipsec ike message-id-control 1 on
  ipsec ike child-exchange type 1 2
  ipsec ike keepalive use 1 on rfc4306 10 3

# --------------------------------------------------------------------------------
# #3: Tunnel Interface Configuration
#
# A tunnel interface is configured to be the logical interface associated
# with the tunnel. All traffic routed to the tunnel interface will be
# encrypted and transmitted to the VPC. Similarly, traffic from the VPC
# will be logically received on this interface.
#
# The address of the interface is configured with the setup for your
# Customer Gateway.  If the address changes, the Customer Gateway and VPN
# Connection must be recreated with Amazon VPC.
#
  ipsec ike local address 1 60.138.244.248
  ipsec ike local name 1 60.138.244.248 ipv4-addr
  ipsec ike remote address 1 3.6.75.13
  ipsec ike remote name 1 3.6.75.13 ipv4-addr
  ipsec ike negotiation receive 1 off
 ipsec tunnel outer df-bit clear
	ip tunnel address 169.254.80.210/255.255.255.252
	ip tunnel remote address 169.254.80.209
 ip tunnel tcp mss limit auto
 tunnel enable 1
tunnel select none
ipsec auto refresh on

# --------------------------------------------------------------------------------

# ----------------------------------------------------------------------------
# #4 Static Route Configuration
#
# Your Customer Gateway needs to set a static route for the prefix
# corresponding to your VPC to send traffic over the tunnel interface.
# An example for a VPC with the prefix 10.0.0.0/16, where tunnel 1 is the
# preferred tunnel, is provided below:
# ip route 10.0.0.0/16 gateway tunnel 1 keepalive 1 gateway tunnel 2 weight 0
#
# Keepalive is used to provide a failover between the two tunnels.
# If the primary tunnel fails, the redundant tunnel will automatically be used.
# This keepalive is defined as keepalive 1, which may conflict with an existing
# keepalive using same number. If so, we recommend changing the keepalive
#  number to avoid conflicts.
#
# ip keepalive 1 icmp-echo 1 5 169.254.80.209
# exit


# --------------------------------------------------------------------------------
# IPSec Tunnel #2
# --------------------------------------------------------------------------------


# #1: Internet Key Exchange (IKE) Configuration
#
# A policy is established for the supported ISAKMP encryption,
# authentication, Diffie-Hellman, lifetime, and key parameters.
#
# Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2.
# Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
# You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH groups like 2, 14-18, 22, 23, and 24.
# NOTE: If you customized tunnel options when creating or modifying your VPN connection, you may need to modify these sample configurations to match the custom settings for your tunnels.
#
# Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".
# The address of the external interface for your customer gateway must be a static address.
# Your customer gateway may reside behind a device performing network address translation (NAT).
# To ensure that NAT traversal (NAT-T) can function, you must adjust your firewall !rules to unblock UDP port 4500.
# If not behind NAT, and you are not using an Accelerated VPN, we recommend disabling NAT-T. If you are using an Accelerated VPN, make sure that NAT-T is enabled.

tunnel select 2

# Note that there are a global list of IPSec policies, each identified by
# sequence number. This policy is defined as #202, which may conflict with
# an existing policy using the same number. If so, we recommend changing
# the sequence number to avoid conflicts.

 ipsec tunnel 202
  ipsec ike version 2 2
  ipsec ike duration isakmp-sa 2 28800
  ipsec ike encryption 2 aes-cbc
  ipsec ike group 2 modp1024
  ipsec ike hash 2 sha
  ipsec ike pre-shared-key 2 text 5LBvQXUQYanIovxYXzk4YJce55blnrqb

# #2: IPSec Configuration

# The IPSec policy defines the encryption, authentication, and IPSec
# mode parameters.
# Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14.
# Please note, you may use these additionally supported IPSec parameters for encryption like AES256 and other DH groups like 2, 5, 14-18, 22, 23, and 24.
# NOTE: If you customized tunnel options when creating or modifying your VPN connection, you may need to modify these sample configurations to match the custom settings for your tunnels.
#
# Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic".
#

  ipsec sa policy 202 2 esp aes-cbc sha-hmac
  ipsec ike duration ipsec-sa 2 3600
  ipsec ike pfs 2 on
  ipsec ike message-id-control 2 on
  ipsec ike child-exchange type 2 2
  ipsec ike keepalive use 2 on rfc4306 10 3

# --------------------------------------------------------------------------------
# #3: Tunnel Interface Configuration
#
# A tunnel interface is configured to be the logical interface associated
# with the tunnel. All traffic routed to the tunnel interface will be
# encrypted and transmitted to the VPC. Similarly, traffic from the VPC
# will be logically received on this interface.
#
# The address of the interface is configured with the setup for your
# Customer Gateway.  If the address changes, the Customer Gateway and VPN
# Connection must be recreated with Amazon VPC.
#
  ipsec ike local address 2 60.138.244.248
  ipsec ike local name 2 60.138.244.248 ipv4-addr
  ipsec ike remote address 2 52.66.157.101
  ipsec ike remote name 2 52.66.157.101 ipv4-addr
  ipsec ike negotiation receive 2 off
 ipsec tunnel outer df-bit clear
	ip tunnel address 169.254.57.206/255.255.255.252
	ip tunnel remote address 169.254.57.205
 ip tunnel tcp mss limit auto
 tunnel enable 2
tunnel select none
ipsec auto refresh on

# --------------------------------------------------------------------------------

# ----------------------------------------------------------------------------
# #4 Static Route Configuration
#
# Your Customer Gateway needs to set a static route for the prefix
# corresponding to your VPC to send traffic over the tunnel interface.
# An example for a VPC with the prefix 10.0.0.0/16, where tunnel 1 is the
# preferred tunnel, is provided below:
# ip route 10.0.0.0/16 gateway tunnel 1 keepalive 1 gateway tunnel 2 weight 0
#
# Keepalive is used to provide a failover between the two tunnels.
# If the primary tunnel fails, the redundant tunnel will automatically be used.
# This keepalive is defined as keepalive 1, which may conflict with an existing
# keepalive using same number. If so, we recommend changing the keepalive
#  number to avoid conflicts.
#
# ip keepalive 1 icmp-echo 1 5 169.254.80.209
# exit




# Additional Notes and Questions

#  - Amazon Virtual Private Cloud Getting Started Guide:
#       http://docs.amazonwebservices.com/AmazonVPC/latest/GettingStartedGuide
#  - Amazon Virtual Private Cloud Network Administrator Guide:
#       http://docs.amazonwebservices.com/AmazonVPC/latest/NetworkAdminGuide
#  - Yamaha router's manual:
#	 http://www.rtpro.yamaha.co.jp/RT/docs/amazon-vpc/index.html
#  - Yamaha router's NAT settings in IPsec:
#        http://www.rtpro.yamaha.co.jp/RT/docs/ipsec/nat.html

もうそのまんまYAMAHA RTXシリーズのConfigファイルですね。
ただこれ、一部間違っているのでこのままではAWS VPN GatewayとVPN Connectionで作成した各種リソース群(Customer Gatewayも)とVPN張れません。
修正箇所はYAMAHAさんの公式サイトで言及されている部分、今回上に張っているConfigだと
ipsec ike local address 1 60.138.244.248
と
ipsec ike local address 2 60.138.244.248
になります。
それぞれオンプレミス側VPN機器、今回だとRTX1210のグローバルIPアドレスですね。
AWSはデフォルトでYAMAHA RTXシリーズと2本VPN張る仕様なんで、2本トンネル設定が存在しますね。
この辺もAzureと違って堅牢だなと思います
Azureはデフォルトだと1本です。
やっぱりAWSさん凄い！

欲を言うなら、以前の記事でも書いてる通りAzureはオンプレミスルーターの宛先をFQDNでも指定できるようになっているので、AWSさんもFQDNを指定可能にしてもらいたいですね。

修正Config

ipsec ike local address 1 60.138.244.248
と
ipsec ike local address 2 60.138.244.248
を
ipsec ike local address 1 192.168.11.1
と
ipsec ike local address 2 192.168.11.1
に変更します。
それぞれオンプレミスルーターのグローバルIPアドレスが指定されていた個所を、ローカルIPアドレスに変更します。
もうちょっと言及すると、AWS側にCustomer Gatewayで定義しているセグメントに含まれるローカルIPアドレス、ですね。

はい。ここまでは一般的な修正箇所です。

ぼくのかんがえたさいきょうのVPN設定

はい。
ここまでは一般的ですね。
ここでタイトル回収します。

AWSさんの出力するRTXシリースのConfigがファームウェア10という古いものなので仕方がないのかもしれませんが、ハッシュ形式が2本のVPNともsha1です。
ご存じの通りsha1は2017年にハッシュ衝突という脆弱性が見つかっているので、これを使い続けるわけにはいきません。
なのでここも修正します。
ついでにAESも128Bitなので256Bitに、DHもグループ2からグループ5に変更します。
「ぼくのかんがえたさいきょうのVPN」とか言いながらなんてことないですね。
現場レベルだと既に実装済みの設定かなという感じです。
ちょっと修正箇所が多いのでトンネル1本目と2本目それぞれわけて記載します。
まずはトンネル1本目

tunnel1.config

~省略~
  ipsec ike encryption 1 aes-cbc
  ipsec ike group 1 modp1024
  ipsec ike hash 1 sha
~省略~
  ipsec sa policy 201 1 esp aes-cbc sha-hmac

を

~省略~
  ipsec ike encryption 1 aes256-cbc
  ipsec ike group 1 modp1536
  ipsec ike hash 1 sha256
~省略~
  ipsec sa policy 201 1 esp aes256-cbc sha256-hmac

にします。
次にトンネル2本目です。

tunne2.config

~省略~
  ipsec ike encryption 2 aes-cbc
  ipsec ike group 2 modp1024
  ipsec ike hash 2 sha
~省略~
  ipsec sa policy 202 2 esp aes-cbc sha-hmac

を

~省略~
  ipsec ike encryption 2 aes256-cbc
  ipsec ike group 2 modp1536
  ipsec ike hash 2 sha256
~省略~
  ipsec sa policy 202 2 esp aes256-cbc sha256-hmac

にします。
はい。
こんなもんですかね。

VPN機器の脆弱性が狙われる昨今なので、VPN機器のファームウェア更新が行われた際にVPNに必要なパラメーターでより強力なハッシュ形式、暗号化形式がサポートされていないか確認し、都度Configに修正をかけていきましょう。

最後にルーティング追加

AWSさんのConfigではなぜかルーティングの設定がコメント内に記載されているだけにとどめられています。
たぶんルーティングはスタティックかBGPかどっちにするかは要件次第なので、どちらでもいけるようにスタティックルートはこうなるよ、とコメント内の記載にとどめているのでしょうね。
今回のTerraformだと以下のスタティックルートになります。
ip route 10.0.0.0/23 gateway tunnel 1 keepalive 1 gateway tunnel 2 weight 0
はい。

では接続確認いってみましょう。

接続確認

はい。
ではお待ちかねの接続確認です。
まずはLinuxから。

10.0.1.84がAWS上のLinuxのIPアドレスなので、Ping打ってみましょう。

完璧ですね！
SSHも

完璧ですね！
続いてWindowsですが、Windows Defender FirewallのデフォルトネットワークプロファイルがPublicであることを考慮し、TNCを使います。
まずはAWS上のWindowsのIPアドレスですが

10.0.1.145なので、ここにTNCでポートを3389(RDP)指定してみます。

はい！
接続確認できましたね！
完璧ですね！
RDPも

完璧ですね！

はい。
これでAWSとTerraformを用いてオンプレミスのRTX1210と無事VPNが張れました。

本日はここまで。