Claudeで多国間ECSサーバーを結ぶ越境WireGuardメッシュを二時間で構築する方法

要点： WireGuardのメッシュ構築でClaudeが本当に効くのは、ピア設定一式——公開鍵、AllowedIPs、エンドポイント——を書き写しミスなしに一貫して生成するところです。三、四ノードなら二時間が現実的になるのはそのためです。二時間に含むもの：鍵、設定、ファイアウォール規則、疎通開始、そして全経路の双方向検証。含まないもの：サーバーが既に存在していること、越境に関する規制の確認、冗長化設計、監視、そして鍵のローテーション方針。

深圳・香港・シンガポールにワークロードを持つ会社は、いずれそれらのサーバー同士を私設経路でつなぐ必要に迫られます。データベースの複製、社内API、公開インターネットから決して届いてはならないバックアップ先。そこで返ってくる企業向けSD-WANの見積もりは、四十拠点には筋が通っても、仮想マシン三台にはまったく通りません。

WireGuardは分かりやすい代替案です。小さく、カーネルで動き、設定ファイル一式は一画面で読み切れます。実際より難しく感じさせるのはこの点です。各ピアは他の全ピアの公開鍵と許可アドレス範囲を知っている必要があり、一文字の打ち間違いが「きれいに確立するのに何も運ばないトンネル」を生みます。自信ありげで、無言で、追跡が退屈なこの失敗こそ、言語モデルが取り除ける部分です。

これは自社が所有するインフラを、自社が管理するクラウドアカウントの中で構築する手引きです。同じ課題が納品プロジェクトとしてどう見えるかは、中国リージョンのクラウド基盤についての記事が近い視点を扱っています。

越境のサーバー間接続が見た目より難しい理由

問題がトンネルのプロトコルにあることは稀で、たいていはその周辺にあります。

クラウドネイティブのピアリングはこの隙間をまたげません。 VPCピアリングやトランジットゲートウェイは、同一事業者内、多くは同一リージョン内では優秀です。深圳のAlibaba Cloudとシンガポールのアマゾン ウェブ サービス、あるいは二か国の別々のアカウント、となった途端に、ネイティブの選択肢は途切れるか商談に変わります。

商用の選択肢は別の規模の会社向けに値付けされています。 マネージドSD-WAN、専用線、クラウド相互接続はいずれも本物の答えですが、どれも拠点と機器と契約期間を持つ規模に合わせて作られています。サーバー三台はその規模ではありません。

そして規制の次元は本当に別物です。 中国本土リージョンのインスタンスが関わる越境接続は規制領域にあり、何が適切かはその回線が何を運ぶか、誰が運用するか、事業が何かによって変わります。これは着手前に現地の法務とクラウド事業者のコンプライアンス窓口に確認する事柄であって、後付けの手続きではありません。本記事のどの記述もその助言の代わりにはなりません。

そこで各社は手作業で組みます。そして手作業こそが誤りの源です。WireGuardで最も重要なフィールドは、同時に最も目立たないフィールドでもあるからです。AllowedIPs はルーティングテーブルであると同時に、暗号レベルのアクセス制御リストでもあります。片方向を誤れば通信は消え、逆を誤ればあるノードが意図をはるかに超える範囲に到達します。

Claudeがここで実際にやること、やれないこと

書き写しミスのない一貫したピア設定一式をどう生成するか

四ノードのフルメッシュでは各ノードに三つのピア定義が要り、合計十二。それぞれが44文字のBase64公開鍵、アドレス範囲、エンドポイントを抱えます。十二個を手で打つのは、人が静かに失敗する典型的な作業です。

トポロジーを仕様としてClaudeに渡します。ノード名、リージョン、グローバルIPアドレス、待ち受けポート、選んだトンネル用サブネット、そして各ノードの公開鍵。返ってくるのは、構造として整合した設定一式と、そこから導かれる検証マトリクス——どのピアがどのアドレスで、どの向きに、どのピアへ到達すべきか、です。

単一ファイルでは見えず、束ねると明白になる構造的な誤りも拾います。二つのピアの AllowedIPs が重なり、先に一致した側へ通信が黙って流れる。トンネル用サブネットが既存のVPCのCIDRやオフィスLANと衝突する。NAT配下の一台だけ PersistentKeepalive が抜けている。エンドポイントが相手から到達できない私設アドレスを指している。

他のどれより重要な境界が一つあります。秘密鍵はモデルに渡さないこと。 鍵ペアはそれを使う機器の上で生成し、秘密側はその機器に置き、Claudeには公開鍵だけを渡します。公開鍵は公開される前提の設計物です。どの事業者であれチャット欄に貼られた秘密鍵は既に管理下を離れており、その時点での誠実な対処は作り直すことです。

トポロジー・アドレス設計・信頼境界を自分で決めるべき理由

