Paket depolarını proxy yapmak için en iyi uygulama


16

Kurumsal ağımda bir CentOS sunucuları koleksiyonum var. Güvenlik nedeniyle, sunucu için temel bir işlevsel gereksinim olmadıkça, çoğu sunucunun genel giden internet erişimi yoktur.

Paketleri güncellemem gerektiğinde bu bir sorun oluşturur. Yum depoları için, şu anda internetten gerekli tüm depoları yansıtıyorum ve aynaları intranet içinde mevcut hale getiriyorum. Her bir deponun kopyalarını beş ortamımızın her birinde saklıyorum: dev, QA, sahneleme ve iki üretim veri merkezi.

Şu anda dile özgü paket depoları için çözüm bulamıyorum. Sunucuların rubygems, PyPI, PECL, CPAN veya npm'den bir güncellemeye ihtiyacı olduğunda, paketleri almak için geçici giden internet erişimi edinmeleri gerekir. Yakutları ve PyPI'yi yansıtmaya başlamam istendi ve gerisi muhtemelen takip edecek.

Bütün bunlar tıknaz ve iyi çalışmıyor. Tam aynaların karmaşıklığını ve disk yükünü ortadan kaldırmak için tek bir ortamda tek bir önbellek proxy'si ve diğer ortamlarımda dört papatya dizimi proxy'si ile değiştirmek istiyorum. Bunlara ek olarak:

  • Bir ileri veya geri proxy olabilir; her paket yöneticisi bir yerel sunucu veya bir ters proxy olabilecek bir proxy sunucusunu veya özel bir havuz uç noktasını destekler.
  • Ayrıntılı erişim kontrolüne ihtiyaç duyar, böylece hangi istemci IP'lerinin hangi repo alanlarına bağlanabileceğini sınırlayabilirim.
  • Müşterilerin bilinmeyen alanlara yönlendirmeleri takip edebilmesi gerekir. Orijinal isteğiniz rubygems.org ile sınırlı olabilir, ancak bu sunucu rasgele bir CDN'ye 302 döndürürse, bunu takip edebilmeniz gerekir.
  • HTTPS arka uçlarını desteklemelidir. Diğer SSL sunucularının kimliğine bürünmek zorunda değilim, ancak bir HTTPS sitesini HTTP üzerinden yeniden gösterebilmeli veya farklı bir sertifika ile sonlandırıp yeniden şifreleyebilmeliyim.

Başlangıçta ters proxy'lere bakıyordum ve Vernik, proxy içindeki 302 yönlendirmelerini dahili olarak çözmeme izin verecek tek kişi gibi görünüyor. Ancak, Varnish'in ücretsiz sürümü HTTPS arka uçlarını desteklemez. Şimdi Squid'i ileri proxy seçeneği olarak değerlendiriyorum.

Bu, kurumsal ağlarda nispeten yaygın bir sorun olması gereken bir şey gibi görünüyor, ancak diğer insanların bunu nasıl çözdüğüne dair örnekler bulmakta zorlanıyorum. Herkes benzer bir şey uyguladı mı veya en iyi nasıl yapılacağına dair düşünceleri var mı?

Teşekkürler!

Yanıtlar:


5

Bunun için Squid kullanıyoruz; kalamar ile ilgili güzel bir şey, bir desen eşleşmesine dayalı nesnelerin ayrı ayrı sona ermesini oldukça kolay bir şekilde ayarlayabilmenizdir, bu da yum deposundan meta verilerin oldukça hızlı bir şekilde temizlenmesini sağlar. Bunu uygulayan yapılandırma:

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

Bu, proxy için kesin bir kullanım örneğidir . Normal bir proxy, ters proxy değil (yük dengeleyicileri).

En tanınmış, özgür ve açık kaynak kalamar . Neyse ki, bir tek ile kolayca kurulabilen apt-get install squid3ve tek bir dosya ile yapılandırılabilen birkaç iyi açık kaynaklı yazılımdan biridir /etc/squid3/squid.conf.

İyi uygulamaları ve bilinmesi gereken dersleri gözden geçireceğiz.

