この記事はネットワークのことをゆっくり解説していきます
その度合いは浅い(アサァイ!!!)のでご了承ください
今回はプロキシ(Proxy)のお話しです
自宅でインターネットに通信するときは利用する方は少ないかもしれませんが、簡単に言うと代理で通信してくれる機器です
プロキシは必ずサーバーってわけじゃなく、プロキシ機能があるネットワーク機器もあります
■概念ざっくり理解していこう編
会社でクライアントPCからインターネットへアクセスするのなら、無自覚で利用している場合が多いでしょう
知らず知らずのうちに利用していることだと思います
反対にプロキシを通さなければ、インターネットにアクセスできない環境も多いと思います
その仕組みをちょっと深堀しましょう
今回の内容はインターネット接続には必要になってくるプロキシの説明
プロキシってなんぞや?
プロキシとは、通信の中継役を果たすサーバーですカテゴリフィルタやURLフィルタを使用して、アクセス制御やセキュリティを強化します
そして、このプロキシ自体も様々な機能があるので、プロキシを通すことによって、それらの機能が利用できるようになります
クライアントPC側で参照するプロキシを設定したりします
また、インターネット通信が上手くいかないときは真っ先にプロキシが疑われます
プロキシの機能
プロキシは、大体次のような機能を持っていることがあります
これらの機能は製品によって違ったり、また利用シーンによって使用する/しないが変わったりします
こういう機能があるというのを覚えておきましょう
接続の代理:
プロキシはクライアントの代理としてインターネットなどにアクセスします
クライアントはプロキシにリクエストを送り、プロキシが代理として、目的のサイトにアクセスしてデータを受け取り、ブラウザに表示させます
URLフィルタリング:
プロキシの利用目的で一番多いのがURLフィルタリングだと思います
URLフィルタリングというのは、「このサイトはアクセスさせるけど、このサイトはアクセスさせない」というものです
プロキシのURLフィルタリングの処理の流れは「カテゴリ」と「URLフィルタ」とからなります
カテゴリフィルタとは
プロキシがアクセスしようとしているウェブサイトのカテゴリを調べ、禁止されているカテゴリの場合はアクセスをブロックします
URLフィルタとは
許可(または拒否)するWebサイト(URL)をフィルタリングすることです
ログ取得:
プロキシはクライアントのアクセスログを取得することができ、通信ログ収集に役立ちます
ログを見ることによって、不正アクセスの検出やトラブルシューティングが行えます
接続の高速化:
プロキシはキャッシュを使用して、同じコンテンツを複数回ダウンロードする必要を減らし、ネットワークの負荷を軽減します
リバースプロキシ:
外部クライアントからのリクエストを複数のWebサーバーに分散したり、代理として通信させたりします
クライアントの代理ではなく、サーバーの代理として、通常の使い方として逆なので、リバースプロキシと呼ばれます
プロキシはWebブラウザの代理ですが、リバースプロキシはWebサーバーの代理となります
パケット振り分け:
プロキシはトラフィックを適切なサーバーに振り分ける役割も担っています
これにより、負荷分散や高可用性を実現できます
デコード:
httpsで暗号化された通信のログはホスト部までしか解析できません、つまり、ディレクトリ部は暗号化されているので見れないということです
プロキシのデコード機能はhttpsで暗号化された通信を解析し、フィルタリングを行えるようにします
プロキシの設定方法
まず最初にプロキシの種類は2種類あって、「システム用」 「ユーザレベル」 で分かれています
システム用というのは、WinHTTP Proxyと呼ばれ、Windows Updateやライセンス認証などで利用されます
ユーザレベルというのはブラウザで利用され、ユーザごとに設定ができるものを指します
今回はユーザレベルのプロキシの説明となります
PCからプロキシに対して通信するので、PC側でプロキシ向け先の設定をします
自動プロキシ セットアップ
「スクリプトのアドレス」の部分に自動構成スクリプトのURLを記載します
これはPACと呼ばれるものを参照しまして、そのPACにはプロキシのアドレスや使用ポートなどの詳細設定が書かれています
手動プロキシ セットアップ
PACの代わりにこちらで明示的にプロキシの設定を記載します
つまり、PACを利用しない環境ではこちらになることが多いです
”次のエントリで始まるアドレス以外~”というのはプロキシ例外設定と呼ばれ、プロキシを通したくない宛先アドレス(IPアドレス、URL)を追加します
トラブルシューティング
詳細ケースはその環境に合ったものとなるので、あくまでも一般的な原因と切り分けを解説します
プロキシを介して通信がうまくいかないケースはざっくりと以下です
・明示的にサイトアクセスを許可していない
・認証関連
・セッション関連
・端末とプロキシの参照先DNSが違う場合
・アプリがプロキシの設定を認識しない
通信をするときに一番重要なのは、当然通信を成功させること
そしてセキュリティ面もそうだけど、どこを経由させて通信を成功するところも意識したい
その経由にプロキシがあるのであれば、以下の要件みたいなものは必ずある
・インターネット上の宛先へはプロキシを経由させる(代理サーバーとしての利用)
・通信ログを取得するため
よっぽどガチガチの要件以外は通信成功ありきでプロキシの存在はある(と思う)
なので、プロキシが理由で通信できないときは、まずは通信成功という目的を重点的に考えますが、その際「通信を成功させるために、この通信はプロキシを通さなくてよい」ということもあります
プロキシを経由させないという定義はいろいろありますが、以下の2つだと思います
1.通信経路的にプロキシを経由させない
2.プロキシを経由したとしても、プロキシ的な処理をさせない、またはその処理を減らす
ネットワーク構成的に「1.」は難しいことがありますけど、「2.」はプロキシの機能になってくるので
そういう機能をもったプロキシを導入するのもありかと思います
さて、プロキシの簡単なトラブルシューティングですが
様々なアプリ、特にWeb会議系のアプリなどは、プロキシ非推奨なものがあります
「1.」ができるのなら一番楽ですが
2の場合だと、プロキシの広く使われている機能としての一つに「認証」がありますけど
これがアプリと相性悪かったりします
なので、この認証を停止(認証除外)をするとアプリケーションが正常に通信できたりします
認証除外をするセキュリティリスクが気になるところですが
その理由としては、認証無しでプロキシが使用されてしまうことになります
その意味するところは勝手にプロキシを使われてインターネットに通信されたり
悪意あるユーザにプロキシを踏み台にされることです
でも、この認証機能って、製品によってですが
送信元IPアドレスや、通信先のURLのみ認証除外できたりが多いので、強くリスクを感じなくてもいいとは私は思います
(適切な設定且つ管理者に相談は必須ですが)
あとは、アプリによってはセッション数を多く使うものがありますので
プロキシで一人当たりのユーザのセッション数を絞るようなものだと通信が失敗するかもしれません
下図のBがその例ですけど、プロキシ通すとセッション数絞られるっていうケースは結構少ないかと思います
パソコンとプロキシの参照先DNSが違う場合も要注意です
DNSサーバーは個体によっては、名前解決にかかる時間が変わってきたりするので、通信できないときの切り分けの一つとして理解してください
アプリがプロキシの設定を認識しないで、直インターネットに向かうケースもあります
これは直インターネットへのアクセスを禁止している環境では、アクセスができないことを意味します
下図のBであれば、経路上にプロキシがあるので通信が普通にプロキシを通過しますが
Aの場合は難しいです、この場合アプリの通信がAですね
その場合、アプリ固有のプロキシ設定をする必要が出てきます
それが無理なら、その通信のみ直インターネットへアクセスできるよう設定を調整するしかありません
まとめ
proxyは英語で「代理」という意味
通常PCで仕事してても、こいつの存在意識しませんけど、たまには思い出してあげよう
管理する側としては、実は結構めんどくさかったりする(運用ポリシーによるけど)
■先回りの思考はもっておこう
今回のハウトゥですが、仕事する上で、できる人が実践している考え方としては
常に先を考えることです
言われたことだけをやっているのはイケていません
上司は何を言うのか、お客さんの次の要望は何なのか
先回りすることで、問題や課題を早く見つけることができます
これは効率的に対処でき、トラブル防止先につながります
あと、提案力も自然に上がります
失敗が多い人や思った通りにうまくいかない人は
少しでもこの考え方をしてみるのもいいでしょう
多分、すぐ変わります
今回はこれで終わりです
ネットワークは対象のレベルによって教えることが幅広くなってきますので
うっすい感じでお送りします
byebye ヾ(❛ᴗ˂ )⌒♥