Najlepsza praktyka do proxy repozytoriów pakietów

16

W mojej sieci korporacyjnej mam kolekcję serwerów CentOS. Ze względów bezpieczeństwa większość serwerów nie ma ogólnego wychodzącego dostępu do Internetu, chyba że jest to podstawowy wymóg funkcjonalny serwera.

Stwarza to wyzwanie, gdy muszę zaktualizować pakiety. W przypadku repozytoriów yum obecnie dubluję wszystkie potrzebne repozytoria z Internetu i udostępniam mirrory w intranecie. Przechowuję kopie każdego repozytorium w każdym z naszych pięciu środowisk: dev, QA, inscenizacja i dwa produkcyjne centra danych.

Obecnie nie rozwiązuję repozytoriów pakietów specyficznych dla języka. Gdy serwery potrzebują aktualizacji z Rubygemów, PyPI, PECL, CPAN lub npm, muszą uzyskać tymczasowy wychodzący dostęp do Internetu, aby pobrać pakiety. Poproszono mnie o rozpoczęcie tworzenia kopii lustrzanych i PyPI, a reszta prawdopodobnie nastąpi.

Wszystko to jest niezgrabne i nie działa dobrze. Chciałbym zastąpić go jednym buforującym serwerem proxy w jednym środowisku i czterema połączonymi łańcuchami serwerami proxy w moich innych środowiskach, aby wyeliminować złożoność i obciążenie dysku pełnymi serwerami lustrzanymi. Do tego:

  • Może to być proxy do przodu lub do tyłu; każdy menedżer pakietów obsługuje serwer proxy lub niestandardowy punkt końcowy repozytorium, którym może być lokalny serwer lustrzany lub odwrotny serwer proxy.
  • Wymaga szczegółowej kontroli dostępu, więc mogę ograniczyć adresy IP klientów, z którymi mogą się łączyć domeny repo.
  • Klienci muszą mieć możliwość śledzenia przekierowań do nieznanych domen. Twoje pierwotne żądanie może być ograniczone do rubygems.org, ale jeśli ten serwer zwróci numer 302 do losowej sieci CDN, powinieneś być w stanie go wykonać.
  • Powinien obsługiwać backendy HTTPS. Niekoniecznie muszę podszywać się pod inne serwery SSL, ale powinienem móc ponownie ujawnić witrynę HTTPS przez HTTP lub zakończyć i ponownie zaszyfrować przy użyciu innego certyfikatu.

Początkowo patrzyłem na odwrotne proxy, a Varnish wydaje się być jedynym, który pozwoliłby mi wewnętrznie rozwiązać 302 przekierowań w proxy. Jednak darmowa wersja Varnish nie obsługuje backendów HTTPS. Teraz oceniam Squid jako opcję przekazywania proxy.

To wydaje się być czymś, co powinno być stosunkowo częstym problemem w sieciach korporacyjnych, ale mam problem ze znalezieniem przykładów tego, jak inni ludzie to rozwiązali. Czy ktoś zaimplementował coś podobnego lub zastanawia się, jak najlepiej to zrobić?

Dzięki!

Dave Smith
źródło

Odpowiedzi:

5

Używamy do tego Squid; Zaletą kałamarnicy jest to, że można dość łatwo ustawić indywidualne wygasanie obiektów na podstawie dopasowania wzorca, co pozwala dość szybko usunąć metadane z repozytorium yum. Posiadana przez nas konfiguracja, która implementuje to:

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/

Andrzej
źródło
5

To ostateczny przypadek użycia proxy . Normalny serwer proxy, a nie odwrotny serwer proxy (zwany także modułami równoważenia obciążenia).

Najbardziej znanym, wolnym i otwartym oprogramowaniem jest kałamarnica . Na szczęście jest to jedno z niewielu dobrych programów typu open source, które można łatwo zainstalować za pomocą jednego apt-get install squid3i skonfigurować za pomocą jednego pliku /etc/squid3/squid.conf.

Omówimy dobre praktyki i lekcje, o których warto wiedzieć.