Resmi yapılandırma dosyası biraz değiştirildi (5000 yararsız yorum satırı kaldırıldı).

#       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

İstemci Yapılandırması - Ortam Değişkenleri

Bu iki ortam değişkenini tüm sistemlerde yapılandırın.

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

Çoğu http istemci kitaplığı (libcurl, httpclient, ...) ortam değişkenleri kullanılarak kendi kendine yapılandırılır. Uygulamaların çoğu ortak kütüphanelerden birini kullanıyor ve bu nedenle kullanıma hazır proxy'leri destekliyorlar (geliştiricilerin bunu bilmeleri gerekmeden).

Sözdiziminin katı olduğunu unutmayın:

  1. Değişken adı http_proxyçoğu Linux'ta küçük harf OLMALIDIR.
  2. Değişken değeri http(s)://BAŞLATMAMALIDIR (proxy protokolü http (s) DEĞİLDİR).

İstemci Yapılandırması - Özel

Bazı uygulamalar, ortam değişkenlerini yok sayar ve / veya değişkenler ayarlanmadan önce hizmet olarak çalıştırılır (örn. Debian apt).

Bu uygulamalar özel yapılandırma gerektirir (örn. /etc/apt.conf).

HTTPS Proxy'si - Bağlan

HTTPS proxy uygulaması tasarım tarafından tamamen desteklenir. Tarayıcı ile proxy arasında bir tür tünel oluşturan özel bir "CONNECT" yöntemi kullanır.

Bu konuda çok şey bilmiyorum ama yıllar içinde hiç sorun yaşamadım. Sadece çalışıyor.

HTTPS Özel Kasa - Şeffaf Proxy

Şeffaf proxy hakkında bir not. (örn. Proxy gizlidir ve istemcilerin isteklerini keser. ortadaki adam).

Şeffaf proxy'ler HTTPS'yi kırıyor. İstemci bir proxy olduğunu bilmiyor ve özel Connect yöntemini kullanmak için bir nedeni yok.

İstemci, kesilen doğrudan bir HTTPS bağlantısı deniyor. Müdahale tespit edilir ve her yere hatalar atılır. (HTTPS, ortadaki adam saldırılarını tespit etmek içindir).

Alan adı ve CDN beyaz listesi

Alan adı ve alt alan adı beyaz listesi kalamar tarafından tamamen desteklenir. Bununla birlikte, zaman zaman beklenmedik şekillerde başarısız olmak zorundadır.

Modern web siteleri her türlü etki alanı yönlendirmesine ve CDN'ye sahip olabilir. Bu, insanlar her şeyi tek bir alana düzgün bir şekilde koymak için fazladan yol kat etmediklerinde ACL'yi kıracaktır.

Bazen, çalıştırmadan önce ev sahibini aramak veya harici bağımlılıkları almak isteyen bir yükleyici veya paket olacaktır. Her seferinde başarısız olacak ve bu konuda yapabileceğiniz hiçbir şey yok.

Önbelleğe almak

Sağlanan yapılandırma dosyası her türlü önbelleğe almayı devre dışı bırakıyor. Eşeği sağlam kazığa bağlamak.

Şahsen, şu anda bulutta bir şeyler çalıştırıyorum, tüm örneklerin en az 100 Mbps bağlantısı var ve sağlayıcı otomatik olarak bulunan popüler şeyler (örneğin Debian) için kendi depolarını çalıştırıyor. Bu, bant genişliğini daha az umursamayacağım bir mal haline getirir.

Sorun gidermede beynimi eritecek tek bir önbellek hatasını deneyimlemekten ziyade önbelleği tamamen devre dışı bırakmayı tercih ederim. İnternetteki herkes tek başına önbellek başlıklarını ALAMAZ.

Yine de tüm ortamlar aynı gereksinimlere sahip değildir. Ekstra mil gidebilir ve önbellekleme yapılandırabilirsiniz.

ASLA proxy üzerinde kimlik doğrulaması gerekmez

İstemcilerden, tipik olarak LDAP hesaplarıyla parola kimlik doğrulaması yapılmasını gerektiren bir seçenek vardır. Evrendeki her tarayıcıyı ve her komut satırı aracını kıracaktır.

