패키지 리포지토리 프록시 모범 사례


16

회사 네트워크에 CentOS 서버 모음이 있습니다. 보안상의 이유로 대부분의 서버는 서버의 핵심 기능 요구 사항이 아닌 한 일반적인 아웃 바운드 인터넷 액세스 권한이 없습니다.

패키지를 업데이트해야 할 때 문제가 발생합니다. yum 저장소의 경우 현재 인터넷에서 필요한 모든 저장소를 미러링하고 미러를 인트라넷 내부에서 사용할 수있게합니다. 개발자, QA, 준비 및 두 개의 프로덕션 데이터 센터의 5 가지 환경 각각에 각 리포지토리의 사본을 보관합니다.

현재 언어 별 패키지 저장소를 해결하지 못했습니다. 서버가 루비 젬, PyPI, PECL, CPAN 또는 npm의 업데이트가 필요한 경우 패키지를 가져 오려면 임시 아웃 바운드 인터넷 액세스 권한을 얻어야합니다. 루비 젬과 PyPI 미러링을 시작하라는 요청을 받았으며 나머지는 아마도 따를 것입니다.

이 모든 것이 어수선하고 잘 작동하지 않습니다. 풀 미러의 복잡성과 디스크 오버 헤드를 없애기 위해 한 환경에서는 단일 캐싱 프록시로, 다른 환경에서는 4 개의 데이지 체인 프록시로 바꾸고 싶습니다. 또한 :

  • 정방향 또는 역방향 프록시 일 수 있습니다. 각 패키지 관리자는 프록시 서버 또는 사용자 정의 저장소 엔드 포인트를 지원하며 로컬 미러 또는 리버스 프록시 일 수 있습니다.
  • 세분화 된 액세스 제어가 필요하므로 어떤 리포지토리 도메인에 연결할 수있는 클라이언트 IP를 제한 할 수 있습니다.
  • 클라이언트는 알 수없는 도메인으로 리디렉션을 수행 할 수 있어야합니다. 원래 요청은 rubygems.org로 제한 될 수 있지만 해당 서버가 임의의 CDN에 302를 반환하면이를 따를 수 있습니다.
  • HTTPS 백엔드를 지원해야합니다. 다른 SSL 서버를 가장 할 필요는 없지만 HTTP를 통해 HTTPS 사이트를 다시 노출하거나 다른 인증서로 종료 및 다시 암호화 할 수 있어야합니다.

나는 처음에 리버스 프록시를보고 있었고, 니스는 프록시 내에서 302 리디렉션을 내부적으로 해결할 수있는 유일한 것 같습니다. 그러나 무료 버전의 Varnish는 HTTPS 백엔드를 지원하지 않습니다. 나는 현재 Squid를 순방향 프록시 옵션으로 평가하고 있습니다.

이것은 엔터프라이즈 네트워크에서 비교적 일반적인 문제인 것처럼 보이지만 다른 사람들이이 문제를 어떻게 해결했는지에 대한 예를 찾는 데 어려움을 겪고 있습니다. 누구든지 비슷한 것을 구현했거나 최선의 방법에 대한 생각을 가지고 있습니까?

감사!

답변:


5

우리는 이것을 위해 오징어를 사용합니다. 오징어의 좋은 점은 패턴 일치를 기반으로 개체의 개별 만료를 매우 쉽게 설정할 수 있다는 것입니다.이 경우 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

이것이 프록시의 확실한 사용 사례입니다 . 리버스 프록시가 아닌 일반 프록시 (일명로드 밸런서)

가장 잘 알려진 무료 오픈 소스는 오징어 입니다. 운 좋게도 하나의 apt-get install squid3파일로 쉽게 설치 하고 구성 할 수있는 몇 안되는 훌륭한 오픈 소스 소프트웨어 중 하나입니다 /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

클라이언트 구성-환경 변수

모든 시스템에서이 두 가지 환경 변수를 구성하십시오.

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

대부분의 http 클라이언트 라이브러리 (libcurl, httpclient, ...)는 환경 변수를 사용하여 자체 구성됩니다. 대부분의 응용 프로그램은 공통 라이브러리 중 하나를 사용하므로 즉시 프록시를 지원합니다 (개발자가 반드시 알고 있음).

구문은 엄격합니다.

  1. 변수 이름 http_proxy은 대부분의 Linux에서 소문자 여야합니다.
  2. 변수 값은 시작해서는 http(s)://안됩니다 (프록시 프로토콜은 http가 아닙니다).

클라이언트 구성-특정

일부 응용 프로그램은 환경 변수를 무시하거나 변수를 설정하기 전에 서비스로 실행됩니다 (예 : debian apt).

이러한 응용 프로그램에는 특별한 구성이 필요합니다 (예 :) /etc/apt.conf.

HTTPS 프록시-연결

HTTPS 프록시는 설계 상 완전히 지원됩니다. 브라우저와 프록시 사이에 일종의 터널을 설정하는 특별한 "CONNECT"방법을 사용합니다.

그 일에 대해서는별로 몰랐지만 몇 년 동안 문제가 없었습니다. 그냥 작동합니다.

HTTPS 특수 사례-투명 프록시

투명한 프록시에 대한 메모. (즉, 프록시는 숨겨져 있으며 클라이언트의 요청을 중간에 가로채는 것을 차단합니다).

투명한 프록시가 HTTPS를 깨뜨리고 있습니다. 클라이언트는 프록시가 있다는 것을 모르고 특별한 Connect 메소드를 사용할 이유가 없습니다.

클라이언트가 직접 HTTPS 연결을 시도합니다 ... 차단되었습니다. 가로 채기가 감지되고 오류가 발생합니다. (HTTPS는 중간자 공격을 탐지하기위한 것입니다).

