企業ネットワークにCentOSサーバーのコレクションがあります。セキュリティ上の理由から、ほとんどのサーバーは、サーバーのコア機能要件でない限り、一般的なアウトバウンドインターネットアクセスを持ちません。

これは、パッケージを更新する必要があるときに課題を作成します。yumリポジトリについては、現在、インターネットから必要なすべてのリポジトリをミラーリングし、ミラーをイントラネット内で利用できるようにします。開発、QA、ステージング、2つの本番データセンターの5つの環境のそれぞれに、各リポジトリのコピーを保持しています。

現在、言語固有のパッケージリポジトリについては解決していません。サーバーがrubygems、PyPI、PECL、CPAN、またはnpmからの更新を必要とする場合、サーバーはパッケージを取得するために一時的なアウトバウンドインターネットアクセスを取得する必要があります。私はrubygemsとPyPIのミラーリングを開始するように求められましたが、残りはおそらく続くでしょう。

これらはすべて不格好で、うまく機能しません。完全なミラーの複雑さとディスクオーバーヘッドを排除するために、ある環境では単一のキャッシングプロキシに置き換え、他の環境では4つのデイジーチェーンプロキシに置き換えたいと思います。さらに：

• フォワードプロキシまたはリバースプロキシのいずれかです。各パッケージマネージャーは、プロキシサーバーまたはカスタムリポジトリエンドポイントをサポートします。これは、ローカルミラーまたはリバースプロキシのいずれかです。
• きめ細かいアクセス制御が必要なので、どのクライアントIPがどのレポドメインに接続できるかを制限できます。
• クライアントは、不明なドメインへのリダイレクトを追跡できる必要があります。元のリクエストはrubygems.orgに限定される場合がありますが、そのサーバーがランダムなCDNに302を返す場合、それに従うことができるはずです。
• HTTPSバックエンドをサポートする必要があります。他のSSLサーバーを偽装する必要は必ずしもありませんが、HTTPS経由でHTTPSサイトを再公開したり、別の証明書で終了して再暗号化できる必要があります。

最初は逆プロキシを見ていたが、プロキシ内で302リダイレクトを内部的に解決できるのはVarnishだけだと思われる。ただし、無料版のVarnishはHTTPSバックエンドをサポートしていません。現在、Squidをフォワードプロキシオプションとして評価しています。

これは企業ネットワーク内で比較的一般的な問題になるはずのように思えますが、他の人がこれをどのように解決したかの例を見つけるのに苦労しています。誰かが同様の何かを実装しましたか、それを行うための最善の方法について考えを持っていますか？

ありがとう！

これにはSquidを使用します。squidの良い点は、パターンマッチに基づいてオブジェクトの個々の有効期限をかなり簡単に設定できることです。これにより、yumリポジトリからのメタデータをかなり迅速に削除できます。これを実装する構成：

refresh_pattern (Release|Packages(.gz)*)$      0       20%     2880
refresh_pattern (\.xml|xml\.gz)$      0       20%     2880
refresh_pattern ((sqlite.bz2)*)$      0       20%     2880
refresh_pattern (\.deb|\.udeb)$   1296000 100% 1296000
refresh_pattern (\.rpm|\.srpm)$   1296000 100% 1296000
refresh_pattern .        0    20%    4320

http://www.squid-cache.org/Doc/config/refresh_pattern/

これがプロキシの決定的なユースケースです。リバースプロキシ（別名ロードバランサー）ではなく、通常のプロキシ。

最もよく知られている無料のオープンソースはsquidです。幸いなことに、これは単一で簡単にインストールできapt-get install squid3、単一のファイルで構成できる数少ない優れたオープンソースソフトウェアの1つです/etc/squid3/squid.conf。

グッドプラクティスと既知の教訓について説明します。

公式の構成ファイルがわずかに変更されました（5000の役に立たないコメント行が削除されました）。