Proxy üzerinde kimlik doğrulaması yapmak istiyorsanız, yapmayın.

Yönetim kimlik doğrulaması istiyorsa, bunun mümkün olmadığını açıklayın.

Bir geliştiriciyseniz ve doğrudan interneti engelleyen ve proxy kimlik doğrulamasını zorlayan bir şirkete katıldıysanız, YAPABİLİRSİNİZ ÇALIŞIN.

Sonuç

Ortak yapılandırma, yaygın hatalar ve vekil sunucu hakkında bilinmesi gereken şeylerden geçtik.

Alınan ders:

  • Proxy (kalamar) için iyi bir açık kaynaklı yazılım var
  • Basit ve yapılandırması kolaydır (tek bir kısa dosya)
  • Tüm (isteğe bağlı) güvenlik önlemlerinin ödünleşimi vardır
  • En gelişmiş seçenekler bir şeyleri kıracak ve sizi rahatsız edecek
  • Şeffaf proxy'ler HTTPS'yi kırıyor
  • Proxy kimlik doğrulaması kötülüktür

Programlama ve sistem tasarımında her zaman olduğu gibi gereksinimleri ve beklentileri yönetmek çok önemlidir.

Proxy kurarken temel bilgilere bağlı kalmanızı tavsiye ederim. Genel olarak konuşursak, belirli bir filtrelemesiz düz bir proxy iyi çalışır ve sorun çıkarmaz. Sadece istemcileri yapılandırmayı (otomatik) hatırlamalıyım.


s / ortadaki adam / ortadaki adam / (S / E tek karakter düzenlemesine izin vermiyor)
Chen Levy

4

Bu, tüm görevlerinizi çözmez, ancak belki de yine de yardımcı olur. İsmine rağmen, apt-cacher-ng sadece Debian ve türevleriyle değil, aynı zamanda

önbellek proxy'si. Linux dağıtımcılarının paket dosyaları için, özellikle Debian (ve Debian tabanlı) dağıtımlar için uzmanlaşmıştır, ancak bunlarla sınırlı değildir.

Bunu sizinkine benzer (Debian tabanlı) bir ortamda üretimde kullanıyorum.

Ancak, AFAIK, bu rubygems, PyPI, PECL, CPAN veya npm'yi desteklemez ve granüler ACL'ler sağlamaz.

Şahsen, Squid'i araştırmanın iyi bir fikir olduğunu düşünüyorum. Sonunda bir kurulum uygularsanız, lütfen deneyimlerinizi paylaşır mısınız? Nasıl gittiğiyle oldukça ilgileniyorum.


2

benzer bir zorluk yaşadık ve yerel depolar ve anlık görüntü tabanlı bir depolama sistemi kullanarak çözdük. Temel olarak geliştirme deposunu güncelliyoruz, test için klonlayın, evreleme için ve son olarak üretim için klonlayın. Kullanılan disk miktarı bu şekilde sınırlıdır, ayrıca hepsi yavaş sata depolamasıdır ve sorun değildir.

İstemciler depo bilgilerini yapılandırma yönetimimizden alır, bu nedenle gerektiğinde geçiş yapmak kolaydır.

Kullanıcı aracısı dizeleri veya kaynak ips / maske kombinasyonları kullanarak ve belirli etki alanlarına erişimlerini kısıtlayarak proxy sunucusundaki ace'ları kullanarak istediğinizi elde edebilirsiniz, ancak bu sorunu yaparsanız, paketlerin / kitaplıkların farklı sürümlerinin olduğunu görüyorum. Bu nedenle, ana bilgisayarlardan biri cpan'a erişebiliyorsa ve istemci belirli bir sürümü kullanma talimatı vermedikçe xxx :: yyy modülünü talep ederse, en son cpan'dan (veya pypy veya rubygems) çekilir, bu zaten olan veya olmayabilir proxy'de önbelleğe alındı. Böylece aynı ortamda farklı sürümlerle karşılaşabilirsiniz. Yerel depoları kullanırsanız bu sorunla karşılaşmazsınız.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.