こんにちは、シニアSREの私です。
オンプレミスのデータセンター（DC）とAWSのVPC、あるいはAzureのVNetを接続するプロジェクトは、インフラエンジニアにとって腕の見せ所であり、同時に夜も眠れなくなるプレッシャーがかかる瞬間でもあります。インターネットを介さないセキュアで太いパイプライン――AWS Direct ConnectやAzure ExpressRoute。これらをただ繋ぐだけでなく、実務で耐えうる堅牢なハイブリッドネットワークとして構築・運用するには、物理回線の向こう側で何が起きているのか、パケットの挙動からBGPのステートマシンまで解像度高く理解しておく必要があります。
今回は、現場のトラブルシューティングで何度も泣く泣くパケットキャプチャを覗いてきた私が、Direct Connect / ExpressRouteを用いた閉域網接続の設計と、BGP動的ルーティングの肝を徹底的に解説します。
—
1. 専用線接続の全体像と通信の仕組み
クラウドとオンプレミスを専用線で結ぶ際、私たちは「ただ回線を引けば繋がる」という幻想を捨てなければなりません。物理的な冗長化（プライマリとセカンダリ）、その上を流れるVLAN（IEEE 802.1Q）、そしてルーティングの生命線であるBGP（Border Gateway Protocol）という、レイヤー2からレイヤー4・7に至るまでの精密な積み木の上にシステムは成り立っています。
通信フロー（BGP確立までのシーケンス）
専用線接続において、IPパケットがオンプレミスからクラウドへ到達するまでのバックグラウンドでは、以下のようなハンドシェイクとルーティング情報の交換が行われています。
[オンプレミス ルーター] [クラウド（AWS Direct Connect / ExpressRoute）]
| |
| --- 1. 物理回線リンクアップ・LACP/VLAN確立 ----> |
| |
| --- 2. BGP OPEN メッセージ送信 (TCP Port 179) -> |
| <--- 3. BGP OPEN 応答 ------------------------- |
| |
| <== 4. BGP Established (セッション確立) ======> |
| |
| --- 5. UPDATE (自網のプレフィックス通知) ------> |
| <--- 6. UPDATE (VPCのプレフィックス通知) ----- |
| |
| --- 7. データパケット送受信開始 (API等) -------> |1. 物理・データリンク層の確立:
キャリアの回線終端装置（CE/PE）と、AWS側のDirect Connectルーター（またはAzure側のMicrosoft Enterprise Edge: MSEE）の間で物理リンクが光り、VLANタグ（例: vlan-100）が一致することでレイヤー2のパスが通ります。
2. TCPコネクションの確立:
BGPはTCP（ポート番号 179）をトランスポート層として使用します。お互いのルーターのピアIPアドレス間で、3ウェイハンドシェイク（SYN -> SYN-ACK -> ACK）が行われます。
3. BGPセッションの確立 (Established):
OPENメッセージを交換し、AS番号（Autonomous System Number）やKeepaliveのタイマー値に合意すると、ステートが Established に移行し、晴れてルーティング情報の交換準備が整います。
4. ルートの交換 (UPDATE):
お互いが保持しているネットワークセグメント（例: オンプレ側 10.100.0.0/16、AWS側 10.200.0.0/16）を UPDATE メッセージで広告し合います。これにより、双方のルーティングテーブルに動的な経路が書き込まれます。
—
2. 実務で必須となる主要パラメーターの設計
専用線接続の設計書を書く際、あらかじめ関係部署（キャリア、ネットワークチーム、クラウド管理者）とすり合わせておくべき主要パラメーターがあります。これらを曖昧にすると、接続テストの段階でルーティングループやパケットロスに悩まされることになります。
- AS番号 (Autonomous System Number):
- プライベートAS番号（
64512〜65534）を使用するのが一般的です。オンプレミス側とクラウド側で重複しないようにアサインします（例: オンプレ側65001、AWS側64512）。 - BGPピアIPアドレス:
- AWSやAzure側から
/30または/29のサブネットマスクが割り当てられます。この中のIPアドレスを、オンプレミス側のルーターインターフェース（BGPプライマリ/セカンダリ）に設定します。 - BGP認証 (MD5 Password):
- セキュリティ要件の厳しい企業では、BGPセッションにMD5パスワード認証をかけることが必須となります。盗聴や不正なBGPインジェクションを防ぎます。
- BFD (Bidirectional Forwarding Detection):
- BGPのKeepaliveだけでは、数秒〜数十秒かかる障害検知を、ミリ秒単位（例: 300ms間隔×3回ロスで検知）で高速化するためのプロトコルです。専用線接続の冗長切り替え（フェイルオーバー）をシームレスに行うために必ず有効化を検討しましょう。
—
3. 設定ファイル・コード例（実践）
ここでは、実務で最も遭遇するケースとして、Ciscoルーター（IOS-XE）におけるAWS Direct Connect (VIF) 向けのBGP設定と、接続完了後に正常に通信できているかを検証するためのPythonスクリプト（AWS API / Web API呼び出しテスト）を紹介します。
A. オンプレミス・ルーター側 BGP設定サンプル (Cisco IOS-XE)
! --- ループバックインターフェース（BGPのUpdate Source用） ---
interface Loopback0
ip address 192.168.255.1 255.255.255.255
! --- Direct Connect用物理インターフェースのサブインターフェース設定 ---
interface GigabitEthernet0/0/1.100
encapsulation dot1Q 100
ip address 169.254.255.2 255.255.255.252 ! AWS側から指定されたプライマリピア用IP
no shutdown
! --- BGPルーティングの設定 ---
router bgp 65001
brouter-id 192.168.255.1
bgp log-neighbor-changes
! プライマリAWS Direct Connectルーター（ピア）の設定
neighbor 169.254.255.1 remote-as 64512
neighbor 169.254.255.1 description AWS-DX-Primary-Peer
neighbor 169.254.255.1 password MySecureBgpPassword123! ! MD5認証パスワード
neighbor 169.254.255.1 timers 10 30 ! Holdタイムアウト等の調整
! 自網のプレフィックスをAWS側に広告する
address-family ipv4 unicast
network 10.100.0.0 mask 255.255.0.0
neighbor 169.254.255.1 activate
exit-address-familyB. 接続確認用 Pythonスクリプト (Fetch API相当 / Requests)
専用線が確立されたら、インターネットを経由せずに閉域網経由でプライベートVPC内のWeb APIやエンドポイント（ALB / API Gateway Private）にアクセスできるかをテストします。
import sys
import requests
from requests.exceptions import RequestException
# 閉域網経由でAWS側（VPC内）に配置された内部ALBのプライベートIPまたは内部DNS名を指定
TARGET_API_URL = "http://internal-app-lb-123456789.ap-northeast-1.elb.amazonaws.com/healthcheck"
def verify_private_connectivity():
print(f"[*] 閉域網経由での接続テストを開始します: {TARGET_API_URL}")
try:
# タイムアウトを3秒に設定し、オンプレミスからのルーティング遅延やパケットロスを検知
response = requests.get(TARGET_API_URL, timeout=3.0)
# ステータスコードの確認
if response.status_code == 200:
print("[SUCCESS] 専用線経由でのAPI疎通に成功しました！")
print(f"レスポンスボディ: {response.json()}")
else:
print(f"[WARNING] 接続は確立できましたが、予期せぬステータスコードです: {response.status_code}")
sys.exit(1)
except RequestException as e:
print(f"[ERROR] 閉域網経由での通信に失敗しました。ルーティングやセキュリティグループを確認してください。")
print(f"詳細エラー: {e}")
sys.exit(1)
if __name__ == "__main__":
verify_private_connectivity()—
4. 現場のシニアが教える「ハマりどころ」とデバッグ手順
最後に、構築現場や本番稼働直後によくあるトラブルと、その泥臭いデバッグ手法を共有します。
1. 「BGPが Idle または Connect のまま Established にならない」
- 原因の多く: ファイアウォールやセキュリティグループ、あるいはキャリア側のアクセスリスト（ACL）で TCPポート
179がブロックされています。 - デバッグ手順:
ルーターから ping が通ることを確認した上で、ルーターのコンソールからパケットキャプチャ（Ciscoなら debug ip bgp や Embedded Packet Capture）を有効にし、SYNパケットに対してSYN-ACKが返ってきているか（あるいはRSTで拒絶されていないか）を確認します。また、MD5パスワードのタイポ（大文字小文字のミス）も非常によくある原因です。
2. 「BGPは Established なのに、宛先IPにパケットが届かない（非対称ルーティング等）」
- 原因の多く: オンプレミス側からAWSへ行くパケットのルーティングと、AWSからオンプレミスへ返るパケットのルーティングが不整合を起こしています。
- デバッグ手順:
AWS側のVPCルートテーブルに、オンプレミスのプレフィックス（例: 10.100.0.0/16）のターゲットとして「仮想プライベートゲートウェイ（VGW）」または「Direct Connectゲートウェイ」が正しくアタッチされているかを確認します。また、Linuxインスタンス上で traceroute を実行し、どのホップでパケットがブラックホールに落ちているかを特定します。
—
まとめ
AWS Direct ConnectやAzure ExpressRouteを用いたハイブリッドクラウドネットワークの構築は、一見すると複雑なパズルのように見えますが、物理層からBGPレイヤーに至るまで「今、どの層で何が起きているか」を論理的に分解して追っていけば、必ず原因にたどり着くことができます。
安定した閉域網は、強固なWebアプリケーションアーキテクチャの土台そのものです。本記事の知識と設定例が、皆さんの現場での円滑なクラウド移行やインフラ運用の力になれば幸いです。次回の記事では、冗長回線の切り替わり（フェイルオーバー）時に発生するセッション断を最小限にするためのチューニングについて深掘りする予定です。お楽しみに！
コメント