説明した通りのものをモデルは動く形で出してきます。全ノードが全サブネットへ到達できてしまう説明も含めてです。それは誰の意図でもないことがほとんどで、しかもモデルには捕まえられません。意図を知る手段がないからです。

トポロジーは障害モードの選択です。 フルメッシュは全ペアに直行経路を与え単一障害点をなくしますが、設定もファイアウォール規則も増えます。ハブアンドスポークは考えやすく変更も安価ですが、ハブが落ちれば全部が落ちます。意識して選んでください。

アドレス設計はあなたの仕事です。 今持っているものとも、この先持ちうるものとも衝突しないトンネル用サブネットを選ぶ。五分の判断ですが、サービスがアドレスを埋め込んだ後では戻すのが苦痛です。

AllowedIPs はアクセス制御そのものです。 香港ノードがシンガポールのVPC全体に届いてよいのか、特定ホストの特定ポートだけなのかを、ピアごとに決める。緩い版に六つのサービスが依存してから締めるより、最初から厳しく書くほうがはるかに楽です。

二時間の構築手順

0:00–0:20 — アドレス設計、トポロジー決定、ピア台帳

各ノードについて書き出します。短い名前、リージョンと事業者、グローバルアドレス（Elastic IPか静的IP。動的割り当てはインスタンスの初回再起動でメッシュを壊します）、待ち受けるUDPポート、トンネル用サブネット内で持つアドレス。フルメッシュかハブアンドスポークかを決め、その理由も書きます。将来の担当者が必要とするのは理由のほうです。

0:20–0:50 — 鍵の生成とピアごとの設定

各ノード上で鍵ペアを生成し、秘密鍵は権限を絞ってその場に置きます。公開鍵を台帳にまとめ、その台帳をClaudeに渡し、設定一式とそこから導かれる到達性マトリクスを求めます。サーバーに何かを書き込む前に、返ってきたものを台帳と突き合わせて読むこと。この確認こそが後段を速くする要で、飛ばせば二時間の構築が二時間の障害切り分けに変わります。

0:50–1:20 — リージョンごとのセキュリティグループとファイアウォール規則

各ノードは待ち受けポートへのUDP受信を許可する必要があり、送信元は 0.0.0.0/0 ではなく各ピアの具体的なグローバルアドレスにします。これは事業者ごと、リージョンごとに繰り返す雑務です。Alibaba Cloudとアマゾン ウェブ サービスの間でも、アカウント間でも、画面構成も規則モデルも既定の送信挙動も違います。三十分まるごと確保してください。最も伸びやすい工程です。

1:20–1:50 — 疎通開始と全経路の双方向検証

各ノードでインターフェースを起動し、ハンドシェイクの成立を確認します。WireGuardの状態表示はピアごとの最終ハンドシェイク時刻を示し、一度もハンドシェイクしないピアは鍵ではなくファイアウォールかエンドポイントの問題です。次に有向ペアをすべて試します。四ノードなら十二方向。「双方向だから」と六つで済ませることが、非対称な規則が本番まで生き延びる典型的な経路です。

pingで止めないこと。各経路で実際に数メガバイトを転送します。MTUが誤ったトンネルは小さなパケットを完璧に通し、少し大きくなると止まるからです。

1:50–2:00 — 設定の永続化、文書化、引き渡し

再起動に耐えるようインターフェースをサービスとして有効化し、設定ファイルを会社が所有する場所——設定リポジトリか秘密情報の保管サービス——に置きます。エンジニアのノートPCではありません。アドレス設計、どの秘密鍵を誰が持つか、どのファイアウォール規則を何のために開けたかを記録します。この十分が、資産と負債の分かれ目です。

自前WireGuardメッシュ vs マネージドSD-WAN vs クラウドネイティブ接続

• 費用 — 自前のWireGuardの圧勝。トンネル自体は無料で、支払うのは元々払っていた送信量だけです。
• 最初の疎通までの時間 — WireGuardの勝ち。本記事の主張そのものです。SD-WANは調達が要り、クラウド相互接続には開通待ちがあります。
• 事業者と国をまたぐ到達性 — WireGuardの勝ち。相手側がどのクラウドかを問わない点が、深圳＋シンガポールのような構成に合う理由です。
• 障害時の挙動と経路品質 — マネージドSD-WANの明確な勝ち。経路選択、複数回線間の切り替え、アプリ単位の制御が製品の中身であり、手組みのメッシュには一つもありません。
• 運用負担 — クラウドネイティブ接続の勝ち。パッチも監視もローテーションも不要という点は、十二か月目に効いてきます。
• 深夜二時に壊れたときの支援 — SD-WANかクラウド事業者の勝ち。自前メッシュの保守契約は「作った本人」であり、この比較が本当に問うているのはそこです。

三か月目に壊れるもの

鍵のローテーションを誰も予定していない。 初日に作った鍵がそのまま残り、その中には別チームへ移ったエンジニアのノートPC上の鍵も含まれます。

