Saya memiliki koleksi server CentOS di jaringan perusahaan saya. Untuk alasan keamanan, sebagian besar server tidak memiliki akses internet keluar umum kecuali itu adalah persyaratan fungsional inti untuk server.

Ini menciptakan tantangan ketika saya perlu memperbarui paket. Untuk repositori yum, saat ini saya mirror semua repo yang dibutuhkan dari internet, dan membuat mirror tersedia di dalam intranet. Saya menyimpan salinan dari masing-masing repo di masing-masing dari lima lingkungan kami: dev, QA, pementasan, dan dua pusat data produksi.

Saat ini saya tidak menyelesaikan untuk repo paket khusus bahasa. Ketika server memerlukan pembaruan dari rubygems, PyPI, PECL, CPAN atau npm, mereka harus mendapatkan akses internet keluar sementara untuk mengambil paket. Saya diminta untuk mulai mirroring rubygems dan PyPI, dan sisanya mungkin akan mengikuti.

Semua ini kikuk dan tidak berfungsi dengan baik. Saya ingin menggantinya dengan satu caching proxy di satu lingkungan dan empat proksi daisy-chain di lingkungan saya yang lain, untuk menghilangkan kompleksitas dan overhead disk dari mirror penuh. Selain itu:

• Ini bisa berupa proxy maju atau mundur; setiap manajer paket mendukung server proxy atau titik akhir repositori khusus, yang bisa berupa mirror lokal atau proxy terbalik.
• Perlu kontrol akses granular, jadi saya dapat membatasi IP klien mana yang dapat terhubung ke domain repo.
• Klien harus dapat mengikuti arahan ke domain yang tidak dikenal. Permintaan awal Anda mungkin terbatas pada rubygems.org, tetapi jika server itu mengembalikan 302 ke CDN acak, Anda harus dapat mengikutinya.
• Seharusnya mendukung backt HTTPS. Saya tidak perlu meniru server SSL lain, tetapi saya harus dapat mengekspos ulang situs HTTPS melalui HTTP, atau mengakhiri dan mengenkripsi ulang dengan sertifikat yang berbeda.

Saya awalnya melihat proksi terbalik, dan Varnish tampaknya menjadi satu-satunya yang akan memungkinkan saya untuk menyelesaikan secara internal 302 pengalihan dalam proxy. Namun, versi gratis Varnish tidak mendukung backt HTTPS. Saya sekarang mengevaluasi Squid sebagai opsi proxy kedepan.

Ini sepertinya sesuatu yang seharusnya menjadi masalah yang relatif umum dalam jaringan perusahaan, tetapi saya mengalami kesulitan menemukan contoh bagaimana orang lain telah memecahkan ini. Adakah yang mengimplementasikan sesuatu yang serupa atau memiliki pemikiran tentang cara terbaik untuk melakukannya?

Terima kasih!

Kami menggunakan Squid untuk ini; hal yang menyenangkan tentang cumi-cumi adalah Anda dapat mengatur waktu kedaluwarsa masing-masing objek berdasarkan pola yang cocok, cukup mudah, yang memungkinkan metadata dari yum repo dibersihkan dengan cukup cepat. Konfigurasi yang kami miliki yang mengimplementasikan ini:

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/

Itu kasus penggunaan yang pasti untuk proxy . Proxy normal, bukan proxy terbalik (alias load balancers).

Yang paling terkenal dan gratis dan open-source adalah cumi-cumi . Untungnya ini adalah salah satu dari beberapa perangkat lunak open-source yang bagus yang dapat dengan mudah diinstal dengan satu apt-get install squid3dan dikonfigurasikan dengan satu file /etc/squid3/squid.conf.

Kami akan membahas praktik yang baik dan pelajaran untuk diketahui.

File konfigurasi resmi sedikit diubah (5000 baris komentar yang tidak berguna dihapus).

#       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

Konfigurasi Klien - Variabel Lingkungan

Konfigurasikan kedua variabel lingkungan ini di semua sistem.

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

Sebagian besar pustaka klien http (libcurl, httpclient, ...) mengkonfigurasi sendiri menggunakan variabel lingkungan. Sebagian besar aplikasi menggunakan salah satu perpustakaan umum dan dengan demikian mendukung proksi out-of-the-box (tanpa dev mengetahui bahwa mereka melakukannya).

Perhatikan bahwa sintaksisnya ketat:

1. Nama variabel http_proxyHARUS huruf kecil di sebagian besar Linux.
2. Nilai variabel TIDAK HARUS dimulai dengan http(s)://(protokol proxy BUKAN http).

Konfigurasi Klien - Khusus

Beberapa aplikasi mengabaikan variabel lingkungan dan / atau dijalankan sebagai layanan sebelum variabel dapat diatur (misalnya debian apt).

Aplikasi ini akan memerlukan konfigurasi khusus (mis /etc/apt.conf.).

Proxying HTTPS - Hubungkan

Proxy HTTPS sepenuhnya didukung oleh desain. Ini menggunakan metode "CONNECT" khusus yang membangun semacam terowongan antara browser dan proksi.

Entah banyak tentang hal itu tetapi saya tidak pernah memiliki masalah dengan itu selama bertahun-tahun. Itu hanya bekerja.

Kasus Khusus HTTPS - Proxy Transparan

Catatan tentang proxy transparan. (Yaitu Proxy disembunyikan dan mencegat permintaan klien ala. man-in-the-middle).

Proxy transparan melanggar HTTPS. Klien tidak tahu bahwa ada proxy dan tidak punya alasan untuk menggunakan metode Connect khusus.

