2 votes

NGinx proxy de mise en cache pour les paquets Ubuntu

J'ai configuré NGinx pour agir en tant que proxy de mise en cache :

server {
        listen  3128;

        access_log      /var/log/nginx/cache-access.log combined_hostname;
        error_log       /var/log/nginx/cache-error.log;

        allow   10.0.0.0/8;
        allow   127.0.0.0/8;
        deny    all;

        resolver        127.0.0.1;

        # Fusionner /pool/ de tous les envois ensemble
        location ~ /pool/(.*) {
                proxy_cache_valid       1y;
                proxy_store     /srv/cache/pool/$1;
                proxy_pass      $scheme://$host$request_uri;
        }

        # Mettre en cache des éléments autres que les fichiers .deb eux-mêmes par hôte
        location / {
                proxy_cache_valid       1d;
                proxy_store     /srv/cache/$host/$request_uri;
                proxy_pass      $scheme://$host$request_uri;
        }

}

J'ai aussi configuré les utilitaires apt pour utiliser le cache :

Acquire::http::Proxy "http://dat.host.example.net:3128";
Acquire::https::Proxy "http://dat.host.example.net:3128";

Cela fonctionne, mais seulement pour les dépôts de packages accessibles via http normal. Ceux qui souhaitent être accessibles via https, échouent tous (quelque chose à propos de "headers invalides").

Qu'est-ce que je fais de travers ? Pour le moment, j'ai simplement défini https::Proxy sur "DIRECT", mais j'aimerais mettre en cache les packages indépendamment de la méthode utilisée pour les télécharger...

0voto

Dakota Points 1541

D'accord, apparemment, NGinx ne peut pas faire de proxy de HTTP régulier vers HTTPS. Son principal auteur dit simplement : "Utilisez Squid".

Heureusement pour nous, les dépôts de packages en amont utilisant SSL redirigent automatiquement le HTTP vers le HTTPS -- une redirection que le proxy de NGinx suivra discrètement.

Il existe également un correctif pour NGinx pour combler cette omission assez importante, mais pour l'instant nous n'en avons pas besoin et pouvons rester avec le NGinx standard fourni par Ubuntu.

0voto

Gon Points 111

Nginx fonctionnant en tant que proxy pour une backend HTTPS fonctionne parfaitement. Le problème que j'ai rencontré en faisant cela était lié aux requêtes envoyées au serveur proxifié depuis Nginx n'ayant pas le bon SNI (pour SSL) ni l'en-tête HTTP Host qui, selon le serveur backend proxifié, sont généralement requis.

Vous aurez probablement besoin de quelques lignes supplémentaires dans votre configuration Nginx :

# Envoyer les informations SNI sur la requête SSL afin que le backend puisse utiliser les bonnes clés.
proxy_ssl_server_name on;

# Domaine SSL SNI à demander au backend
proxy_ssl_name backend.example.com;

# Si vous utilisez l'hébergement virtuel basé sur l'hôte, vous devrez ajouter l'en-tête HTTP `Host` :
proxy_set_header Host backend.example.com;

# Facultatif. Assurez-vous que la connexion Nginx <-> Backend utilise le HTTPS sécurisé
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;

C'est ce que j'utilise. Cela semble fonctionner mais cela pourrait ne pas être plus rapide. Il y a probablement quelques ajustements des paramètres de mise en cache qui sont nécessaires mais la connexion principale aux vrais backends fonctionne.

proxy_cache_path /var/cache/nginx/mirror use_temp_path=off keys_zone=mirror:10m max_size=90g inactive=1y levels=1:1:1;

server {
  server_name mirror.example.com;

  listen 80;
  listen [::]:80;

  # Let's Encrypt
  location ^~ /.well-known/acme-challenge/ {
   default_type "text/plain";
   root /var/lib/letsencrypt/webroot;
  }
  location = /.well-known/acme-challenge/ {
   return 404;
  }

  listen 443 ssl;
  listen [::]:443 ssl;
  ssl_certificate     /etc/letsencrypt/live/mirror.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/mirror.example.com/privkey.pem;

  # Indiquer au serveur distant/backend quel client fait réellement la requête
  #proxy_set_header X-Real-IP $remote_addr;
  #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  # Activer la plage. Si vous proxy de gros fichiers, vous pouvez les diviser en morceaux pour permettre des recherches arbitraires plus rapides
  #proxy_cache_key $uri$is_args$args$slice_range;
  #proxy_set_header Range $slice_range;
  #slice 100m;

  # Garder notre cache à jour
  #proxy_cache_use_stale updating;
  proxy_ignore_client_abort on;

  # Empêcher les mises à jour de cache concurrentes multiples en bloquant les nouveaux clients jusqu'à ce que la demande du backend soit remplie.
  proxy_cache_lock on;
  proxy_cache_lock_age 35m;
  proxy_cache_lock_timeout 35m;

  # Configuration SSL du serveur distant backend
  proxy_ssl_verify on;
  proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
  proxy_ssl_server_name on;

  # Doit correspondre au nom de notre configuration de cache proxy
  proxy_cache mirror;

  # Nettoyer automatiquement le cache
  #proxy_cache_purge $purge_method;

  # Proxyer le backend de Raspbian avec le bloc Nginx `upstream`
  location /raspbian {
    # HTTP c'est bien, non ?
    proxy_pass http://raspbian;

    # Forcer la connexion HTTPS au backend, même si les clients nous demandent sur HTTP
    #proxy_pass https://raspbian;

    # Utiliser le même schéma que nos clients. (Pourquoi ??)
    #proxy_pass $scheme://raspbian;

    # Utiliser la source Raspbian
    proxy_set_header Host raspbian.raspberrypi.org;
    proxy_ssl_name raspbian.raspberrypi.org;
  }

  # Proxyer le backend Ubuntu avec le bloc Nginx `upstream`
  location /ubuntu {
    proxy_pass http://ubuntu;
    proxy_set_header Host us.archive.ubuntu.com;
    proxy_ssl_name us.archive.ubuntu.com;

    # Utiliser le miroir de DigitalOcean à la place, par exemple
    #proxy_pass http://digitalocean;
    #proxy_set_header Host mirrors.digitalocean.com;
    #proxy_ssl_name mirrors.digitalocean.com;
  }

  # On pourrait probablement être sophistiqué avec des contrôles de durée de vie plus granulaires pour les entrées de cache basées sur l'URL.
  proxy_cache_valid 200 206 1w;
}

upstream raspbian { server raspbian.raspberrypi.org; }
upstream ubuntu { server us.archive.ubuntu.com; }
upstream digitalocean { server mirrors.digitalocean.com; }

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X