ConoHa VPSとAWS Transit GatewayをSite-to-Site VPNでつなぐ方法｜strongSwan設定例

ConoHaのVPSとAWSの複数のVPCをプライベートアドレスで通信させたい場合、ConoHa上のVPSを1台IPsecのVPNルーターにして、AWS Site-to-Site VPNでTransit Gateway（TGW）に接続する構成が組みやすい方法です。この記事では、その構成の考え方と、AWS側・ConoHa側の設定、つまずきやすい点を説明します。目標は、検証環境でConoHaのVPSからVPC内のEC2インスタンスへpingが通るところまでです。

構成の全体像

ConoHa VPSには、同じアカウントのVPS同士をつなぐローカルネットワークの機能があります。一方、ConoHaとAWSを専用線のように直接つなぐサービスは、この記事を書いた2026年10月時点ではConoHaの公式情報に見当たりません。そのため、インターネット越しのIPsec VPNでつなぎます。

• ConoHa側：VPNルーター役のVPSを1台用意し、グローバルIPとローカルネットワークの両方に接続する。他のVPSは、ローカルネットワーク経由でこのVPSを通ってAWSへ向かう。
• AWS側：TGWにSite-to-Site VPNのアタッチメントを作り、ConoHaのVPSをカスタマーゲートウェイとして登録する。各VPCはVPCアタッチメントでTGWにつなぐ。

VPCが1つだけなら、TGWを使わず仮想プライベートゲートウェイ（VGW）にVPNをつなぐほうが簡単です。TGWを選ぶのは、複数のVPCやアカウントをまとめてConoHaとつなぎたい場合です。TGWとSite-to-Site VPNには、アタッチメントの時間やデータ処理量に応じた料金がかかるので、AWSの料金ページで確認してください。

AWSのVPNはルートベース

AWS Site-to-Site VPNは、AWSの公式ドキュメントで「ルートベース」のVPNと説明されています。どの通信をトンネルに流すかは、TGWやVPCのルートテーブルで決まります。顧客側の機器をポリシーベース（通す範囲をトラフィックセレクターで指定する方式）で設定する場合は、トンネルあたりのセキュリティアソシエーション（SA）を1組に収める必要があります。

AWS側のトラフィックセレクターは、既定では両側とも 0.0.0.0/0 です。この記事のようにstrongSwan側で範囲を絞る（ポリシーベースの）設定をする場合は、VPN接続の作成時に、AWS側にも同じ範囲を指定して両側をそろえます。

アドレス設計を最初に決める

後戻りが難しいのがアドレス設計です。ConoHaのローカルネットワークと、TGWにつながるすべてのVPCのCIDRが重ならないようにします。この記事では次の値を使います（グローバルIPは説明用のアドレスです）。

• ConoHaのローカルネットワーク：172.16.0.0/24（VPNルーターのVPSは 172.16.0.10）
• AWS側のVPC：10.0.0.0/16 と 10.1.0.0/16（まとめて 10.0.0.0/8 の範囲に置く）
• VPNルーターのVPSのグローバルIP：203.0.113.10

AWS側を 10.0.0.0/8 のような1つの範囲にまとめておくと、トラフィックセレクターを1組で済ませられ、SAを1組に収めるという条件を満たせます。

AWS側の設定

カスタマーゲートウェイとVPN接続を作る

マネジメントコンソールでも作れますが、ここではAWS CLIで流れを示します。IDは自分の環境の値に置き換えてください。

# ConoHa の VPN ルーターをカスタマーゲートウェイとして登録
# （静的ルーティングでも --bgp-asn か --bgp-asn-extended の指定が必要。65000 は既定値）
aws ec2 create-customer-gateway \
  --type ipsec.1 \
  --ip-address 203.0.113.10 \
  --bgp-asn 65000

# TGW に VPN 接続を作成（静的ルーティング、トラフィックセレクターを両側で指定）
aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --customer-gateway-id cgw-0123456789abcdef0 \
  --transit-gateway-id tgw-0123456789abcdef0 \
  --options StaticRoutesOnly=true,LocalIpv4NetworkCidr=172.16.0.0/24,RemoteIpv4NetworkCidr=10.0.0.0/8

古い例では --public-ip を使っていますが、2026年10月時点のAWS CLIのリファレンスではこのオプションは非推奨で、--ip-address を使うよう案内されています。

VPN接続を作ると、AWS側にトンネルが2本用意され、それぞれの接続先IPと事前共有鍵が発行されます。コンソールのVPN接続の画面から機器ごとの設定ファイルをダウンロードできるので、暗号方式やIKEのバージョンなどのパラメーターはそのファイルに合わせてください。AWSはIKEv2の利用を推奨しています。

TGWのルートテーブル