#       WELCOME TO SQUID 3.4.8
#       ----------------------------
#
#       This is the documentation for the Squid configuration file.
#       This documentation can also be found online at:
#               http://www.squid-cache.org/Doc/config/
#
#       You may wish to look at the Squid home page and wiki for the
#       FAQ and other documentation:
#               http://www.squid-cache.org/
#               http://wiki.squid-cache.org/SquidFaq
#               http://wiki.squid-cache.org/ConfigExamples
#

###########################################################
# ACL
###########################################################

acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 1025-65535  # unregistered ports

acl CONNECT method CONNECT

#####################################################
# Recommended minimum Access Permission configuration
#####################################################
# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

#####################################################
# ACL
#####################################################

# access is limited to our subnets
acl mycompany_net   src 10.0.0.0/8

# access is limited to whitelisted domains
# ".example.com" includes all subdomains of example.com
acl repo_domain dstdomain .keyserver.ubuntu.com
acl repo_domain dstdomain .debian.org
acl repo_domain dstdomain .python.org

# clients come from a known subnet AND go to a known domain
http_access allow repo_domain mycompany_net

# And finally deny all other access to this proxy
http_access deny all

#####################################################
# Other
#####################################################

# default proxy port is 3128
http_port 0.0.0.0:3128

# don't forward internal private IP addresses
forwarded_for off

# disable ALL caching
# bandwidth is cheap. debugging cache related bugs is expensive.
cache deny all

# logs
# Note: not sure if squid configures logrotate or not
access_log daemon:/var/log/squid3/access.log squid
access_log syslog:squid.INFO squid


# leave coredumps in the first cache dir
coredump_dir /var/spool/squid3

# force immediaty expiry of items in the cache.
# caching is disabled. This setting is set as an additional precaution.
refresh_pattern .               0       0%      0

クライアント構成-環境変数

すべてのシステムでこれら2つの環境変数を構成します。

http_proxy=squid.internal.mycompany.com:3128
https_proxy=squid.internal.mycompany.com:3128

ほとんどのhttpクライアントライブラリ（libcurl、httpclientなど）は、環境変数を使用して自己構成します。ほとんどのアプリケーションは、一般的なライブラリの1つを使用しているため、すぐにプロキシを使用できます（開発者がそれらを使用することを必ずしも認識していません）。

構文は厳密であることに注意してください。

1. http_proxyほとんどのLinuxでは、変数名は小文字でなければなりません。
2. 変数値は、http(s)://（プロキシプロトコルはhttp（s）ではありません）で始まってはなりません（MUST NOT ）。

クライアント構成-特定

環境変数を無視しているアプリケーションや、変数を設定する前にサービスとして実行されているアプリケーションもあります（例：debian apt）。

これらのアプリケーションには特別な設定が必要です（例：）/etc/apt.conf。

HTTPSプロキシ-接続

HTTPSプロキシは、設計により完全にサポートされています。ブラウザとプロキシ間に何らかのトンネルを確立する特別な「CONNECT」メソッドを使用します。

ダンノはそのことについて多くを知っていますが、私は何年もそれに関して問題を抱えたことはありません。それはただ動作します。

HTTPS特殊ケース-透過プロキシ

透過プロキシに関する注意。（つまり、プロキシは非表示であり、クライアントのリクエストを傍受します。中間者）。

透過プロキシはHTTPSを破壊しています。クライアントはプロキシがあることを知らず、特別なConnectメソッドを使用する理由はありません。

クライアントは、直接HTTPS接続を試みます...これはインターセプトされます。傍受が検出され、あらゆる場所でエラーがスローされます。（HTTPSは中間者攻撃を検出するためのものです）。

ドメインおよびCDNホワイトリスト

ドメインおよびサブドメインのホワイトリストは、Squidによって完全にサポートされています。それにもかかわらず、それは時々予期しない方法で失敗するはずです。

最新のWebサイトでは、あらゆる種類のドメインリダイレクトとCDNを使用できます。人々が単一のドメインにすべてをきちんと配置するために余分な距離を移動しなかった場合、ACLが壊れます。