Klien mencoba koneksi HTTPS langsung ... yang dicegat. Intersepsi terdeteksi dan kesalahan dilemparkan ke semua tempat. (HTTPS dimaksudkan untuk mendeteksi serangan man-in-he-middle).

Daftar putih domain dan CDN

Daftar putih domain dan subdomain didukung sepenuhnya oleh squid. Meskipun demikian, itu pasti gagal dengan cara yang tidak terduga dari waktu ke waktu.

Situs web modern dapat memiliki semua jenis pengalihan domain dan CDN. Itu akan mematahkan ACL ketika orang tidak berusaha keras untuk menempatkan semuanya dengan rapi dalam satu domain.

Terkadang akan ada installer atau paket yang ingin memanggil homeship atau mengambil dependensi eksternal sebelum dijalankan. Ini akan gagal setiap saat dan tidak ada yang bisa Anda lakukan.

Caching

File konfigurasi yang disediakan menonaktifkan semua bentuk caching. Lebih baik aman daripada menyesal.

Secara pribadi, saya sedang menjalankan berbagai hal di cloud saat ini, semua instance memiliki setidaknya 100 Mbps konektivitas dan penyedia menjalankan repo sendiri untuk barang-barang populer (misalnya Debian) yang ditemukan secara otomatis. Itu membuat bandwidth menjadi komoditas yang saya tidak peduli.

Saya lebih suka menonaktifkan caching daripada mengalami bug caching tunggal yang akan melelehkan otak saya dalam pemecahan masalah. Setiap orang di internet TIDAK BISA mendapatkan header caching mereka dengan benar.

Tidak semua lingkungan memiliki persyaratan yang sama. Anda dapat bekerja ekstra dan mengkonfigurasi caching.

TIDAK PERNAH memerlukan otentikasi pada proxy

Ada opsi untuk meminta otentikasi kata sandi dari klien, biasanya dengan akun LDAP mereka. Ini akan memecah setiap browser dan setiap alat baris perintah di alam semesta.

Jika Anda ingin melakukan otentikasi pada proxy, jangan.

Jika manajemen ingin otentikasi, jelaskan bahwa itu tidak mungkin.

Jika Anda seorang dev dan Anda baru saja bergabung dengan perusahaan yang memblokir internet langsung DAN memaksa otentikasi proxy, JAUHKAN SAJA.

Kesimpulan

Kami telah melalui konfigurasi umum, kesalahan umum, dan hal-hal yang harus diketahui tentang proksi.

Pelajaran yang dipelajari:

• Ada perangkat lunak sumber terbuka yang baik untuk proxy (squid)
• Ini sederhana dan mudah dikonfigurasi (satu file pendek)
• Semua tindakan keamanan (opsional) memiliki pengorbanan
• Sebagian besar opsi lanjutan akan merusak barang dan kembali menghantui Anda
• Proxy transparan melanggar HTTPS
• Otentikasi proxy adalah jahat

Seperti biasa dalam pemrograman dan desain sistem, sangat penting untuk mengelola persyaratan dan harapan.

Saya akan merekomendasikan untuk tetap berpegang pada dasar-dasar ketika menyiapkan proxy. Secara umum, proxy biasa tanpa penyaringan tertentu akan berfungsi dengan baik dan tidak menimbulkan masalah. Hanya harus ingat untuk (otomatis) mengkonfigurasi klien.

Ini tidak akan menyelesaikan semua tugas Anda, tetapi mungkin ini masih membantu. Terlepas dari namanya, apt-cacher-ng tidak hanya bekerja dengan Debian dan turunannya, dan memang demikian

proxy caching. Khusus untuk file paket dari distributor Linux, terutama untuk distribusi Debian (dan berbasis Debian) tetapi tidak terbatas pada itu.

Saya menggunakan ini dalam produksi di lingkungan (berbasis Debian) yang sama seperti milik Anda.

Namun, AFAIK, ini tidak akan mendukung rubygems, PyPI, PECL, CPAN atau npm dan tidak memberikan ACL granular.

Secara pribadi, saya pikir menyelidiki Squid adalah ide yang bagus. Jika Anda menerapkan pengaturan pada akhirnya, bisakah Anda membagikan pengalaman Anda? Saya cukup tertarik dengan kelanjutannya.

kami memiliki tantangan serupa dan menyelesaikannya menggunakan repo lokal dan sistem penyimpanan berbasis snapshot. Kami pada dasarnya memperbarui repositori pengembangan, mengkloning untuk pengujian, mengkloning itu untuk pementasan dan akhirnya untuk produksi. Jumlah disk yang digunakan terbatas seperti itu, ditambah itu semua penyimpanan sata lambat dan tidak apa-apa.

Klien mendapatkan info repositori dari manajemen konfigurasi kami sehingga beralih menjadi mudah jika perlu.

Anda dapat mencapai apa yang Anda inginkan dengan menggunakan ace di server proxy menggunakan string agen-pengguna atau kombinasi ips / mask sumber dan membatasi akses mereka ke domain tertentu, tetapi jika Anda melakukan itu satu masalah yang saya lihat adalah versi paket / pustaka yang berbeda. Jadi jika salah satu host dapat mengakses cpan dan meminta modul xxx :: yyy kecuali jika klien menginstruksikan untuk menggunakan versi tertentu, akan menarik yang terbaru dari cpan (atau pypy atau rubygems), yang mungkin atau mungkin bukan salah satu yang sudah ada di-cache dalam proxy. Jadi, Anda mungkin berakhir dengan versi berbeda di lingkungan yang sama. Anda tidak akan memiliki masalah itu jika Anda menggunakan repositori lokal.