静的ルーティングのVPNでは、TGWのルートテーブルにConoHa側のCIDRを、VPNアタッチメント宛てとして登録します。VPNアタッチメントのIDは、VPN接続のIDから調べられます。

# VPN 接続に対応する TGW アタッチメントの ID を調べる
aws ec2 describe-transit-gateway-attachments \
  --filters Name=resource-id,Values=vpn-0123456789abcdef0 \
  --query 'TransitGatewayAttachments[0].TransitGatewayAttachmentId'

# ConoHa 側の CIDR を VPN アタッチメント宛てに登録
aws ec2 create-transit-gateway-route \
  --transit-gateway-route-table-id tgw-rtb-0123456789abcdef0 \
  --destination-cidr-block 172.16.0.0/24 \
  --transit-gateway-attachment-id tgw-attach-0123456789abcdef0

# 登録内容の確認
aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id tgw-rtb-0123456789abcdef0 \
  --filters Name=type,Values=static,propagated

TGWのルートテーブルは、アタッチメントごとに「どのルートテーブルを使うか（関連付け）」が決まっています。VPCアタッチメントが関連付けられたルートテーブルに 172.16.0.0/24 へのルートがあり、VPNアタッチメントが関連付けられたルートテーブルに各VPCのCIDRへのルート（VPCアタッチメントからの伝播か静的ルート）があることを確認してください。既定の設定のまま1つのルートテーブルを全アタッチメントで共有している場合は、そのテーブルに両方がそろっていれば足ります。

VPCのルートテーブルとセキュリティグループ

見落としやすいのがVPC側です。各VPCのサブネットのルートテーブルに「172.16.0.0/24 宛てはTGW」というルートを追加しないと、ConoHaからの通信は届いても、戻りの通信がTGWへ向かいません。また、EC2インスタンスのセキュリティグループで、172.16.0.0/24 からの通信を必要な範囲（検証中ならICMP、本番では使うポートだけ）で許可します。

ConoHa側の設定

VPNルーターのVPSを準備する

VPNルーターのVPSはUbuntuを例にします。ConoHaのセキュリティグループで、AWSのトンネル2本の接続先IPからのUDP 500とUDP 4500を受け付けるルールを追加します。SSHなど管理用のポートは、接続元を自分の作業環境に絞ってください。

IPsecの通信本体（ESP、IPプロトコル番号50）にも注意が必要です。ConoHa VPS（Ver.3.0）のAPIリファレンスでは、セキュリティグループのルールで指定できるプロトコルは tcp・udp・icmp と、すべてを許可する指定の4種類で、ESPだけを個別に許可する項目はありません（2026年10月時点）。そこでこの記事では、strongSwanの設定でESPをUDP 4500に包んで送る（encap = yes）ようにし、UDP 500と4500だけで通信できるようにします。

パケットを転送するため、IPフォワーディングを有効にします。

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-ipforward.conf
sudo sysctl --system

strongSwanでトンネルを張る

strongSwanをインストールし、swanctl形式で設定します。Ubuntuのパッケージ名は2026年10月時点で strongswan-swanctl と charon-systemd です。

sudo apt install strongswan-swanctl charon-systemd

トンネル1本の設定例です。198.51.100.1 はAWSが発行したトンネル1の接続先IP、事前共有鍵もAWSが発行した値に置き換えます。暗号方式は、ダウンロードした設定ファイルと、AWS側のトンネルオプションで許可されている組み合わせに合わせてください。

# /etc/swanctl/conf.d/aws.conf
connections {
  aws-tunnel1 {
    version = 2
    local_addrs = 203.0.113.10
    remote_addrs = 198.51.100.1
    proposals = aes256-sha256-modp2048
    encap = yes
    dpd_delay = 10s
    local {
      auth = psk
      id = 203.0.113.10
    }
    remote {
      auth = psk
      id = 198.51.100.1
    }
    children {
      aws-net {
        local_ts = 172.16.0.0/24
        remote_ts = 10.0.0.0/8
        esp_proposals = aes256-sha256-modp2048
        start_action = start
        dpd_action = restart
      }
    }
  }
}
secrets {
  ike-aws1 {
    id = 198.51.100.1
    secret = "AWSが発行した事前共有鍵"
  }
}

local_ts と remote_ts は、VPN接続の作成時に指定した LocalIpv4NetworkCidr と RemoteIpv4NetworkCidr に合わせます。鍵を含むので、ファイルの権限はrootだけが読める状態にします。

sudo chmod 600 /etc/swanctl/conf.d/aws.conf
sudo swanctl --load-all
sudo swanctl --list-sas

MSSを調整する

IPsecで包むとパケットが大きくなるため、TCPの最大セグメントサイズ（MSS）を小さく書き換えます。AWSのドキュメントでは、暗号方式とNATトラバーサルの有無ごとに推奨値が示されています。AES-CBCとSHA2-256でNATトラバーサル（UDPカプセル化）を使う場合、MSSは1382バイトです。

