squid とファイアウオールを併用することで、外部の攻撃から内部ネットワークを保護することができるようになります。ファイアウオールでは、 squid を除いて全てのクライアントからの外部サービスアクセスを拒否するように設定することで、全ての Web 接続をプロキシ経由で行わせることができます。これにより、 squid で Web アクセスの全てを制御できるようになります。

ファイアウオールの設定内に DMZ の構成が含まれる場合、プロキシは DMZ 内で動作させるべきです。 26.6項 「透過型プロキシの設定」 では、 透過型 プロキシを実装するための手順を説明しています。この透過型プロキシの構成により、クライアント側ではプロキシに関する設定を行う必要がなくなりますので、設定をより簡単に済ませることができます。

複数の squid インスタンスを動作させて、お互いにオブジェクトを交換できるように設定することもできます。これによりシステム全体の負荷を軽減し、ローカルネットワーク内でオブジェクトの取得を完了させる機会を増やすことができます。また、キャッシュには階層構造を設定することもできます。これにより、オブジェクトへの要求を兄弟関係にあるキャッシュに転送したり、親キャッシュに転送したりすることができるようになります。これにより、ローカルネットワーク内の他のキャッシュからオブジェクトを提供するか、直接情報源から取得するかを効率的に選択することができるようになります。

キャッシュの階層構造を構築するにあたっては、適切なトポロジ選択が重要です。なぜなら、ネットワーク内のトラフィック量を減らすことが、プロキシキャッシュの目的の 1 つであるからです。巨大なネットワークの場合、それぞれのサブネット内にそれぞれプロキシサーバを設置して、それらは親プロキシサーバに接続して、親プロキシサーバからインターネットに直接アクセスするような構成が良いでしょう。

ここで行われる通信は、 UDP プロトコル上で動作する ICP (Internet Cache Protocol) で行われます。キャッシュ間のデータ転送は、 TCP をベースにした HTTP (HyperText Transmission Protocol) で行われます。

特定のオブジェクトを要求するにあたって、最も適切なサーバを選択する目的で、キャッシュは全ての兄弟関係のプロキシに対して、 ICP リクエストを送信します。 ICP リクエストを受け取ったプロキシは、 ICP レスポンスとしてそれらの要求に応答します。オブジェクトが見つかった場合は HIT を、見つからなかった場合は MISS を使用して応答します。

複数の HIT 応答が届いた場合、プロキシサーバは最も高速に応答したサーバや、最も近いサーバなどの判断基準で、特定のサーバを選択します。逆に、必要な応答が届かなかった場合、要求はそのまま親キャッシュに送信されます。

注記: squid でのオブジェクト重複の回避方法について

ネットワーク内の複数のキャッシュ間でオブジェクトの重複を防ぐため、 CARP (Cache Array Routing Protocol) や HTCP (HyperText Cache Protocol) などの他の ICP プロトコルを使用します。ネットワーク内で保持されるオブジェクトが増えれば増えるほど、必要なオブジェクトを見つける機会が増えることになります。

動的に生成されるページや TLS/SSL で暗号化されたコンテンツなど、ネットワーク内にある多くのオブジェクトは静的なものではありません。これらのオブジェクトは、アクセスが行われるたびに変化するものであることから、キャッシュが行われません。

また、キャッシュ内にオブジェクトを保持する期間を判断する目的で、オブジェクトには状態が割り当てられます。 Web やプロキシサーバでは、 「最終更新日時」 や 「期限切れ日時」 などの仕組みを用意することで、これらのオブジェクトに対して状態を付与できるようになっています。なお、オブジェクトに含まれるその他のヘッダ情報については、そのままキャッシュ内に保持されます。

キャッシュ内のオブジェクトは、ディスク領域の不足などを理由として置き換えられるのが一般的です。この処理を行うにあたっては、 LRU (Least Recently Used) などのアルゴリズムを使用します。これにより、最も長い時間使われていないオブジェクトは、キャッシュから消滅することを意味します。

