Ich habe eine Sammlung von CentOS-Servern in meinem Unternehmensnetzwerk. Aus Sicherheitsgründen haben die meisten Server keinen allgemeinen ausgehenden Internetzugang, es sei denn, dies ist eine grundlegende Funktionsanforderung für den Server.

Dies ist eine Herausforderung, wenn ich Pakete aktualisieren muss. Für yum-Repositories spiegele ich derzeit alle benötigten Repos aus dem Internet und stelle die Spiegel im Intranet zur Verfügung. Ich bewahre Kopien jedes Repos in jeder unserer fünf Umgebungen auf: Entwicklungs-, Qualitätssicherungs-, Staging- und zwei Produktions-Rechenzentren.

Ich löse derzeit nicht für sprachspezifische Paket-Repos. Wenn Server ein Update von Rubygems, PyPI, PECL, CPAN oder npm benötigen, müssen sie einen temporären ausgehenden Internetzugriff erwerben, um die Pakete abzurufen. Ich wurde gebeten, mit dem Spiegeln von Rubygems und PyPI zu beginnen, und der Rest wird wahrscheinlich folgen.

All dies ist klobig und funktioniert nicht gut. Ich möchte es durch einen einzelnen Caching-Proxy in einer Umgebung und vier verkettete Proxys in meinen anderen Umgebungen ersetzen, um die Komplexität und den Festplatten-Overhead von Vollspiegeln zu beseitigen. Zusätzlich:

• Es kann sich entweder um einen Forward- oder einen Reverse-Proxy handeln. Jeder Paketmanager unterstützt einen Proxyserver oder einen benutzerdefinierten Repository-Endpunkt, der entweder ein lokaler Spiegel oder ein Reverse-Proxy sein kann.
• Es erfordert eine differenzierte Zugriffskontrolle, damit ich einschränken kann, welche Client-IPs eine Verbindung zu welchen Repo-Domänen herstellen können.
• Clients müssen Weiterleitungen zu unbekannten Domänen folgen können. Ihre ursprüngliche Anfrage ist möglicherweise auf rubygems.org beschränkt. Wenn dieser Server jedoch eine 302 an ein zufälliges CDN zurückgibt, sollten Sie in der Lage sein, dieser zu folgen.
• Es sollte HTTPS-Backends unterstützen. Ich muss nicht unbedingt die Identität anderer SSL-Server annehmen, sollte jedoch in der Lage sein, eine HTTPS-Site über HTTP erneut freizugeben oder sie zu beenden und mit einem anderen Zertifikat erneut zu verschlüsseln.

Anfangs habe ich Reverse-Proxys in Betracht gezogen, und Varnish scheint der einzige zu sein, der es mir ermöglicht, 302 Weiterleitungen innerhalb des Proxys intern aufzulösen. Die kostenlose Version von Varnish unterstützt jedoch keine HTTPS-Backends. Ich bewerte jetzt Squid als Forward-Proxy-Option.

Dies scheint ein relativ häufiges Problem in Unternehmensnetzwerken zu sein, aber ich habe Probleme, Beispiele dafür zu finden, wie andere Leute dies gelöst haben. Hat jemand etwas ähnliches implementiert oder überlegt, wie man das am besten macht?

Vielen Dank!

Wir benutzen dafür Squid; Das Schöne an Squid ist, dass Sie den individuellen Ablauf von Objekten basierend auf einer Musterübereinstimmung relativ einfach einstellen können, wodurch die Metadaten aus dem Yum-Repo relativ schnell gelöscht werden können. Die Konfiguration, die wir haben, implementiert dies:

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/

Das ist ein definitiver Anwendungsfall für einen Proxy . Ein normaler Proxy, kein Reverse-Proxy (auch bekannt als Load Balancer).

Das bekannteste und kostenlosste Open-Source-Produkt ist der Tintenfisch . Zum Glück ist es eine der wenigen guten Open-Source-Software, die einfach apt-get install squid3mit einer einzigen Datei installiert und konfiguriert werden kann /etc/squid3/squid.conf.

Wir werden die guten Praktiken und die Lektionen durchgehen, über die wir Bescheid wissen.