# 転送する TCP の SYN パケットの MSS を 1382 に書き換える
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1382

# 再起動後も残す（iptables-persistent を使う場合）
sudo apt install iptables-persistent
sudo netfilter-persistent save

ほかの暗号方式を使う場合は、AWSのドキュメント「Best practices for an AWS Site-to-Site VPN customer gateway device」の表で値を確認してください。

ConoHaの他のVPSからAWSへ向ける

ローカルネットワーク上の他のVPSには、AWS宛ての経路をVPNルーター経由に設定します。

sudo ip route add 10.0.0.0/8 via 172.16.0.10

この設定は再起動で消えます。Ubuntuならnetplanの設定に経路を書いて永続化します。eth1 はローカルネットワーク側のインターフェース名に置き換えてください（ip -br addr で確認できます）。

# /etc/netplan/ 内の、ローカルネットワークのインターフェースを定義しているファイルに追記
network:
  version: 2
  ethernets:
    eth1:
      routes:
        - to: 10.0.0.0/8
          via: 172.16.0.10

追記後は sudo netplan try で確認してから反映します。

送信元IPの制限に注意する

ConoHaのローカルネットワークは、各ポートに割り当てたIPアドレス以外を送信元とするパケットを通さない場合があります。AWSから届いた通信をVPNルーターがローカルネットワークへ転送すると、送信元は 10.x.x.x のままなので、この制限で捨てられることがあります。ConoHa VPS（Ver.3.0）のAPIでは、ローカルネットワークのポートに allowed_address_pairs（CIDR形式）を指定できるので、VPNルーターのローカルネットワーク側のポートに 10.0.0.0/8 を指定する方法があります。APIを使わない場合は、VPNルーターでローカルネットワークへ出ていく通信に送信元NAT（SNAT）をかけて回避します。ただしSNATをかけると、ConoHa側のサーバーからはAWSの接続元IPが見えなくなります。

冗長化をどう考えるか

AWS側のトンネルは2本あり、AWS側のメンテナンスで片方が一時的に落ちることがあります。AWSは両方のトンネルを設定することを推奨しています。ただし、この記事のようなポリシーベースの設定で2本のトンネルに同じトラフィックセレクターを設定すると、どちらのトンネルを使うかの制御が難しくなります。

本番で使う場合は、strongSwanをルートベース（XFRMインターフェースなど）で構成してトンネルを2本張り、BGPで経路を交換する構成を検討してください。その場合、VPN接続は StaticRoutesOnly を指定せずに（動的ルーティングで）作成し、TGWのルートテーブルにはVPNアタッチメントからの経路伝播を使います。VPNルーターのVPS自体も単一障害点になるので、重要度に応じて2台構成を検討します。

疎通確認とつまずきやすい点

確認は内側から外側へ順に行います。

1. sudo swanctl --list-sas で、IKE SAとCHILD SAが確立しているかを見る
2. AWS側でトンネルの状態を確認する。CLIなら次のコマンドで、トンネルごとの状態（UP / DOWN）が見られる
3. VPNルーターから、VPC内のEC2インスタンスのプライベートIPへpingする（送信元を -I 172.16.0.10 で指定する）
4. ConoHaの別のVPSから、同じ宛先へpingとtracerouteをする

aws ec2 describe-vpn-connections \
  --vpn-connection-ids vpn-0123456789abcdef0 \
  --query 'VpnConnections[0].VgwTelemetry'

手順3で送信元を指定するのは、VPNルーター自身のグローバルIPから送ると、トラフィックセレクター（172.16.0.0/24）に当てはまらず、トンネルを通らないためです。

よくある症状と確認点は次のとおりです。

作業は検証用のVPCとVPSで手順を確かめてから本番に適用し、既存のルートテーブルを変更する前には現在の設定を控えておいてください。

まとめ

• ConoHaからAWSへは、VPSをVPNルーターにしてSite-to-Site VPNでTGWに接続する
• AWSのVPNはルートベース。strongSwan側で範囲を絞るなら、LocalIpv4NetworkCidr/RemoteIpv4NetworkCidr で両側のトラフィックセレクターをそろえ、SAを1組に収める
• TGWのルートテーブルだけでなく、各VPCのルートテーブルとセキュリティグループに戻りの設定を入れる
• ConoHaのセキュリティグループではESPを個別に許可できないため、encap = yes でUDP 4500に包む
• MSSはAWSのドキュメントの表に合わせる（AES-CBC＋SHA2-256＋NATトラバーサルなら1382）
• 本番ではルートベース＋BGPでトンネル2本を使い、VPNルーターの単一障害点も対策する

関連記事:

• AWS Transit Gateway の作成と情報取得の方法｜VPCアタッチメントとルートテーブル設定まで