AWSのブラックボックスを暴く：ENIセカンダリIPとProxy ARPの深淵なる挙動
クラウドエンジニアの日常において、EC2インスタンスに複数のENI（Elastic Network Interface）をアタッチしたり、セカンダリプライベートIPを付与したりする作業は、もはや「日常茶飯事」だ。しかし、その内部でパケットがどのような魔法にかけられているのか、真に理解しているエンジニアはどれほどいるだろうか。
今回は、AWSの仮想ネットワーク層、とりわけ「Proxy ARP」が織りなすパケットの挙動と、それに付随するパフォーマンスチューニングの核心に迫る。
—
1. Proxy ARP：仮想ルーターが仕掛ける「優しい嘘」
オンプレミスの物理ネットワークであれば、ARP要求（Who has 10.0.1.5?）に対しては、そのIPを持つホストが直接応答する。しかし、AWSのVPC環境は物理的なL2セグメントではない。
AWSの仮想ルーター（VPC Router）は、ARPリクエストをインターセプトし、あたかもそのIPアドレスが直結されているかのように振る舞う。これがAWSにおけるProxy ARPの正体だ。
なぜセカンダリIPで苦しむのか
一つのENIに複数のIPを割り当てた際、Linuxカーネルのネットワークスタックは、デフォルトで最も適切なソースIPを選択しようとする（Source Address Selection）。ここで、意図しないENIやIPからパケットが送出され、セキュリティグループのルールや、アプリケーションのバインド設定と衝突するケースが後を絶たない。
特にKubernetesのCNI（VPC CNI）を利用している場合、PodsがNodeのENIからセカンダリIPを借り受ける仕組みとなっている。このとき、ARPの挙動を正しく制御しなければ、パケットはブラックホールに消えるか、あるいは予期せぬインターフェースから出ていくことになる。
—
2. カーネルレベルの防御とチューニング
ENIを複数持つ場合、Linuxのrp_filter（リバースパスフィルタリング）が最大の敵となる。これは、パケットの送信元IPが、そのパケットが到着したインターフェースでルーティング可能かどうかを検証する機能だ。
# /etc/sysctl.conf に以下の設定を投入する
# 複数ENI環境では strict mode (1) だとパケットがドロップされる可能性が高い
# 緩和設定 (2: loose mode) への変更を推奨する
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
# ARP応答の挙動を厳格に制御する
# 外部からのARP要求に対し、該当インターフェースがそのIPを保持している場合のみ応答する
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2この設定を行うことで、カーネルは「どのインターフェースからどのIPで応答すべきか」を正しく認識し、VPCの仮想ルーターと健全な対話が可能になる。
—
3. パフォーマンスの極致：TCPバッファとTLSハンドシェイクの最適化
大規模なマイクロサービス環境では、ENIの帯域制限（PPS: Packets Per Second）がボトルネックになりやすい。特にTLSハンドシェイクが頻発する環境では、RTT（Round Trip Time）の削減が正義だ。
TCPウィンドウサイズのチューニング
デフォルトのTCPバッファサイズは、現代の高速なNitro System上では小さすぎることが多い。以下のチューニングにより、スループットの改善が見込める。
# TCPウィンドウサイズの拡大
# 高速なネットワーク環境下でスループットを最大化する
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 接続の高速化: Fast Openの有効化
# TLSハンドシェイクと同時にデータを送信することで1往復分を削減する
net.ipv4.tcp_fastopen = 3—
4. セキュリティ専門家が見るべき「見えない脆弱性」
複数のENIを制御する際、最も注意すべきは「IPスプーフィング」に対するAWS側の保護機能だ。AWSはデフォルトでSource/Dest Checkを有効にしており、ENIに割り当てられていないIPアドレスからのパケットは問答無用でドロップする。
NATインスタンスやVPNゲートウェイのように、自身がルーターとして振る舞うインスタンスを構築する場合、このチェックを無効化しなければならない。
# AWS CLIによる制御
# NATインスタンス等でルーティングを行う際は、このチェックをオフにする必要がある
aws ec2 modify-network-interface-attribute \
--network-interface-id eni-xxxxxxxx \
--no-source-dest-checkただし、この設定を無効化するということは、インスタンス内部でのルーティングテーブル管理が完全にあなたの責任下に置かれることを意味する。iptablesやnftablesでの厳密な制御を怠れば、VPC内のセグメント間をまたぐ不正なパケットの踏み台にされかねない。
—
最後に：クラウドの「黒魔術」を味方につける
ENIとセカンダリIPの扱いは、単なる設定作業ではない。AWSの抽象化されたネットワーク層と、Linuxカーネルのネイティブなスタックをいかに調和させるかという、アーキテクトの腕の見せ所だ。
「なぜパケットが届かないのか」「なぜTCPコネクションが切断されるのか」。その答えは、常にtcpdumpの先にある。パケットを信じ、カーネルのログを読み解く。クラウドインフラの深淵を覗く勇気を持つ者だけが、極限のパフォーマンスと堅牢なセキュリティを両立できるのだ。
さあ、次はどのレイヤーを深掘りしようか。ネットワークの旅に終わりはない。
コメント