MTUは遅れてやってくる。 数週間は問題なく動き、新しいサービスが大きなデータを流し始めた途端、一経路だけタイムアウトし始めます。

誰も見ていない。 トンネルが落ちたことを、利用者から「レポートが空だ」と言われて知る。ハンドシェイク状態、到達性、規則の乖離はいずれも監視できますが、手組みのメッシュではたいてい監視されていません。

どれも珍しくありません。担当者がいる網が受ける平凡な保守と、いない網が受ける平凡な放置の、その差でしかありません。

正しく進めるために——鍵の保管、変更記録、ITに任せる範囲

メッシュが重要なものを運び始める前に、決めておく価値のあることが三つあります。

第一に鍵の保管。WireGuardのメッシュでは秘密鍵こそがアクセス制御で、第二要素も、失効させるべき中央の権威も存在しません。どこで生成し、どこに保管し、誰が読め、退職の日に何が起きるかを決めてください。その答えは誰かの記憶ではなく手順であるべきです。AI+サポートはこの種の作業を個人の道具ではなく会社アカウントと統制された資格情報の上に整えることを支援し、管理型ITサポートはその周りのIDと退職処理のライフサイクルを扱います。

第二に変更記録。開けたファイアウォール規則には理由があり、三か月後には誰も覚えていません。規則の隣に理由を書く。監査が後で楽になるのもここで、その場では費用がかかりません。

第三に構築より長生きする保守。メッシュも他のネットワーク機器と同じ地味な世話を要します。設定バックアップ、ファームウェアとパッケージの更新、稼働確認、そしてトンネルが本当に生きているかを見る人。それはまさにネットワーク・ハードウェア保守が扱う範囲で、VPNレベルの監視と四半期ごとの設定バックアップを含みます。手組みのメッシュが七か月目にどうなるかへの、正直な答えです。Brocentは2007年の北京での創業以来アジアで管理型ITを提供しており、本社はシンガポール、2016年から香港オフィスを構えています。

よくある質問

自前のWireGuardメッシュは本番に耐えますか？

数ノード間の私設サーバー接続としては耐えます。WireGuardは成熟した評価の高いプロトコルで、多くの本番トラフィックが乗っています。自前メッシュに無いのは経路の冗長性、自動切り替え、そして電話をかけられる相手です。その回線の断が事業を止めるなら、それらを意識して足すか、最初から備えた製品を買ってください。

秘密鍵は誰が持ち、退職時に何が起きますか？

各ノード上のファイルを読める人が持っています。中央の失効機構がないため、誰かのアクセスを外すとは、その人が触れられたノードの鍵をローテーションし、それを信頼していた全ピアを更新することです。必要になる前に段取りを決め、鍵の台帳は個人のパスワード管理ではなく会社が管理する場所に置いてください。

SD-WANを買うのと何が違いますか？

SD-WANはマネージド製品で、経路選択、複数回線間の切り替え、アプリを意識した制御、集中ポリシー、そして保守契約が付きます。WireGuardのメッシュはペアごとの暗号化トンネルだけで、それ以外はありません。私設経路が要るだけのサーバー三台なら、その差は費用に見合わないことが多い。音声や業務アプリを載せる多拠点網なら見合います。

中国本土リージョンのピアについて、越境の規制上どんな考慮が要りますか？

エンジニアが作業中に判断してよい量ではありません。中国本土リージョンのインスタンスからの越境接続は規制領域にあり、何が適切かは回線が何を運ぶか、法人がどう設立されているかで変わります。稼働前に現地法務とクラウド事業者から見解を得て、その判断の記録を設定と一緒に保管してください。

Claudeは私たちの鍵を見られますか？

貼り付けた場合だけです。ですから貼らないこと。秘密鍵はそれを使うノード上で生成し、共有するのは公開鍵だけにします。一般的な作法として、使っている製品階層のデータ取り扱いと学習利用の条件は、思い込みではなく確認してください。法人向けと消費者向けは異なるのが普通で、条件も変わります。

SSHは通るのにファイル転送が止まるのはなぜですか？

MTUの問題の典型的な兆候です。小さなパケットは収まって通り、大きなものは経路上のどこかが行っていない分割を必要とするため、接続は確立してから止まります。大きな転送が安定して完了するまでトンネルインターフェースのMTUを下げるのが標準的な対処で、疎通確認の時点で実際に転送してみることが、利用者より先に気づく方法です。

まずどこから

最小の有用版から始めます。二ノード、一本のトンネル、両側の厳しい AllowedIPs、そして受け入れ試験としての実データ転送。三つ目のノードを足す前にこれを端から端まで通すこと。型が正しければメッシュはきれいに広がりますし、四ノードを一気に組んで切り分けるのは別種の、より悪い午後になります。ネットワークの他の部分と合わせて、構築・監視・保守までまとめて任せたいなら、お問い合わせください。