リバースプロキシとは？DNSとウェブの実践ガイド

リバースプロキシとは、1台以上のバックエンドサーバーに代わってリクエストを受け取り、適切な宛先に転送するサーバーです。訪問者から見ると、プロキシが公開されたエンドポイントであることが多く、ブラウザーがアプリケーションサーバーに直接接続することはありません。リバースプロキシは、HTTPSの終端、ホスト名やパスによるリクエストのルーティング、トラフィックの分散、レスポンスのキャッシュ、コンテンツの圧縮、セキュリティ制御の適用を行えます。DNSは通常、公開ホスト名を、プロキシ、またはその前段にあるプロバイダー管理のアドレスに向けます。そのうえで、プロキシが自身のルーティング設定を使って、上流のアプリケーションに到達します。

リバースプロキシとフォワードプロキシの違い

フォワードプロキシはクライアントのために動きます。クライアントは、ポリシー、プライバシー、ネットワークアクセスなどの理由で、それを経由して外部のサービスにリクエストを送ります。リバースプロキシはサーバーのために動きます。外部のクライアントがそれに接続し、リバースプロキシがバックエンドのサービスにリクエストを転送します。そのため、「プロキシ」という言葉だけでは曖昧です。ウェブサイトのアーキテクチャーでは、リバースプロキシが通常、公開されたサービスのエンドポイントを担い、バックエンドのプールの詳細を隠します。同じインフラ上で複数のドメインをルーティングしたり、異なるパスを異なるアプリケーションに振り分けたりしながら、公開の接続ポイントを1つに保てます。

DNSとリバースプロキシは、接続の異なる部分を解決します。DNSは、ホスト名を公開アドレスやエイリアスに対応付けます。クライアントが接続した後、プロキシは、HTTPのホスト情報、TLSのサーバー名表示（SNI）、そして自身の設定を使って、正しいサービスを選びます。ドメインは問題なく動くのに、IPアドレスだけでアクセスするとデフォルトのページや証明書の警告が表示されることがあるのは、このためです。リクエストに、想定されるホスト名の文脈が含まれていない可能性があります。同様に、DNSを変更しても、対応するプロキシのルートが自動的に作られたり、証明書が発行されたりはしません。両方の層で、ホスト名と宛先が一致している必要があります。

プロキシが障害の一部になる、よくあるパターン

ドメインが正しく名前解決されていても、リバースプロキシが停止した上流を指していたり、間違ったポートを使っていたり、配信を設定していないホスト名を拒否したりすることがあります。エッジに有効な証明書がない場合や、暗号化された上流の設定が間違っている場合は、TLSの失敗が起こり得ます。バックエンドが過負荷になっていたり到達不能だったりすると、プロキシがタイムアウトを返すこともあります。逆に、DNSがクライアントを間違ったプロキシのアドレスに向けていると、正常なアプリケーションが利用できないように見えることもあります。まずDNSの答えを記録し、次にHTTPの応答、TLS接続、プロキシのログ、バックエンドの健全性を、順に調べてください。

• DNSが、意図した公開プロキシのエンドポイントを指していることを確認する。
• プロキシに、そのドメインのホストルールと、正常な上流があることを確認する。
• HTTPSが失敗する場合は、エッジと上流の両方のTLS設定を確認する。
• プロキシのログを使って、ルーティングのエラーとアプリケーションのエラーを区別する。
• IPの検索で、バックエンドサーバーが分かると思い込まない。

セキュリティと運用上の境界

リバースプロキシは、バックエンドのサービスが直接さらされる度合いを減らせますが、アクセスルールが設定され、維持されていなければ、自動的にセキュリティの境界になるわけではありません。アーキテクチャーが許す限り、オリジンは、意図した経路からのトラフィックだけを受け入れるべきです。管理用のインターフェースは、適切な認証なしに、公開のルートに置いてはいけません。プロキシのソフトウェアにはパッチを当て、管理アクセスを制限し、転送されたヘッダーを検証してください。プロキシは、クライアントと上流の情報を解釈する、信頼された存在になるからです。DNS、プロキシのルール、証明書、バックエンドをどのチームが所有しているかを文書化しておけば、各グループが別の層に責任があると考えて、インシデント対応が止まってしまうことを防げます。

公開されたエッジとバックエンドの関係については、オリジンサーバーとはをお読みください。世界規模のプロキシネットワークについては、CDNがDNSを使ってトラフィックをルーティングする仕組みをご覧ください。公開のドメインからIPを調べるチェックでは、DNSが示すアドレスを確認できますが、リバースプロキシのルートとアプリケーションの健全性には、それぞれ運用上のチェックが必要です。これらの責任を分けて考えれば、デバッグがより正確になり、アドレスの結果が、インフラ全体の診断だと取り違えられることもなくなります。

プロキシのルールの所有者を明確にする

リバースプロキシは重要な引き継ぎ地点にあるため、DNS、ホストのルーティング、証明書、上流の定義、アクセスポリシーを、誰が所有しているかを記録しておいてください。ある層では変更が正しくても、別の層が更新されていないために失敗することがあります。DNSはプロキシを指しているのに、プロキシにバーチャルホストがない。ルートはあるが、証明書が別の名前のものである。上流は正常だが、ファイアウォールがプロキシのサブネットをブロックしている、といった具合です。シンプルな経路図と、本番の各ホスト名に対する、正常と分かっているリクエストを残しておきましょう。インシデントの際は、同じリクエストのタイムスタンプや相関IDを使って、公開DNSの答え、プロキシのアクセスログ、上流の健全性、アプリケーションのログを比較します。