実行する前にホームシップを呼び出したり、外部の依存関係を取得したりするインストーラーまたはパッケージが存在する場合があります。毎回失敗し、あなたがそれに対してできることは何もありません。

キャッシング

提供された構成ファイルは、すべての形式のキャッシュを無効にします。転ばぬ先の杖。

個人的には、現在クラウドで物事を実行しています。すべてのインスタンスは少なくとも100 Mbpsの接続を持ち、プロバイダーは自動的に発見される人気のあるもの（例えばDebian）の独自のリポジトリを実行します。そのため、帯域幅はあまり気にすることのできない商品になります。

トラブルシューティングで頭を悩ます単一のキャッシングバグを経験するよりも、キャッシングを完全に無効にします。インターネット上のすべての人がキャッシングヘッダーを正しく取得することはできません。

ただし、すべての環境に同じ要件があるわけではありません。余分な距離を移動して、キャッシュを構成できます。

決してプロキシで認証を必要としない

通常はLDAPアカウントを使用して、クライアントからのパスワード認証を要求するオプションがあります。それは、宇宙のすべてのブラウザとすべてのコマンドラインツールを破壊します。

プロキシで認証を行いたい場合は、しないでください。

管理者が認証を必要としている場合、それが不可能であることを説明します。

あなたが開発者で、直接インターネットをブロックし、プロキシ認証を強制している会社に参加したばかりの場合は、できる限り逃げましょう。

結論

一般的な設定、よくある間違い、プロキシについて知っておくべきことを経験しました。

学んだ教訓：

• プロキシ用の優れたオープンソースソフトウェアがあります（squid）
• 構成が簡単で簡単です（単一の短いファイル）
• すべての（オプションの）セキュリティ対策にはトレードオフがあります
• 最も高度なオプションは、物事を壊し、あなたを悩ませるために戻ってくる
• 透過プロキシがHTTPSを破壊している
• プロキシ認証は悪です

プログラミングとシステム設計ではいつものように、要件と期待を管理することが重要です。

プロキシを設定するときは基本に固執することをお勧めします。一般的に、特定のフィルタリングのないプレーンプロキシは問題なく機能し、問題はありません。クライアントを（自動）設定することを忘れないでください。

これはすべてのタスクを解決するわけではありませんが、おそらくこれはまだ役立つでしょう。名前にもかかわらず、apt-cacher-ngはDebianとその派生物でしか動作せず、

キャッシングプロキシ。主にDebian（およびDebianベース）ディストリビューション向けのLinuxディストリビューターからのパッケージファイルに特化していますが、これらに限定されません。

私はあなたのような似たような（Debianベースの）環境で本番環境でこれを使用しています。

ただし、知る限り、これはrubygems、PyPI、PECL、CPAN、またはnpmをサポートせず、詳細なACLを提供しません。

個人的には、Squidを調査するのは良い考えだと思います。最後にセットアップを実装する場合、あなたの経験を共有してもらえますか？私はそれがどうなるかに非常に興味があります。

同様の課題があり、ローカルリポジトリとスナップショットベースのストレージシステムを使用して解決しました。基本的に、開発リポジトリを更新し、テスト用に複製し、ステージング用に複製し、最終的に本番用に複製します。使用されるディスクの量はそのように制限されており、それに加えてすべての遅いSATAストレージであり、それで問題ありません。

クライアントは構成管理からリポジトリ情報を取得するため、必要に応じて切り替えが簡単になります。

プロキシサーバーでaceを使用して、ユーザーエージェント文字列またはソースIP /マスクの組み合わせを使用し、特定のドメインへのアクセスを制限することで目的を達成できますが、その1つの問題を確認すると、異なるバージョンのパッケージ/ライブラリの問題が発生します。したがって、ホストの1つがcpanにアクセスし、モジュールxxx :: yyyを要求する場合、クライアントが特定のバージョンの使用を指示しない限り、cpan（またはpypyまたはrubygems）から最新のものをプルします。プロキシにキャッシュされます。そのため、同じ環境で異なるバージョンになる可能性があります。ローカルリポジトリを使用する場合、その問題は発生しません。