Die offizielle Konfigurationsdatei wurde leicht geändert (die 5000 unnötig kommentierten Zeilen wurden entfernt).

#       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

Client-Konfiguration - Umgebungsvariablen

Konfigurieren Sie diese beiden Umgebungsvariablen auf allen Systemen.

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

Die meisten http-Client-Bibliotheken (libcurl, httpclient, ...) konfigurieren sich selbst mithilfe der Umgebungsvariablen. Die meisten Anwendungen verwenden eine der gängigen Bibliotheken und unterstützen daher das sofortige Proxying (ohne dass der Entwickler dies unbedingt weiß).

Beachten Sie, dass die Syntax streng ist:

1. Der Variablenname http_proxyMUSS unter den meisten Linux-Betriebssystemen in Kleinbuchstaben angegeben werden.
2. Der Variablenwert http(s)://DARF NICHT mit beginnen (das Proxy-Protokoll ist NICHT http (s)).

Client-Konfiguration - spezifisch

Einige Anwendungen ignorieren Umgebungsvariablen und / oder werden als Dienst ausgeführt, bevor Variablen gesetzt werden können (zB Debian apt).

Diese Anwendungen erfordern eine spezielle Konfiguration (z /etc/apt.conf. B. ).

HTTPS-Proxy - Verbinden

Das HTTPS-Proxying wird vom Design voll unterstützt. Es wird eine spezielle "CONNECT" -Methode verwendet, die eine Art Tunnel zwischen dem Browser und dem Proxy herstellt.

Ich weiß nicht viel darüber, aber ich hatte seit Jahren nie Probleme damit. Es funktioniert einfach

HTTPS-Sonderfall - Transparenter Proxy

Ein Hinweis zum transparenten Proxy. (dh der Proxy ist ausgeblendet und fängt Client-Anfragen ab, ua man-in-the-middle).

Transparente Proxys brechen HTTPS. Der Client weiß nicht, dass ein Proxy vorhanden ist, und hat keinen Grund, die spezielle Connect-Methode zu verwenden.

Der Client versucht eine direkte HTTPS-Verbindung ... die abgefangen wird. Das Abfangen wird erkannt und Fehler werden überall hin geworfen. (HTTPS soll Man-in-He-Middle-Angriffe erkennen).

Domain- und CDN-Whitelisting

Das Whitelisting von Domains und Subdomains wird vollständig von Squid unterstützt. Dennoch wird es von Zeit zu Zeit auf unerwartete Weise versagen.

Moderne Websites können alle Arten von Domain-Weiterleitungen und CDNs enthalten. Das wird ACL brechen, wenn die Leute nicht die Extrameile gegangen sind, um alles ordentlich in einer einzigen Domäne unterzubringen.

Manchmal gibt es ein Installationsprogramm oder ein Paket, das das Homeship aufrufen oder externe Abhängigkeiten abrufen möchte, bevor es ausgeführt wird. Es wird jedes Mal scheitern und es gibt nichts, was Sie dagegen tun können.

Caching

Die bereitgestellte Konfigurationsdatei deaktiviert alle Arten von Caching. Sicher ist sicher.

Ich persönlich betreibe momentan Dinge in der Cloud, alle Instanzen haben mindestens 100 Mbit / s Konnektivität und der Anbieter betreibt seine eigenen Repos für beliebte Dinge (zB Debian), die automatisch erkannt werden. Das macht Bandbreite zu einer Ware, die mich nicht weniger interessiert.

Ich würde das Caching lieber vollständig deaktivieren, als einen einzelnen Caching-Fehler zu beobachten, der mein Gehirn bei der Fehlerbehebung zum Erliegen bringt. Jede einzelne Person im Internet KANN NICHT die richtigen Caching-Header erhalten.

Nicht alle Umgebungen haben die gleichen Anforderungen. Sie können die Extrameile gehen und das Zwischenspeichern konfigurieren.

NIEMALS eine Authentifizierung am Proxy erfordern

