VPC の中で「つながらない」と言われたとき、SG を緩めたり NACL を触ったりして、たまたま通ったところで安心していませんか。原因が分からないまま通ると、不要な許可が残り、次に壊れたときも同じ迷い方をします。この記事は、仕組みの解説（VPC の通信が外に出る仕組み）を読んだ人が、原因を順番に絞り込む「運用の型」を身につけるためのものです。
この記事の結論
- つながらない原因は、経路（ルート）・入口と出口の許可（SG と NACL）・宛先の待ち受けの 3 か所に分けられます。
- まず Reachability Analyzer で、送信元から宛先までの設定上の経路を調べます。パケットは送らず、止めている部品を示してくれます。
- 設定は正しいのに通らないときは、VPC フローログで ACCEPT と REJECT を見て、実際に届いたかを確かめます。
- SG はステートフル、NACL はステートレスです。NACL では戻りの通信（エフェメラルポート）の許可も要ります。
- 直したら同じ経路をもう一度分析して、通ることを確かめます。変更は 1 回に 1 つにします。
つながらないときは何を疑うか｜経路・許可・宛先の 3 つに分ける
通信は、送信元を出てから宛先のアプリに届くまでに、いくつもの部品を通ります。「つながらない」はその全体の結果で、どこで止まったかまでは教えてくれません。そこで疑う場所を、次の 3 つに分けます。
| 分け方 | 見るもの | 止まるときの例 |
|---|---|---|
| 経路 | ルートテーブル、エンドポイントの関連付け | 行き先のルートが無い、ルートテーブルに関連付けていない |
| 許可 | SG、NACL | 必要なポートや送信元が許可されていない |
| 宛先 | アプリの待ち受け、OS 内の設定 | そのポートで待ち受けていない |
経路が無ければ、許可を直しても通りません。許可が閉じていれば、宛先のアプリが正常でも届きません。だから「経路 → 許可 → 宛先」の順に、手前から確かめます。
経路の例として、S3 のゲートウェイエンドポイントを作ったのに通信が従来の経路のままだった、という場面があります。ゲートウェイエンドポイントはルートテーブルごとに効くので、対象のサブネットのルートテーブルに関連付けていないと使われません。名前が引けない例もあります。インターフェイスエンドポイントでプライベート DNS を使うには、VPC の DNS 解決と DNS ホスト名の両方が有効でなければなりません。このように、設定した「つもり」と実際の状態がずれていることが原因になりやすいのです。
WHERE IT STOPS止まりうる6か所
つながらない原因は、経路・許可・宛先のどこかにある
-
ルート
行き先の登録があるか
-
NACL（出）
サブネットの出口
-
SG（出）
送信元の門
-
SG（入）
宛先の門
-
NACL（入）
宛先サブネットの入口
-
アプリ
待ち受けているか
CHECK 1ここまでの確認
パケットを実際には送らず、設定を分析して、送信元から宛先までの経路上で通信を止めている部品を示す道具はどれ?
答えと解説
答え: 2. Reachability Analyzer
設定を静的に分析して阻害要因を示すのが Reachability Analyzer です。フローログは実際に流れた通信の記録なので、役割が違います。「Reachability Analyzer とは何か」を読み直してください。
Reachability Analyzer とは何か｜パケットを送らずに経路を調べる道具
Reachability Analyzer は、送信元と宛先を指定して、その間の接続を設定から分析する VPC の機能です。実際にはパケットを送りません。到達できない場合は、SG、NACL、ルートテーブル、ロードバランサーなど、通信を止めている部品を特定して示します。
使い方の考え方は次のとおりです。
- 送信元と宛先、プロトコルとポートを決めて、分析を 1 回実行する
- 結果が「到達可能」なら、設定上は経路が通っている
- 「到達不能」なら、止めている部品が示されるので、そこを直す
ここで大事なのは、これが設定の分析であることです。宛先のアプリが待ち受けていない、OS 内のファイアウォールが止めている、といった VPC の外側の事情は見えません。「到達可能」と出てもつながらないなら、原因は設定の外側にあると考えて、次の手段へ進みます。
料金は、分析 1 回ごとにかかります。金額は変わりうるので、AWS の公式の料金ページで確認してください。
CHECK 2ここまでの確認
フローログの記録で、通信が許可されたのか拒否されたのかを見分けるのは、どの項目?
答えと解説
答え: 1. action（ACCEPT / REJECT）
許可か拒否かの結果は action に入ります。protocol と srcport は通信の種類と送信元のポートで、結果ではありません。「フローログで何が分かるか」を読み直してください。
VPC フローログで何が分かるか｜ACCEPT と REJECT の読み方と、見えないもの
VPC フローログは、ネットワークインターフェイスを出入りする IP 通信の記録です。出力先は CloudWatch Logs、S3、Data Firehose から選べます。記録は通信の経路の外で集められるので、通信の性能には影響しません。
1 件の記録には、送信元と宛先のアドレス、ポート、プロトコルなどに加えて、action という項目があります。値は次の 2 つです。
| action | 意味 |
|---|---|
| ACCEPT | 通信が受け入れられた |
| REJECT | 通信が拒否された。SG や NACL が許可していない場合のほか、接続が閉じた後にパケットが届いた場合も含む |
Reachability Analyzer が「設定の上でどうか」を見るのに対し、フローログは「実際に何が起きたか」を残します。つまり「届いたが拒否された」と「そもそも届いていない」を見分けられます。REJECT が出ていれば、通信は宛先側のネットワークまで来ていて、SG か NACL が止めています。記録が一切無いなら、経路の手前で止まっているか、そもそも送られていない可能性があります。
フローログに写らないもの
フローログはすべての IP 通信を記録するわけではありません。たとえば次の通信は記録されません。
- Amazon の DNS サーバーへの通信（自前の DNS サーバーを使う場合は記録される）
- インスタンスメタデータ（169.254.169.254）との通信
- DHCP の通信
- ARP の通信
「記録に出ない」ことが、そのまま「通信が無かった」ことを意味するとは限りません。また、記録はアドレスやポートなどのメタデータで、通信の中身までは見えません。中身を調べたいなら、通信そのものをコピーする別の仕組みが必要です。
TWO TOOLS設定を見る／通信を見る
先に設定を分析し、次に記録で裏を取る
Reachability Analyzer
設定を静的に見る
- 分かること経路上で止めている部品
- 分からないことアプリの待ち受け・OS 内の設定
- 使う場面最初の切り分け・直した後の確認
VPC フローログ
実際の通信の記録
- 分かることACCEPT / REJECT の結果
- 分からないこと記録されない通信・中身
- 使う場面設定が正しいのに通らないとき
CHECK 3ここまでの確認
行きの通信を許可しても、戻りの通信の許可を別に書かないと跳ね返されるのはどちら?
答えと解説
答え: 2. ネットワーク ACL
NACL はステートレスで、行きと戻りを別々に評価します。SG はステートフルなので、許可した通信の応答は自動で通ります。「SG と NACL のどちらが止めているか」を読み直してください。
SG と NACL のどちらが止めているか｜ステートフルとステートレスの違いが出る場面
許可のどちらが止めているかを見分けるとき、一番効くのが戻りの通信の扱いの違いです。
- SG はステートフル: 許可した通信の応答は、自動で通ります。
- NACL はステートレス: 以前に送受信した通信の情報を持たないので、行きの通信を許可しても、戻りは自動では許可されません。戻りの通信も、ルールで明示的に許可する必要があります。
特に、クライアントとして外へ出ていく通信では、応答の宛先が 1024 以上の範囲のエフェメラルポートになります。NACL のインバウンドでこの範囲を許可していないと、行きは ACCEPT なのに、戻りが入口で REJECT になります。フローログで「外向きは ACCEPT、応答は REJECT」という組み合わせを見たら、NACL の戻りの許可を疑うのが筋です。
SG の側でも見るべき点があります。層をまたぐ通信では、IP アドレスではなく SG を送信元に指定して許可すると、インスタンスの入れ替わりで IP が変わっても許可が追随します。「この IP を許可したはずなのに」という食い違いを避けられます。
STATEFUL OR NOT戻りの通信の扱い
SG は戻りが自動で通る。NACL は戻りも許可が要る
戻りの通信（応答）
- SGステートフル 戻りは自動で通る行きを許可すれば
- NACLステートレス 通る戻りの許可を書けば
- NACLステートレス 跳ね返る戻りの許可がないと
CHECK 4ここまでの確認
つながらないとき、設定を変える前に最初にやるのは?
答えと解説
答え: 2. 経路を分析して、止めている部品を特定する
当てずっぽうの変更は、本当の原因を隠し、ほかの通信まで通してしまいます。先に原因の部品を特定し、直したら再分析で確かめます。「調べる順番を手順にする」を読み直してください。
調べる順番を手順にする｜分析 → 記録 → 宛先の確認 → 直して再分析
ここまでを 1 本の手順にします。
- 経路を分析する: Reachability Analyzer で、送信元から宛先、対象のポートまでを分析する。止めている部品が示されたら、それが第一候補。
- 設定上は通るなら、フローログを見る: 宛先側のネットワークインターフェイスの記録で、ACCEPT か REJECT かを見る。REJECT なら SG と NACL を、戻りの通信の扱いも含めて見る。
- ACCEPT なのにつながらないなら、宛先を見る: アプリがそのポートで待ち受けているか、OS 内のファイアウォールが止めていないかを確かめる。
- 1 つだけ直して、再分析する: 変更は 1 回に 1 つ。同じ経路をもう一度分析し、通ることを確かめる。
やってはいけないこと
- 原因が分からないまま、複数の許可を一度に緩める
- 通ったことだけを見て、何を直して通ったのかを残さない
当てずっぽうに複数を変えると、どの変更が効いたのか分からなくなり、不要な許可が残ります。1 つずつ直し、再分析で確かめれば、原因と対処が 1 対 1 で記録に残ります。
調べる準備を平時にしておく運用｜フローログの保存先と料金の考え方
障害の最中にフローログを有効にしても、それ以前の通信は残っていません。つながらなくなってから「いつから」「どの通信が」を知りたいなら、記録は平時から取っておく必要があります。
ただし、記録した量に応じて保存先の料金がかかります。何を残すかは次の観点で決めます。
- どのネットワークインターフェイス、サブネット、VPC を対象にするか
- 保存先はどこか（すぐ検索したいなら CloudWatch Logs、長く安く残すなら S3 など）
- いつまで残すか
保存期間と保存先の考え方は、ログの保存の設計で扱っています。また、複数の VPC をつなぐ構成では調べる範囲が広がります。その設計はネットワーク設計で扱います。
Cloudory 執筆者（AWS 認定 全冠）
「つながらない」と言われたら、まず設定の分析、次に実際の記録、最後に宛先、の順です。この順番を言葉で説明できれば、後輩や顧客にも調べ方を渡せます。
参照ソース
- Reachability Analyzer とは（Amazon VPC Reachability Analyzer ガイド） — 送信元と宛先の間の接続を分析し、止めている部品を特定すること、分析 1 回ごとの課金であることの根拠
- VPC フローログ（Amazon VPC ユーザーガイド） — 記録の対象、出力先、通信の経路の外で収集されることの根拠
- フローログのレコード（Amazon VPC ユーザーガイド） — action の ACCEPT と REJECT の意味の根拠
- フローログの制限事項（Amazon VPC ユーザーガイド） — 記録されない通信の根拠
- ネットワーク ACL でサブネットの通信を制御する（Amazon VPC ユーザーガイド） — NACL がステートレスで、戻りの通信が自動では許可されないことの根拠
