Re: proxy に hosts は効かない
ばっくすとーりー
先日「proxy に hosts は効かない」という記事を書いたのですが、とある方から マサカリ🪓 をいただきまして、折角なので記事にしておきます。
なお、元の記事では Web Apps は Azure が提供するサービスの一つを指していましたが、この記事の中では一般的な Web アプリケーションのことを指しているかとは思います、たぶん。
proxyがある環境下でWeb Appsを開発する際の現実的な問題
はじめに
proxy に hosts は効かないの記事を読んだうえで、ツッコミどころ、補足したいところがあったのでつらつら書いていきます。
proxyの役目とは
本来proxyとは、クライアントが直接的に接続できない場合に、経由することで接続を可能とするためのサーバ、あるいはサービスのことを指します。proxyの定義においては取り扱うプロトコルの制限はないですが、もとの記事をはじめHTTP proxyを指していることが多いです。今回もHTTP proxyの話をしようと思います。
ちなみに、proxyにはforwardとreverseがあり、WebサーバやWAFを扱う人にはreverse proxyがおなじみだと思いますが、もとの記事でもこの記事でもproxy = forward proxyの意味で扱っています。
一方で今どき業務用PCなどが接続するproxyは、単に接続の肩代わりをするためにあるとは限りません。できることの一例としては以下の通りです。
- HTTPリクエストヘッダの編集(追加、削除)
- リクエスト・レスポンスに対するフィルタリング
- 業務用PCからの接続管理、ログ収集
これを踏まえ、もとの記事にある「外部公開されていないFQDNのWeb Appsへの接続」をどうすべきかを考えます。
安易にproxy除外をしてよいか
まず、proxyが名前解決をするせいで到達できないからといって、安易にproxyの除外設定を用いてしまうと、通信に失敗する・セキュリティリスクが高まるなどの可能性があり得ます。
例えば社内LANに設置された業務用PCに対し、外部接続のログ管理を徹底するために必ずproxyを通して外部通信をするよう設計されている場合、proxyの除外設定をしてもfirewallなどで遮断され通信できない場合があります。
また、リクエストやレスポンスをフィルタリングするセキュリティ要素を含むproxyの場合、それを利用しないことによるセキュリティリスクの増加は考えられます。(とはいえ、ご自身で構築中のWeb Appsへのアクセスにセキュリティリスクがどれくらいあるかは別問題ですが…)
proxyと名前解決の現実的な解決策
では、proxyを経由して開発中のWeb Appsにアクセスする場合を考えていきます。前提としてこの時Web Appsで本来設定されるべきFQDNはまだ外部公開されていません。
もとの記事にある通り、proxyを経由してのWebアクセスでは、宛先の名前解決はproxyで実施されます。つまり、外部公開されていないFQDNを指定してproxy経由でアクセスするには、proxyがどうにかそのFQDNとIPアドレスを紐づけられる必要があります。
proxyで実現する方法には大きく2つあります。
- proxyサーバのhostsファイルに、FQDNとIPアドレスの紐づけを定義する
- proxyサーバが参照するDNSサーバが、そのFQDNを解決できる
この2つの方法について、優劣があるかというと、場合によるかと思います。
そもそもproxyでは、DNSサーバへの問い合わせよりhostsファイルの内容が優先されます。今回想定するFQDNが現状別のものと紐づいている(同じFQDN・別のIPアドレスで新たなWeb Appsを構築しているなど)の場合であれば、hostsファイルで対応するのが適切でしょう。
一方で企業等の環境下において、proxyサーバのhostsファイルを書き換える、あるいはproxyサーバが参照するDNSサーバにレコードを追加するといった行為はルール次第では難しい場合もあります。どちらの方法がいいかはそのようなレイヤーで検討する必要もあるかもしれません。
そもそもproxy設定を変更できない場合もありえる
企業などによってはポリシーとしてproxy設定を配布するケースがあり、そのような場合利用者が任意のFQDNを除外設定できないことがあります。
そのような場合も社内での手続きといったレイヤーでの検討が必要になります。
Discussion