Es gibt eine Option, die eine Kennwortauthentifizierung von Clients erfordert, normalerweise mit ihren LDAP-Konten. Es wird jeden Browser und jedes Befehlszeilentool im Universum beschädigen.

Wenn Sie eine Authentifizierung am Proxy durchführen möchten, tun Sie dies nicht.

Wenn das Management eine Authentifizierung wünscht, erklären Sie, dass dies nicht möglich ist.

Wenn Sie ein Entwickler sind und gerade einer Firma beigetreten sind, die das direkte Internet blockiert UND die Proxy-Authentifizierung erzwingt, RUN AWAY WHILE YOU CAN.

Fazit

Wir gingen durch die gemeinsame Konfiguration, gemeinsame Fehler und Dinge, die man über das Proxying wissen muss.

Lektion gelernt:

• Es gibt eine gute Open-Source-Software zum Proxying (Tintenfisch)
• Es ist einfach und leicht zu konfigurieren (eine einzelne kurze Datei)
• Alle (optionalen) Sicherheitsmaßnahmen haben Kompromisse
• Die fortschrittlichsten Optionen zerstören Dinge und kommen zurück, um Sie zu verfolgen
• Transparente Proxys brechen HTTPS
• Proxy-Authentifizierung ist böse

Wie in der Programmierung und im Systemdesign üblich, ist es wichtig, die Anforderungen und Erwartungen zu verwalten.

Ich würde empfehlen, sich beim Einrichten eines Proxys an die Grundlagen zu halten. Im Allgemeinen funktioniert ein einfacher Proxy ohne besondere Filterung gut und bereitet keine Probleme. Ich muss nur daran denken, die Clients (automatisch) zu konfigurieren.

Dies wird nicht alle Ihre Aufgaben lösen, aber vielleicht ist dies immer noch hilfreich. Trotz des Namens funktioniert apt-cacher-ng nicht nur mit Debian und Derivaten und ist es auch

ein Caching-Proxy. Spezialisiert auf Paketdateien von Linux-Distributoren, hauptsächlich für Debian- (und Debian-basierte) Distributionen, aber nicht darauf beschränkt.

Ich verwende dies in der Produktion in einer ähnlichen (auf Debian basierenden) Umgebung wie Ihrer.

AFAIK unterstützt jedoch keine Rubygems, PyPI, PECL, CPAN oder npm und bietet keine granularen ACLs.

Ich persönlich halte es für eine gute Idee, Squid zu untersuchen. Wenn Sie am Ende ein Setup implementieren, können Sie Ihre Erfahrungen mitteilen? Ich bin ziemlich interessiert, wie es geht.

Wir hatten eine ähnliche Herausforderung und haben sie mit lokalen Repos und einem auf Snapshots basierenden Speichersystem gelöst. Grundsätzlich aktualisieren wir das Entwicklungs-Repository, klonen es zum Testen, klonen es für die Bereitstellung und schließlich für die Produktion. Die Menge der verwendeten Festplatte ist auf diese Weise begrenzt. Außerdem ist der Sata-Speicher langsam und das ist in Ordnung.

Die Kunden erhalten die Repository-Informationen von unserem Konfigurationsmanagement, so dass das Wechseln bei Bedarf einfach ist.

Sie könnten das erreichen, was Sie wollen, indem Sie Asse auf dem Proxy-Server verwenden, indem Sie Benutzer-Agent-Zeichenfolgen oder Quell-IPS / Mask-Kombinationen verwenden und deren Zugriff auf bestimmte Domänen einschränken. Wenn Sie jedoch dieses eine Problem tun, sehe ich das von verschiedenen Versionen von Paketen / Bibliotheken. Wenn einer der Hosts auf cpan zugreift und das Modul xxx :: yyy anfordert, sofern der Client nicht anweist, eine bestimmte Version zu verwenden, wird der neueste Host von cpan (oder pypy oder rubygems) abgerufen, der möglicherweise bereits vorhanden ist oder nicht im Proxy zwischengespeichert. Es kann also vorkommen, dass Sie unterschiedliche Versionen in derselben Umgebung haben. Sie werden dieses Problem nicht haben, wenn Sie lokale Repositorys verwenden.