도메인 및 CDN 허용 목록

도메인과 서브 도메인 화이트리스트는 오징어에 의해 완벽하게 지원됩니다. 그럼에도 불구하고 때때로 예기치 않은 방식으로 실패 할 수밖에 없습니다.

최신 웹 사이트는 모든 종류의 도메인 리디렉션 및 CDN을 가질 수 있습니다. 사람들이 단일 도메인에 모든 것을 깔끔하게 배치하기 위해 여분의 마일을 가지지 않으면 ACL이 손상됩니다.

때로는 설치하기 전에 패키지를 설치하거나 패키지를 실행하여 홈 쉽을 호출하거나 외부 종속성을 검색해야 할 수도 있습니다. 매번 실패 할 것이고 당신이 할 수있는 일은 없습니다.

캐싱

제공된 구성 파일이 모든 형태의 캐싱을 사용하지 않습니다. 죄송합니다보다 더 안전.

개인적으로 저는 현재 클라우드에서 사물을 실행하고 있으며 모든 인스턴스는 최소 100Mbps의 연결을 가지고 있으며 공급자는 자동으로 검색되는 인기있는 항목 (예 : 데비안)에 대해 자체 저장소를 실행합니다. 그것은 내가 관심이없는 상품을 대역폭으로 만든다.

문제를 해결할 때 뇌가 녹아 버리는 단일 캐싱 버그를 경험하는 것보다 캐싱을 완전히 비활성화하고 싶습니다. 인터넷상의 모든 사람은 캐싱 헤더를 올바르게 얻을 수 없습니다.

그러나 모든 환경에 동일한 요구 사항이있는 것은 아닙니다. 여분의 마일로 가서 캐싱을 구성 할 수 있습니다.

프록시에서 인증을 요구하지 마십시오

일반적으로 LDAP 계정을 사용하여 클라이언트에서 비밀번호 인증을 요구하는 옵션이 있습니다. 유니버스의 모든 브라우저와 모든 명령 줄 도구가 손상됩니다.

프록시에서 인증을 원한다면하지 마십시오.

경영진이 인증을 원하면 불가능하다고 설명하십시오.

개발자이고 직접 인터넷을 차단하고 프록시 인증을 강요하는 회사에 가입 한 경우 가능하면 실행하십시오.

결론

일반적인 구성, 일반적인 실수 및 프록시에 대해 알아야 할 사항을 살펴 보았습니다.

학습 한 내용 :

  • 프록 싱을위한 좋은 오픈 소스 소프트웨어가 있습니다 (오징어)
  • 간단하고 구성하기 쉽습니다 (단일 짧은 파일)
  • 모든 (선택적) 보안 조치에는 장단점이 있습니다
  • 대부분의 고급 옵션은 물건을 깰 수 있고 다시 돌아올 것입니다
  • 투명한 프록시가 HTTPS를 깨뜨리고 있습니다
  • 프록시 인증은 악하다

프로그래밍 및 시스템 설계에서 일반적으로 요구 사항과 기대치를 관리하는 것이 중요합니다.

프록시를 설정할 때 기본 사항을 따르는 것이 좋습니다. 일반적으로 특정 필터링이없는 일반 프록시는 제대로 작동하며 문제를 일으키지 않습니다. 클라이언트를 (자동) 구성해야한다는 것을 기억하십시오.


s / man-in-he-middle / man-in-the-middle / (S / E는 단일 문자 편집을 허용하지 않음)
Chen Levy

4

모든 작업이 해결되지는 않지만 여전히 도움이 될 수 있습니다. 이름에도 불구하고 apt-cacher-ng 는 데비안 및 파생 상품과 함께 작동하지 않으며

캐싱 프록시. Linux 배포자의 패키지 파일, 주로 데비안 (및 데비안 기반) 배포 용으로 전문화되었지만 이에 한정되지는 않습니다.

나는 당신과 비슷한 (데비안 기반) 환경에서 프로덕션에서 이것을 사용하고 있습니다.

그러나 AFAIK는 루비 젬, PyPI, PECL, CPAN 또는 npm을 지원하지 않으며 세분화 된 ACL을 제공하지 않습니다.

개인적으로, 오징어 조사는 좋은 생각이라고 생각합니다. 마지막에 설정을 구현 한 경우 경험을 공유 할 수 있습니까? 나는 그것이 어떻게 진행되는지에 상당히 관심이 있습니다.


2

우리는 비슷한 과제를 겪었고 로컬 저장소와 스냅 샷 기반 스토리지 시스템을 사용하여 해결했습니다. 기본적으로 개발 리포지토리를 업데이트하고 테스트를 위해 복제하고 스테이징 및 프로덕션을 위해 복제합니다. 사용되는 디스크의 양은 제한되어 있으며, 모든 저장 공간이 느리고 괜찮습니다.

클라이언트는 구성 관리에서 리포지토리 정보를 가져 오므로 필요한 경우 쉽게 전환 할 수 있습니다.

사용자 에이전트 문자열 또는 소스 IP / 마스크 조합을 사용하여 프록시 서버에서 에이스를 사용하고 특정 도메인에 대한 액세스를 제한 할 수는 있지만 그 한 가지 문제를 해결하면 다른 버전의 패키지 / 라이브러리가 있습니다. 따라서 호스트 중 하나가 cpan에 액세스하고 클라이언트가 특정 버전을 사용하도록 지시하지 않는 한 모듈 xxx :: yyy를 요청하면 cpan (또는 pypy 또는 rubygems)에서 최신 버전을 가져옵니다. 프록시에 캐시됩니다. 따라서 동일한 환경에서 다른 버전으로 끝날 수 있습니다. 로컬 리포지토리를 사용하면 문제가 발생하지 않습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.