web-dev-qa-db-ja.com

パッケージリポジトリのプロキシのベストプラクティス

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

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

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

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

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

私は当初リバースプロキシを調べていましたが、プロキシ内の302リダイレクトを内部で解決できるのはVarnishだけです。ただし、無料バージョンのVarnishはHTTPSバックエンドをサポートしていません。 Squidをフォワードプロキシオプションとして評価しています。

これは、エンタープライズネットワーク内で比較的よくある問題のように思われますが、他の人がこれを解決した方法の例を見つけるのに苦労しています。誰かが同様の何かを実装したり、そうするための最善の方法について考えたことはありますか？

ありがとう！

proxysquidvarnishpackage-managementrepository
16
Dave Smith

これには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/

5
Andrew

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

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

グッドプラクティスと、知っておくべきレッスンについて説明します。

公式の構成ファイルがわずかに変更されました（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）ではありません）。

クライアント構成-特定

一部のアプリケーションは、環境変数を無視するか、変数を設定する前にサービスとして実行されます（たとえば、debian apt）。

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

HTTPSプロキシ-接続

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

Dunnoはそのことについて多くのことを言いましたが、私はそれに関して何年も問題がありませんでした。うまくいきます。

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

透過プロキシに関する注意。 （つまり、プロキシは隠されており、クライアントのリクエストを途中で傍受します）。

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

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

ドメインとCDNのホワイトリスト

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

最新のWebサイトでは、あらゆる種類のドメインリダイレクトとCDNを使用できます。単一のドメインにすべてをきちんと入れるために人々が余計な努力をしなかった場合、それはACLを破ります。

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

キャッシング

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

個人的には、現時点ではクラウドで物事を実行しています。すべてのインスタンスは少なくとも100 Mbpsの接続を備えており、プロバイダーは自動的に検出される人気のあるもの（Debianなど）に対して独自のリポジトリを実行します。それは帯域幅を私があまり気にすることができなかった商品にしています。

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

ただし、すべての環境に同じ要件があるわけではありません。あなたはさらに一歩進んで、キャッシングを設定することができます。

プロキシで認証を要求することはありません

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

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

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

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

結論

よくある設定、よくある間違い、プロキシについて知っておくべきことを学びました。

学んだ教訓：

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

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

プロキシを設定するときは、基本に忠実に従うことをお勧めします。一般的に言えば、特定のフィルタリングを行わないプレーンプロキシは問題なく機能します。クライアントを（自動）構成することを忘れないでください。

5
user5994461

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

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

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

ただし、私の知る限り、これはルビジェム、PyPI、PECL、CPAN、またはnpmをサポートせず、きめ細かなACLを提供しません。

個人的には、Squidを調査することをお勧めします。最後にセットアップを実装する場合、あなたの経験を共有していただけませんか？私はそれがどうなるかにかなり興味があります。

4
gf_

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

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

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

2
natxo asenjo