ConoHa と AWS Transit Gateway をつなぐ方法｜ConoHa VPS を VPN ルーターにした Site-to-Site VPN 構成

ConoHa のサーバー群と AWS の複数 VPC をプライベートアドレスで通信させたい場合、現実的な方法は「ConoHa 上の VPS を IPsec VPN ルーターにして、AWS Site-to-Site VPN で Transit Gateway に接続する」構成です。この記事では、その構成の考え方、AWS 側と ConoHa 側の設定手順、つまずきやすい点と確認方法を説明します。読み終えるころには、検証環境で ConoHa から VPC 内のサーバーへ ping が通るところまで組めるようになることを目指します。

構成の全体像と前提

ConoHa には、同じリージョン内の VPS 同士をつなぐローカルネットワーク（プライベートネットワーク）の機能がありますが、AWS の Direct Connect のように AWS へ直接つなぐ接続サービスは、公式情報を見る限り提供されていません（2026年10月現在）。サービス内容は変わることがあるので、作業前に ConoHa の公式サイトで最新の機能を確認してください。

そのため、ここでは次の構成を前提にします。

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

VPC が一つだけなら、TGW を使わず仮想プライベートゲートウェイ（VGW）に VPN をつなぐほうが構成は簡単です。TGW を選ぶ理由は、複数の VPC やアカウントをまとめて ConoHa とつなぎたい、将来的に拠点が増える、といった場合です。TGW はアタッチメントやデータ処理量に応じて料金がかかるため、料金体系は AWS の公式ページで確認してください。

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

いちばん後戻りが難しいのがアドレス設計です。ConoHa のローカルネットワークと、TGW につながるすべての VPC の CIDR が重複していると、経路を正しく引けません。例として、この記事では次のように置きます。

• 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 の範囲に置く）
• ConoHa VPN ルーターのグローバル IP：203.0.113.10（例示用のアドレス）

AWS 側を 10.0.0.0/8 のような大きな範囲にまとめておくと、ConoHa 側の経路やトンネルのトラフィックセレクターを一つで済ませられ、設定が簡潔になります。

AWS 側の設定

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

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

# ConoHa の VPN ルーターをカスタマーゲートウェイとして登録
aws ec2 create-customer-gateway \
  --type ipsec.1 \
  --public-ip 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

VPN 接続を作ると、AWS 側にトンネルが 2 本用意され、それぞれの接続先 IP と事前共有鍵が発行されます。コンソールから接続設定ファイルをダウンロードでき、主な機器向けの設定例も選べるので、パラメーター（暗号方式、IKE のバージョン、DPD など）はそのファイルに合わせるのが手戻りの少ない進め方です。

TGW のルートテーブルと VPC のルートテーブル

静的ルーティングの VPN では、TGW のルートテーブルに 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

見落としやすいのが VPC 側です。各 VPC のサブネットのルートテーブルに「172.16.0.0/24 の宛先は TGW」というルートを追加しないと、行きは届いても戻りの通信が TGW に戻ってきません。さらに、VPC 内のインスタンスのセキュリティグループで、172.16.0.0/24 からの通信を必要な範囲で許可します。

ConoHa 側の設定

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

VPN ルーター役の VPS では、ConoHa のセキュリティグループ（パケットフィルター）で、AWS のトンネル接続先 IP からの UDP 500・UDP 4500 と ESP（IP プロトコル 50）を許可します。SSH など管理用のポートは、接続元を自分の作業環境に絞ってください。

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

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

strongSwan でトンネルを張る

Ubuntu などでは strongSwan の swanctl 形式で設定できます。以下はトンネル 1 本の例です。暗号方式などの値は、AWS からダウンロードした設定ファイルの内容に合わせてください。鍵は例のダミー値ではなく、AWS が発行した値を使い、設定ファイルの権限を root のみに絞ります。

# /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
    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 = "your-pre-shared-key"
  }
}

sudo swanctl --load-all
sudo swanctl --list-sas

AWS のポリシーベースの VPN は、トンネルあたり一組のトラフィックセレクターを前提にしているため、local_ts と remote_ts をそれぞれ一つの範囲にまとめておくと安定します。

冗長化をどう考えるか

AWS 側のトンネルは 2 本あり、AWS 側のメンテナンスで片方が落ちることがあります。静的ルーティングでポリシーベースのまま 2 本を同時に使うと、どちらのトンネルを使うかの制御が難しくなります。本番で使う場合は、ルートベース（XFRM インターフェースや VTI）でトンネルを 2 本張り、FRRouting で BGP を話して経路を交換する構成を検討してください。その場合、VPN 接続は StaticRoutesOnly を指定せずに作成し、TGW ルートテーブルには VPN アタッチメントからの経路伝播を使います。VPN ルーターの VPS 自体も単一障害点なので、重要度に応じて 2 台構成を検討します。

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

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

sudo ip route add 10.0.0.0/8 via 172.16.0.10

この設定は再起動で消えるため、netplan などで永続化します。注意点として、クラウドのローカルネットワークでは、なりすまし防止のために「そのサーバーに割り当てられていない送信元 IP」のパケットが破棄される場合があります。転送したパケットが途中で消えるときは、ConoHa の仕様を確認し、必要なら VPN ルーターで送信元 NAT（SNAT）をかけて回避します。

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

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

1. sudo swanctl --list-sas で IKE と CHILD SA が確立しているか。
2. AWS 側でトンネルの状態を確認する。CLI なら aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[0].VgwTelemetry' で各トンネルの状態が見られます。
3. VPN ルーターから VPC 内インスタンスのプライベート IP へ ping。
4. ConoHa の別 VPS から同じ宛先へ ping と traceroute。

ping は通るのに Web や SSH の大きな応答が途中で止まる場合は、IPsec のオーバーヘッドによる MTU の問題が疑われます。VPN ルーターで TCP MSS を小さく書き換える（MSS クランプ）のが一般的な対処で、推奨値は AWS の Site-to-Site VPN のドキュメントに記載があるので確認してください。トンネルは張れるのに通信が流れない場合は、TGW のルートテーブルの関連付け（どの VPC アタッチメントがどのルートテーブルを使うか）と、VPC 側の戻りの経路を見直します。

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

まとめ

• ConoHa から AWS へは、VPS を VPN ルーターにして Site-to-Site VPN で TGW に接続するのが現実的な構成。
• 最初に CIDR の重複がないアドレス設計を決め、AWS 側はまとめた範囲にしておくと設定が簡潔になる。
• TGW のルートテーブルだけでなく、各 VPC のルートテーブルとセキュリティグループに戻りの設定を入れる。
• 本番ではトンネル 2 本と BGP による冗長化、VPN ルーターの単一障害点対策を検討する。
• 大きな通信だけ止まるなら MTU・MSS を疑い、送信元 IP の制限があれば SNAT で回避する。

• AWS Transit Gateway の作成と VPC アタッチメント・ルートテーブル設定
• ConoHa VPS の初期設定