Oficjalny plik konfiguracyjny został nieco zmodyfikowany (usunięto 5000 bezużytecznych komentarzy).

#       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

Konfiguracja klienta - zmienne środowiskowe

Skonfiguruj te dwie zmienne środowiskowe we wszystkich systemach.

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

Większość bibliotek klienckich http (libcurl, httpclient, ...) konfiguruje się samodzielnie przy użyciu zmiennych środowiskowych. Większość aplikacji korzysta z jednej ze wspólnych bibliotek, a tym samym obsługuje proxy bezpośrednio po wyjęciu z pudełka (bez konieczności tworzenia przez programistę wiedzy).

Zauważ, że składnia jest ścisła:

  1. Nazwa zmiennej http_proxyMUSI zawierać małe litery w większości systemów Linux.
  2. Wartość zmiennej NIE MOŻE zaczynać się od http(s)://(protokół proxy to NIE http (s)).

Konfiguracja klienta - specyficzna

Niektóre aplikacje ignorują zmienne środowiskowe i / lub są uruchamiane jako usługa, zanim można ustawić zmienne (np. Debian apt).

Te aplikacje będą wymagały specjalnej konfiguracji (np /etc/apt.conf.).

HTTPS Proxying - Connect

Proxy HTTPS jest w pełni obsługiwane przez projekt. Korzysta ze specjalnej metody „CONNECT”, która ustanawia tunel między przeglądarką a serwerem proxy.

Nie wiem zbyt wiele na ten temat, ale nigdy nie miałem z tym problemów od lat. To po prostu działa.

Przypadek specjalny HTTPS - przezroczysty serwer proxy

Uwaga na temat przezroczystego serwera proxy. (tzn. serwer proxy jest ukryty i przechwytuje żądania klientów, np. man-in-the-middle).

Przezroczyste proxy przełamują HTTPS. Klient nie wie, że istnieje serwer proxy i nie ma powodu, aby używać specjalnej metody Connect.

Klient próbuje bezpośredniego połączenia HTTPS ... przechwyconego. Przechwytywanie jest wykrywane, a błędy są zgłaszane w dowolnym miejscu. (HTTPS ma na celu wykrywanie ataków typu człowiek w środku).

Biała lista domen i CDN

Biała lista domen i subdomen jest w pełni obsługiwana przez kałamarnicę. Niemniej jednak od czasu do czasu musi zawieść w nieoczekiwany sposób.

Nowoczesne strony internetowe mogą mieć wszelkiego rodzaju przekierowania domen i CDN. To złamie ACL, gdy ludzie nie zrobią więcej, aby wszystko uporządkować w jednej domenie.

Czasami pojawia się instalator lub pakiet, który chce zadzwonić do domu lub pobrać zewnętrzne zależności przed uruchomieniem. Za każdym razem zawiedzie i nic nie możesz na to poradzić.

Buforowanie

Podany plik konfiguracyjny wyłącza wszelkie formy buforowania. Lepiej dmuchać na zimne.

Osobiście w tej chwili działam w chmurze, wszystkie instancje mają łączność co najmniej 100 Mb / s, a dostawca uruchamia własne repozytorium popularnych rzeczy (np. Debian), które są wykrywane automatycznie. To sprawia, że ​​przepustowość jest towarem, o który nie dbam mniej.

Wolę całkowicie wyłączyć buforowanie niż napotkać pojedynczy błąd buforowania, który stopi mój mózg podczas rozwiązywania problemów. Każda pojedyncza osoba w Internecie NIE MOŻE poprawnie ustawić swoich nagłówków buforowania.

Jednak nie wszystkie środowiska mają takie same wymagania. Możesz pójść o krok dalej i skonfigurować buforowanie.

NIGDY NIGDY nie wymaga uwierzytelnienia na serwerze proxy

Istnieje możliwość żądania uwierzytelnienia hasła od klientów, zwykle przy użyciu ich kont LDAP. Zniszczy każdą przeglądarkę i każde narzędzie wiersza poleceń we wszechświecie.

