「インターネットに出られない」という孤独：プライベートサブネットでのパッケージ管理と戦うための処方箋
SREとして現場を走り回っていると、よく耳にする悲鳴があります。「プライベートサブネットに入れたインスタンスの yum update が通らない」「セキュリティ要件でインターネットへのフルアクセスは禁止されているが、ライブラリだけは取りに行きたい」。
これ、クラウドインフラを触るエンジニアが必ず一度は通る「通過儀礼」のようなものですよね。今回は、教科書的な構成を一段掘り下げ、NATゲートウェイ（NATGW）を介した通信でどうやって「安全」と「利便性」を両立させるか、その泥臭い現場の知見を共有します。
—
なぜ、プライベートサブネットは「孤島」なのか
まず前提を共有しましょう。プライベートサブネットとは、ルートテーブルにインターネットゲートウェイ（IGW）へのルートを持たないセグメントです。ここから外に出る唯一の手段が NATGW です。
パケットの視点で言えば、プライベートインスタンスから出たパケットは、NATGWで送信元IPアドレスが「NATGWのパブリックIP」に書き換えられ（SNAT）、インターネットへ放流されます。しかし、ここで問題になるのが「ホワイトリスティング（IP制限）」です。
セキュリティポリシーが厳しい環境では、「特定のドメイン以外への通信は遮断せよ」というお達しが出ます。しかし、パッケージリポジトリ（archive.ubuntu.com や amazonlinux.amazonaws.com など）は、CDN（Content Delivery Network）越しに配信されており、背後のIPアドレスは頻繁に変わります。IPで制御しようとすると、翌日には通信が死ぬという悪夢が待っています。
—
現場で通用する「ホワイトリスティング」の最適解
IPベースの制限が現実的でないなら、どうすべきか。結論から言うと、「FQDNベースでの制御」が正攻法です。
1. 透過的プロキシ（Squid等）の導入
NATGWとは別に、特定のドメインのみを通過させる「フォワードプロキシ」を構築します。インスタンス側の yum や apt の設定で proxy を指定することで、通信を制御します。
2. VPCエンドポイント（Interface Endpoint）の活用（AWSの場合）
AWS環境であれば、これが最強の解決策です。S3やECR、そしてAmazon Linuxのリポジトリなどを、インターネットに出ることなくVPC内部のプライベートIPで完結させることができます。NATGWを通る必要すらありません。
—
実践：プロキシ経由でパッケージマネージャーを動かす
もし、どうしてもNATGWを通さざるを得ない、あるいは社内プロキシを介する必要がある場合、設定は以下のようになります。
Yum（RHEL/CentOS系）の設定
/etc/yum.conf にプロキシ情報を追記します。
[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
# ここにプロキシサーバーの情報を追記します
proxy=http://proxy.internal.example.com:8080
# 必要であれば認証情報も
proxy_username=myuser
proxy_password=mypasswordApt（Debian/Ubuntu系）の設定
/etc/apt/apt.conf.d/proxy.conf を作成（または編集）します。
# HTTP/HTTPSそれぞれのプロキシを指定
Acquire::http::Proxy "http://proxy.internal.example.com:8080/";
Acquire::https::Proxy "http://proxy.internal.example.com:8080/";—
デバッグ：なぜ通信が通らないのか？
「設定したはずなのに動かない！」という時、私はまず以下の手順でパケットの迷子を確認します。
1. ルートテーブルの確認
インスタンスが存在するサブネットのルートテーブルに、0.0.0.0/0 がNATGWに向いているか確認します。これがないと、パケットは最初の一歩すら踏み出せません。
2. curl による疎通テスト
curl は強力なデバッグツールです。-v（verbose）オプションで、ハンドシェイクのどこで止まっているかを確認しましょう。
# プロキシを通した通信確認
curl -v -x http://proxy.internal.example.com:8080 http://archive.ubuntu.com/ubuntu/ここで 403 Forbidden が返るならプロキシ側でのACLの問題、Connection Timeout ならNATGWのルートやセキュリティグループ（SG）の問題である可能性が極めて高いです。
3. セキュリティグループ（SG）の確認
NATGW自体のSGだけでなく、「NATGWがあるサブネット」のネットワークACL（NACL）を疑ってください。特に、エフェメラルポート（1024-65535）の戻り通信が許可されていないケースは、新人SREが必ずハマる落とし穴です。
—
最後に：クラウド時代のインフラ設計思想
かつてネットワークエンジニアは物理ルーターのコンソールと向き合っていましたが、今はコードと設定ファイルがネットワークを作ります。
「インターネット非接続」を守ることは大切ですが、そこに固執しすぎてOSのパッチ適用が遅れ、脆弱性を放置しては本末転倒です。「信頼できるプロキシを通す」か「VPCエンドポイントで通信を閉じる」か。この二択を使い分け、環境に応じた「スマートな閉域網」を設計してください。
インフラは、ただ動くだけでなく、運用しやすく、かつ論理的に説明できる状態であること。これがSREの美学です。現場のトラブルで迷った時は、まずはパケットのフローを脳内で図解するところから始めてみてください。きっと出口は見つかります。
コメント