こんにちは！
カスタマーサクセス部の河本と申します。
今回の記事では、実際にTransit Gateway Flow Logsの中身を見て理解を深めたいと思います。
Transit Gateway Flow Logsとは、Transit Gatewayを経由するトラフィックをロギングする機能です。
ログの中身については後述しますが、Transit Gatewayを使用した複雑なネットワーク構成でのトラブルシューティングにも役立ちます。
本記事の目次は以下の通りです。
構成図
ログを取得するために以下の構成を構築しました。
EC2間でping疎通することにより、ログを取得してやろうという魂胆です。
東京リージョンのVPC Aに存在するEC2から、大阪リージョンのVPC Bに存在するEC2へ向けてpingを飛ばします。
設定方法
Transit Gateway Flow Logsは、S3またはCloudWatch Logsに保管することが可能です。
ネットワーク関連のログは膨大になりがちなため、分析やフィルタができるCloudWatch Logsに保管することを推奨します。
そのため今回はCloud Watch Logsに保管するよう設定してみます。
１．ロググループの作成
CloudWatchコンソールより、ロググループを作成します。
２．IAMロールの作成
今回はAWS公式ページの手順を使用します。
インラインポリシーおよび信頼ポリシーは以下の通りです。
インラインポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Resource": "*"
}
]
}
信頼ポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "vpc-flow-logs.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
３．フローログの作成
①対象のTransit Gatewayを選択し、[アクション]-[フローログを作成]を選択します。
②先ほど作成したロググループ、IAMロールを使用し、[フローログを作成]を選択します。
※今回は全てのフィールドを出力させるため、ログのレコード形式は[AWSのデフォルト形式]とします。
大阪リージョンにも同様の設定をすれば完了です！
フローログを確認してみる
それでは準備が整ったので、ping疎通してみます。
[ec2-user@ip-10-0-0-59 ~]$ ping 192.168.0.67 -c 3 PING 192.168.0.67 (192.168.0.67) 56(84) bytes of data. 64 bytes from 192.168.0.67: icmp_seq=1 ttl=124 time=11.8 ms 64 bytes from 192.168.0.67: icmp_seq=2 ttl=124 time=9.66 ms 64 bytes from 192.168.0.67: icmp_seq=3 ttl=124 time=10.0 ms --- 192.168.0.67 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 9.664/10.498/11.782/0.921 ms [ec2-user@ip-10-0-0-59 ~]$
pingが通りました・・・！！
やはりネットワーク疎通がうまくいくのは気持ちのいいものですね。
それではフローログを取得できているか見てみましょう。
無事取得できていました。アタッチメント単位でログストリームが作成されるようです。 ログが出力されるまで5分ほどのラグがありました。
ログの中身
以下はVPC Aのピアリングアタッチメントのログです。
※AWSアカウントIDは伏せます。
2024-02-09T12:19:44.000+09:00 6 TransitGateway [AWSアカウントID] tgw-0d1aff278ad1e771f tgw-attach-0ed66ac38ad74f63d [AWSアカウントID] [AWSアカウントID] vpc-0038c660f34e32728 - subnet-0153e04c0b230623c - eni-0248c46d8b6ad8c66 - apne1-az4 apne1-az4 tgw-attach-08c673f56543ad414 10.0.0.59 192.168.0.67 0 0 1 3 252 1707448784 1707448786 OK IPv4 0 0 0 0 0 ap-northeast-1 egress - -
使用されないフィールドは「-」になります。
また、公式ページによると各フィールドは以下の意味があるようです。
2024-02-09T12:19:44.000+09:00 [バージョン] [リクエストタイプ] [送信元Transit Gatewayを所有しているAWSアカウントID] [Transit GatewayのリソースID] [Transit GatewayアタッチメントのリソースID] [送信元VPCを所有しているAWS アカウント ID] [送信先VPCを所有しているAWS アカウント ID] [送信元VPCのリソースID] [送信先VPCのリソースID] [送信元サブネットのリソースID] [送信先サブネットのリソースID] [送信元ピアリングアタッチメントENIのリソースID] [送信先ピアリングアタッチメントENIのリソースID] [送信元Transit Gatewayを含むAZのID] [送信先Transit Gatewayを含むAZのID] [フローの出力先または入力元のアタッチメント ID] [送信元アドレス] [送信先アドレス] [送信元ポート] [送信先ポート] [プロトコル番号] [パケット数] [転送されたパケットバイト数] [転送されたバイト数] [最初のパケットを受信した時間 (UNIX 秒)] [最後のパケットを受信した時間 (UNIX 秒)][フローログのステータス] [トラフィックの種類] [ルートが指定されていないためにロスしたパケット数] [送信先がブラックホール（削除された）の場合にロスしたパケット数] [MTUを超えるためにロスしたパケット数] [TTL満了によりロスしたパケット数] [TCPフラグのビットマスク値] [トラフィックが記録されるTransit Gatewayを含むリージョン] [トラフィックフローの方向] [srcaddr 用の IP アドレスの範囲のサブセットの名前] [dstaddr フィールド用の IP アドレスの範囲のサブセットの名前]
送信先や送信元のリソースIDはもちろんのこと、理由別にパケットロス数のフィールドが分かれているので、トラブルシューティングに役立ちそうですね。 これを全て覚えきるのは現実的ではないので、以下いずれかの対応になるかと思います。
- 都度、公式ページとフィールドを突き合わせながら確認する。
- フローログを設定する際にカスタム形式で設定し、不要なフィールドを省いたり見やすいフォーマットにする。
どのようなトラブルシューティングに役立つか
次は色々な疎通不可のケースを作り出して、どのようにログが出力されるのか確認したいと思います。 果たしてどのようなケースのトラブルシューティングに役立つのでしょうか。
存在しないホストのIPアドレスに対してping疎通
第4オクテットを変更し、存在しない192.168.0.10にping疎通しました。
[ec2-user@ip-10-0-0-59 ~]$ ping 192.168.0.10 -c 3 PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data. --- 192.168.0.10 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2054ms [ec2-user@ip-10-0-0-59 ~]$
ping疎通は失敗しました。
しかしVPC BのTransit Gatewayアタッチメントのログを見ても異常は見当たりません。
2024-02-09T14:27:36.000+09:00 6 TransitGateway [AWSアカウントID] tgw-0b3c56f918504bd66 tgw-attach-04921288a41262589 - [AWSアカウントID] - vpc-03da3869f659f228e - subnet-0d7f466ad9088b317 - eni-0a4d0f19954b1cd7c apne3-az1 apne3-az3 tgw-attach-0ed66ac38ad74f63d 10.0.0.59 192.168.0.10 0 0 1 3 252 1707456456 1707456458 OK IPv4 0 0 0 0 0 ap-northeast-3 egress - -
今回はTransit Gatewayルートテーブルで10.0.0.0/16と192.168.0.0/16のVPCを接続しています。 ネットワークアドレスは正常なため、Transit Gatewayを渡り切ったあと、VPC内でパケットが消失しているように見受けられます。アタッチメントから先の通信はTransit Gatewayフローログの範疇ではないようですね。
VPC BからTransit Gatewayアタッチメントを削除してみた
VPC BからTransit Gatewayアタッチメントを削除してみました。
つまりこうなります。
無事にping疎通失敗。
[ec2-user@ip-10-0-0-59 ~]$ ping 192.168.0.67 -c 3 PING 192.168.0.67 (192.168.0.67) 56(84) bytes of data. --- 192.168.0.67 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2115ms [ec2-user@ip-10-0-0-59 ~]$
以下のログが出力されました。
2024-02-09T14:27:36.000+09:00 6 TransitGateway [AWSアカウントID] tgw-0b3c56f918504bd66 tgw-attach-0ed66ac38ad74f63d [AWSアカウントID] - - - - - - - apne3-az2 - - 10.0.0.59 192.168.0.67 0 0 1 3 252 1707459042 1707459044 OK IPv4 3 0 0 0 0 ap-northeast-3 ingress - -
今までのログと比較すると、値が「-」のフィールドが増えたと思います。
送信先の情報が「-」となっていることから、送信先が見当たらないことが伺えますね。
このようにTransit Gateway内における通信のトラブルシューティングに役立ちそうです。
終わりに
つい先日まで4ヶ月に渡る研修を受けていたのですが、いつの間にかTransit Gatewayを構築できるようになっててビックリです。
この記事が誰かの参考になれば幸いです。ご一読ありがとうございました。