Jeśli chcesz przeprowadzić uwierzytelnianie na serwerze proxy, nie rób tego.

Jeśli zarząd chce uwierzytelnienia, wyjaśnij, że nie jest to możliwe.

Jeśli jesteś programistą i właśnie dołączyłeś do firmy, która blokuje bezpośredni internet ORAZ wymusza uwierzytelnianie proxy, URUCHAMIAJ SIĘ, GDY MOŻESZ.

Wniosek

Przeszliśmy przez wspólną konfigurację, typowe błędy i rzeczy, które trzeba wiedzieć o proxy.

Wyciągnięta lekcja:

  • Istnieje dobre oprogramowanie typu open source do proxy (kałamarnica)
  • Jest prosty i łatwy w konfiguracji (pojedynczy krótki plik)
  • Wszystkie (opcjonalne) środki bezpieczeństwa mają kompromisy
  • Najbardziej zaawansowane opcje psują rzeczy i wracają, by cię prześladować
  • Przezroczyste proxy przełamują HTTPS
  • Uwierzytelnianie proxy jest złe

Jak zwykle w programowaniu i projektowaniu systemu, niezwykle ważne jest zarządzanie wymaganiami i oczekiwaniami.

Zalecam trzymanie się podstaw podczas konfigurowania serwera proxy. Ogólnie rzecz biorąc, zwykły serwer proxy bez żadnego konkretnego filtrowania będzie działał dobrze i nie sprawiał problemów. Pamiętaj tylko o (automatycznej) konfiguracji klientów.

użytkownik5994461
źródło
s / man-in-he-middle / man-in-the-middle / (S / E nie zezwala na edycję pojedynczych znaków)
Chen Levy
4

To nie rozwiąże wszystkich twoich zadań, ale być może nadal jest to pomocne. Pomimo nazwy apt-cacher-ng nie działa tylko z Debianem i pochodnymi, i jest

buforujący serwer proxy. Specjalizuje się w plikach pakietów od dystrybutorów Linuksa, głównie w dystrybucjach Debiana (i opartych na Debianie), ale nie tylko.

Używam tego w produkcji w podobnym (opartym na Debianie) środowisku, takim jak twoje.

Jednak AFAIK, to nie obsługuje rubygemów, PyPI, PECL, CPAN lub npm i nie zapewnia granularnych list ACL.

Osobiście uważam, że badanie Squid jest dobrym pomysłem. Jeśli ostatecznie wdrożysz konfigurację, możesz podzielić się swoimi doświadczeniami? Jestem bardzo zainteresowany tym, jak to idzie.

gf_
źródło
2

mieliśmy podobne wyzwanie i rozwiązaliśmy je przy użyciu lokalnych repozytoriów i systemu pamięci masowej opartego na migawkach. Zasadniczo aktualizujemy repozytorium programistyczne, klonujemy je do testowania, klonujemy do testowania i wreszcie do produkcji. Ilość używanego dysku jest w ten sposób ograniczona, a ponadto jest to wolne miejsce do przechowywania danych sata i jest w porządku.

Klienci uzyskują informacje o repozytorium z naszego zarządzania konfiguracją, więc przełączanie jest w razie potrzeby łatwe.

Możesz osiągnąć to, co chcesz, za pomocą asa na serwerze proxy, używając ciągów użytkownika-agenta lub źródłowych kombinacji ips / mask i ograniczając ich dostęp do niektórych domen, ale jeśli zrobisz ten problem, to widzę różne wersje pakietów / bibliotek. Więc jeśli jeden z hostów może uzyskać dostęp do cpan i żąda modułu xxx :: yyy, chyba że klient poleci użyć konkretnej wersji, pobierze najnowszą wersję z cpan (lub pypy lub rubygems), która może, ale nie musi być tą, która była już buforowane w proxy. Więc możesz skończyć z różnymi wersjami w tym samym środowisku. Nie będziesz mieć tego problemu, jeśli korzystasz z lokalnych repozytoriów.

natxo asenjo
źródło