squid で必要とされるメモリ量は、キャッシュ内のオブジェクトの数に依存して決まります。メモリはハードディスクや SSD より高速に動作するものであるため、 squid プロセスに対しては十分なメモリの割り当てが重要となります。メモリが不足してスワップディスクを使用してしまうと、システムの性能が劇的に下がる結果になります。

squid では、データの取得を高速化する目的で、キャッシュオブジェクトの参照と頻繁に要求されるオブジェクトについては、メインメモリ内に保持するようになっています。これに加えて、処理した全ての IP アドレスの一覧やドメイン名の正確なキャッシュ、そして最もよく要求されるオブジェクトやアクセス制御リスト、バッファなどについても、 squid はメモリ内に保持する必要があります。

squid はプロセッサのコア数の少ない (物理コア数で 4 〜 8 コア程度) 環境でも十分に動作するようチューニングされています。また、ハイパースレッディングなどの仮想的なコアでは、性能が十分に引き出せない場合があります。

複数の CPU コアを効率的に使用するため、異なるキャッシュデバイスに書き込むワーカースレッド数を多くする必要があります。既定では、マルチコアサポートが無効化されています。

小さなキャッシュの場合は、 HIT (つまり、オブジェクトが既に取得済みのものである) の確率が小さくなります。なぜなら、小さなキャッシュではすぐにオブジェクトで埋め尽くされてしまうため、頻繁に使用されるものであっても容易に廃棄されてしまうからです。たとえばキャッシュに 1 GB を割り当てていて、ユーザが 1 日あたり 10 MB 程度のアクセスしかしない環境であれば、キャッシュを埋め尽くすのに 100 日程度かかることになります。

キャッシュとして必要なサイズを判断するのに最も簡単な方法は、インターネット接続の最大転送速度から見積もる方法です。たとえば 1 Mbit/s のインターネット接続の場合、最大転送速度は 128 KB/s になります。キャッシュ内を 1 時間で埋め尽くすと仮定すると、必要なサイズは 460 MB になります。また、業務時間を 8 時間と仮定すると、 1 日あたり 3.6 GB になります。インターネット接続は一般に、最大まで使用することはありませんので、キャッシュとして使用するのはおおよそ 2 GB 程度で十分ということになります。そのため、この例では squid に対して 2 GB 程度のキャッシュを設定することで、 1 日分に相当するデータをキャッシュできることになります。

キャッシュ処理においては、速度が重要となります。そのため、この要素に対しては特別に配慮しておくことをお勧めします。ハードディスクや SSD の場合、このパラメータは ランダムシークタイム や ランダムリードパフォーマンス などとして示され、多くはミリ秒で示されます。 squid からハードディスクや SSD に書き込んだり、それらから読み込んだりするデータは小さいものであるため、データのスループットよりはシークタイムや読み込み性能のほうがより重要となります。

プロキシとして使用する場合、高速回転のハードディスクや SSD を使用しておくことが最適な選択となります。ハードディスクを使用する場合、複数の小さなハードディスクを使用して、それぞれにキャッシュディレクトリを設定することで、読み込み時間を削減することができます。

RAID システムを使用すると、速度を犠牲にして信頼性を増すことができますが、性能上の理由から、 (ソフトウエア) RAID5 やそれに類似の設定は避けておくことをお勧めします。

ほとんどの場合において、ファイルシステムの選択はそれほど重要ではありません。ただし、マウントオプションに noatime を指定することで、性能を改善することができます。これは、 squid では独自のタイムスタンプを保持しているため、ファイルシステム側でアクセス日時を管理する必要が無いためです。

squid を起動するには、下記のコマンドを実行します:

> sudo systemctl start squid

システムの起動時に squid を開始するように設定したい場合は、 systemctl enable squid のように実行して、サービスを有効化します。

squid が動作しているかどうかを確認するには、下記のコマンドを実行します:

ローカルシステム内で squid の機能をテストするには、下記のいずれかの方法を使用します:

ローカルシステムや他のシステムから squid 経由でインターネットにアクセスできるようにするには、設定ファイル /etc/squid/squid.conf 内にある http_access deny all を http_access allow all に変更してください。ただし、この設定を実施すると、 squid は誰からもアクセスできるようになってしまうことに注意してください。アクセスできるユーザを制限したい場合は、 ACL (Access Control List; アクセス制御リスト) を設定して行います。また、設定ファイルを変更した場合は、 squid を再読み込みさせるか、再起動しなければなりません。 ACL について、詳しくは 26.5.2項 「アクセス制御用オプション」 をお読みください。

squid が正しく開始できているにもかかわらず、しばらくして squid が停止してしまうような場合は、ネームサーバの設定が正しく行われていないか、 /var/run/netconfig/resolv.conf ファイルがそもそも存在していないことが考えられます。 squid では、開始時の問題を /var/log/squid/cache.log ファイル内に記録します。

squid を再読み込みさせるには、下記のいずれかを実施します:

squid を停止するには、下記のいずれかを実施します:

squid は、その停止時にクライアントとの接続を切断し、データをディスクに書き込む処理を行うため、最大で 30 秒程度の時間がかかります (/etc/squid/squid.conf 内の shutdown_lifetime オプションで設定することができます) 。

警告: squid の停止について

squid を停止させる際は、 kill や killall コマンドで停止させてはなりません。これを行ってしまうと、キャッシュデータを壊してしまう可能性があります。この場合、 squid を再度開始できるようにするには、キャッシュデータを削除しなければならなくなります。

システムから squid を削除しても、キャッシュ構造やログファイルについては削除が行われません。これらを削除するには、 /var/cache/squid ディレクトリを手作業で削除してください。

たとえ自分自身でドメインを所有していなくても、ローカルで DNS サーバを構築しておくことには意味があります。ローカルの DNS サーバは、キャッシュ専用のネームサーバとして動作させることで、特別な設定を行わなくてもルートネームサーバへの DNS 要求ができるようになります (詳しくは 19.4項 「BIND ネームサーバの起動」 をお読みください) 。このようなローカルの DNS サーバは、インターネットの接続にあたって動的に DNS サーバの設定を取得しているのか、静的に取得しているのかによって、やるべき作業が異なる点にも注意してください。

ヒント: DNS とファイアウオールについて

ファイアウオールを動作させている場合は、 DNS の要求を通すことができるように設定してください。

下記には、 squid の設定オプションのうち主なものを一覧で示しています。下記は全ての設定を網羅しているわけではありません。 squid パッケージ内には、全てのオプションを簡易に説明した文書が用意されています。詳しくは /etc/squid/squid.conf.documented ファイルをお読みください。

squid では アクセス制御リスト (ACL; Access Control List) を利用してプロキシサーバへのアクセスを制御します。 ACL は上から順に処理されるルールを一覧で指定する形を取るほか、指定する前に定義を行う必要もあります。また、既定の ACL である all と localhost については、定義せずに利用することができます。しかしながら、 ACL の設定だけでは何も効果がありません。対応する http_access ルールなどを設定することではじめて効果があります。

acl オプションの書式は下記のとおりです:

acl ACL_名 種類 データ

それぞれの項目の意味は下記のとおりです:

YaST の squid モジュールでルールを追加する場合は、モジュールを開いて アクセス制御 タブを選択します。あとは ACL グループの一覧から 追加 ボタンを押して、ルールの名前と種類、パラメータを指定します。

ACL ルールに関するより詳しい説明については、 https://www.squid-cache.org/Versions/v3/3.5/cfgman/acl.html にある squid のドキュメンテーションをお読みください。

acl mysurfers srcdomain .example.com 1
acl teachers src 192.168.1.0/255.255.255.0 2
acl students src 192.168.7.0-192.168.9.0/255.255.255.0 3
acl lunch time MTWHF 12:00-15:00 4