Gérer plusieurs services de façon transparente

Posté par  . Édité par Benoît Sibaud, Florent Zara et Bruno Michel. Modéré par Florent Zara. Licence CC By‑SA.
Étiquettes :
54
18
nov.
2013
Administration système

Vous avez commencé à héberger de plus en plus de services internet pour votre famille ou votre association et, les besoins évoluant, vous commencez à avoir plusieurs services qui utilisent le même protocole (vous avez par exemple un serveur web, un serveur d'application et un serveur d'API qui communiquent tous en HTTP) ou alors vous avez voulu cloisonner dans différentes machines virtuelles les services selon leurs utilisateurs et vous vous retrouvez avec plusieurs serveurs web, ftp, mail, dns… malheureusement vous n'avez qu'une seule adresse IP publique pour accéder à tout cela, alors comment permettre à chacun d'accéder au bon service ?

schéma

Des logiciels dits de proxy inverse permettent de répondre à ce besoin, cet article va vous présenter comment fonctionnent certains d'entre eux.

Sommaire

Les services HTTP

Logiciels

À peu près tous les logiciels de proxy HTTP peuvent remplir cette fonctionnalité, le plus à la mode actuellement pour faire cela est nginx mais si vous êtes plus habitué à Squid ou Apache HTTP Server ceux-ci feront bien l'affaire…

Problématique

Pour notre exemple, on va considérer que nous avons deux serveurs HTTP à gérer, le premier héberge un wiki et un blog, le second qui écoute sur le port 8080 héberge une api et un webmail.

Configuration d'Apache HTTP Server

Il faut d'abord charger le module proxy, et le configurer pour agir comme un proxy inverse :

# chargement des modules
LoadModule proxy_module mod_proxy.so
LoadModule proxy_http_module mod_proxy_http.so

# on ne veut pas servir de proxy sortant
ProxyRequests Off

# le proxy ne fera que transférer les requêtes HTTP
ProxyPreserveHost On

Ensuite, il faut configurer chacun des serveurs que l'on veut servir :

NameVirtualHost *:80

<VirtualHost *:80>
        ServerName serveur1.local
        ServerAlias wiki.example.com
        ServerAlias blog.example.com
    ProxyPass / http://serveur1.local/
</VirtualHost>

<VirtualHost *:80>
        ServerName serveur2.local
        ServerAlias api.example.com
        ServerAlias webmail.example.com
    ProxyPass / http://serveur2.local:8080/
</VirtualHost>

Bien entendu, si on est amené à gérer beaucoup de sites et que ceux-ci évoluent, on préférera automatiser la génération de cette configuration.

Bonus : faire du HTTPS grâce au proxy

On peut profiter du proxy pour chiffrer la communication avec internet, il suffit d'activer le proxy SSL :

<VirtualHost *:443>
        ServerName serveur2.local
        ServerAlias api.example.com
        ServerAlias webmail.example.com
        SSLEngine On
        SSLProxyEngine On
        SSLCertificateFile /etc/apache2/ssl/server.crt
        SSLCertificateKeyFile /etc/apache2/ssl/server.key
    ProxyPass / http://serveur2.local:8080/
</Virtualhost>

Ici il faudrait que le certificat gère à la fois les noms de domaine api.example.com et webmail.example.com pour que celui-ci soit valide. Si jamais on veut gérer plusieurs certificats, il est nécessaire de s'assurer de la compatibilité du serveur et des navigateurs web des visiteurs avec la fonctionnalité Server Name Indication.

Les services FTP

Logiciels

De nombreux logiciels de proxy FTP existent, d'ailleurs certains des logiciels faisant office de proxy HTTP ont aussi une fonction FTP. Cependant, ces logiciels ont pour la plupart une des limitations suivantes :

  • le choix du serveur cible n'est pas transparent (il faut par exemple utiliser le login avec le compte georgette@serveur2.local pour accéder au serveur2 avec le compte georgette)
  • un seul serveur cible est géré
  • seule la récupération de fichiers est gérée et pas le dépôt

Il existe cependant deux logiciels qui permettent de répondre à notre besoin de proxy inverse transparent : ftp.proxy et frox ; nginx, encore lui, devrait également répondre à ce besoin dans ses dernières versions

Problématique

Pour notre exemple on considérera qu'il y a un serveur ftp principal (serveur1) et que les utilisateurs georgette et mauricette ont chacun un serveur ftp dédié (serveur2 et serveur3)

Configuration de ftp.proxy

ftp.proxy ne dispose pas de fichier de configuration. Il est lancé à partir de xinetd avec les arguments qui font office de configuration. Voici à quoi doit ressembler /etc/xinetd.d/ftp :

service ftp
{
    socket_type = stream
    wait        = no
    user        = root
    server      = /usr/local/sbin/ftp.proxy
    server_args = -e -m -b -x /usr/local/bin/routage_ftp.pl
}

Le routage des accès vers les différents serveurs est faite grâce au script passé en argument (ici /usr/local/bin/routage_ftp.pl), si on veut rediriger les accès selon le compte utilisé pour le login, il suffit de tester la valeur de la variable d'environnement PROXY_SERVERLOGIN :

#!/usr/bin/perl

# on recupere l'utilisateur ftp
my $login = $ENV{'PROXY_SERVERLOGIN'};

# par defaut le serveur ftp est serveur1
my $serveur = 'serveur1.local';

# georgette et mauricette sont sur d'autres serveurs
if ($login eq 'georgette')
{
  $serveur = 'serveur2.local';
}
elsif ($login eq 'mauricette')
{
  $serveur = 'serveur3.local';
}

# on envoie la reponse au proxy ftp
print "LOGIN $login\nSERVER $serveur\n";

Bien entendu, chacun utilisera son langage préféré pour faire son script, et s'il y a de nombreux comptes on fera un script un peu plus évolué (qui interroge la base de données de chaque serveur FTP par exemple).

Les services DNS

Logiciels

La solution la plus élégante et qui est gérée par tous les logiciels de serveurs DNS est de faire un transfert de zone DNS depuis chacun de vos serveurs DNS vers celui qui sera relié à internet. Cependant, la plupart des serveurs DNS ont aussi une fonctionnalité de proxy inverse et peuvent se contenter de renvoyer les requêtes au bon serveur.

Problématique

Pour notre exemple, on considérera que 192.168.0.33 gère toutes les zones, sauf la zone georgette.example.com qui est gérée par 192.168.0.44 et la zone mauricette.example.com qui est gérée par 192.168.0.55.

Configuration de bind9

# configuration du serveur par défaut
options {
    forwarders {192.168.0.33;};
};
# configuration des cas particuliers
zone "georgette.example.com" {
  type forward;
  forwarders {192.168.10.44;};
};
zone "mauricette.example.com" {
  type forward;
  forwarders {192.168.10.55;};
};

Les services SMTP

Logiciels

Les logiciels de serveur mail les plus populaires, dont sendmail, postfix et exim, permettent tous de relayer des messages à plusieurs serveurs internes

Problématique

Pour notre exemple, on va considérer que les adresses paulette@example.com et claudette@example.com sont gérées par serveur1, et que les adresses contact@georgette.example.com et georgette@example.com sont gérées par serveur2. Chaque serveur mail écoute sur le port 587.

Configuration de postfix

On met d'abord en place une configuration pour n'accepter que les mails à destination de boîtes hébergées par la plateforme :

smtpd_recipient_restrictions = reject_unauth_destination, reject_unlisted_recipient

Ensuite on met en place la configuration du relayage par adresse dans main.cf :

# liste des nom de domaines gérés
relay_domains = /etc/postfix/domaines_relayes
# liste des adresses gérées
relay_recipient_maps = hash:/etc/postfix/adresses_relayees
# serveur de destination de chaque adresse gérée
transport_maps = hash:/etc/postfix/adresses_transport

Fichier domaines_relayes :

example.com
georgette.example.com

Fichier adresses_relayees :

paulette@example.com OK
claudette@example.com OK
georgette@example.com OK
contact@georgette.example.com OK

Fichier adresses_transport :

paulette@example.com smtp:[serveur1.local]:587
claudette@example.com smtp:[serveur1.local]:587
georgette@example.com smtp:[serveur2.local]:587
contact@georgette.example.com smtp:[serveur2.local]:587

Bien entendu la gestion par des fichiers gérés manuellement n'est destinée qu'à une petite architecture évoluant peu, il est possible de demander à postfix d'aller directement interroger des bases de données pour récupérer les différentes adresses et noms de domaines gérés.

Bonus : et la communication en interne ?

Si votre serveur proxy inverse SMTP connaît bien toutes les adresses, ce n'est pas forcément le cas de chacun de vos serveurs mails. Dans notre exemple, si vous souhaitez écrire à paulette@example.com depuis serveur2, le message risque d'être refusé par le serveur mail local parce que l'adresse lui est inconnue… il existe trois solutions pour contourner ce problème :

  • soit mettre en place la configuration de relayage sur tous vos serveurs mails (donc serveur1 aura la configuration pour relayer vers serveur2 les mails gérés par serveur2, et inversement), ce qui peut se révéler lourd à gérer si vous commencez à multiplier les services mails
  • soit, si votre serveur mail le permet, ne pas rejeter les messages aux destinataires inconnus mais plutôt les transférer au serveur proxy (NDLA : je ne connais pas de serveur mail permettant cela)
  • soit configurer deux instances de serveur mail sur chaque serveur, l'une destinée à la réception de mails (que l'on fait écouter sur le port 587 par exemple), et l'autre destinée à l'envoi de mails (qui se contentera de tout envoyer au proxy, charge à celui-ci de redistribuer les mails au bon endroit par la suite) ; en ce qui concerne postfix la lecture de http://www.postfix.org/MULTI_INSTANCE_README.html est un bon début pour mettre cela en place

Les services POP/IMAP

Logiciels

De nombreux projets existent pour offrir un service de proxy inverse en IMAP, mais seuls deux sont pleinement stables et opérationnels : nginx, toujours lui, et perdition qui gère également les protocoles POP et SIEVE.

Configuration de perdition

Perdition fournit une configuration par défaut qui gère directement les protocoles pop et imap, sans avoir besoin de la modifier. Il nécessite seulement un fichier popmap (qui doit être compilé avec la commande make depuis le répertoire /etc/perdition/) qui contient la liste des adresses gérées :

paulette@example.com:serveur1
claudette@example.com:serveur1
georgette@example.com:serveur2
contact@georgette.example.com:serveur2

Perdition peut également interroger une base de données ou un serveur LDAP pour récupérer ces informations.

Bonus : faire du POPS et de l'IMAPS grâce au proxy

Il est possible de profiter de ce proxy pour chiffrer les communications passant par internet. Pour cela, il suffit d'activer les services IMAPS et POPS, en leur indiquant qu'ils doivent communiquer avec un port non crypté en face. Cela est géré dans le fichier /etc/default/perdition ou /etc/sysconfig/perdition selon les distributions :

# Run an instance of perdition in POP3S mode
# Set to "yes" to run this instance of perdition
# Set to any other value to not run this instance of perdition
POP3S=yes
#Command line parameters to pass to perdition when run in POP3S mode
POP3S_FLAGS="--ssl_mode ssl_listen -p 110"
# Run an instance of perdition in IMAP4S mode
# Set to "yes" to run this instance of perdition
# Set to any other value to not run this instance of perdition
IMAP4S=yes
#Command line parameters to pass to perdition when run in IMAP4S mode
IMAP4S_FLAGS="--ssl_mode ssl_listen -p 143"

Le certificat doit être déclaré dans /etc/perdition/perdition.conf :

# chemin des informations de certificat
ssl_ca_file /etc/perdition/perdition.ca.pem
ssl_cert_file /etc/perdition/perdition.crt.pem
ssl_key_file /etc/perdition/perdition.key.pem
# facultatif : autoriser un certificat auto-signé
ssl_ca_accept_self_signed
ssl_cert_accept_self_signed

Dernières considérations pratiques

Visibilité de l'adresse IP publique

Une fois que les connexions passent par le proxy, vos serveurs n'auront plus la visibilité de l'adresse IP publique d'origine, ce qui nécessitera probablement quelques adaptations au niveau de votre plateforme :

  • si vous loguez pour des raisons légales vos accès, que vous avez des outils de statistiques qui utilisent les adresses IP source, ou encore que vous avez des mécanismes de sécurité comme fail2ban, il faudra dorénavant utiliser les logs du proxy et non plus ceux de vos serveurs
  • si vous avez des antispams sur vos serveurs mails, il sera probablement plus pertinent de les installer sur le proxy pour bénéficier de tous les fonctionnalités
  • si vous utilisez des vues sur vos serveurs DNS, il faudra bien veiller à ce que le proxy accède à la vue "internet"
  • dans le cadre du HTTP, les proxys ajoutent un entête X-Forwarded-For aux entêtes, vous pouvez configurer vos serveurs web pour qu'ils considèrent cet entête comme adresse IP source (dans apache HTTPD server, cela peut être fait avec le mod_rpaf).

Choisir le bon logiciel

Vous trouverez une multitude de logiciels prétendant pouvoir répondre au besoin de proxy inverse, mais presque tous ont un défaut en commun : un manque flagrant de documentation pour ce cas précis d'usage. Ici ont été présentés des exemples de configuration pour une sélection de logiciels, mais si vous savez configurer d'autres logiciels pour répondre au même besoin, n'hésitez pas à l'indiquer en commentaire (en conservant de préférence la licence CC-BY-SA afin que l'ensemble puisse être diffusé et réutilisé).

  • # Type

    Posté par  (Mastodon) . Évalué à 1.

    Dans "Les services POP/IMAP"

    s/ngninx/xginx/

  • # Le lien epub en bas ne fonctionne pas

    Posté par  . Évalué à 1.

    Quand je clique, je reçoit quelque chose que le plugin firefoc epubreader ne peut pas lire

  • # Pour du HTTP/HTTPS

    Posté par  . Évalué à 2.

    … Pound fait cela très bien.

    Seul défaut: la documentation quelque peu spartiate.

    • [^] # Re: Pour du HTTP/HTTPS

      Posté par  . Évalué à 1.

      En même temps la documentation est suffisante, et le logiciel fait ça très bien dans mon cas aussi (reverse proxy HTTPS).

  • # Reverse Proxy HTTPS

    Posté par  (site web personnel) . Évalué à 1.

    C'est intéressant ce tuto, je fais justement du reverse Proxy+https chez moi pour rediriger subsonic ou mes flux de streaming audio icecast.
    J'ajouterais qu'on peut utiliser cette technique pour ajouter également de l'authentification http pour des outils qui ne gèrent pas forcément l'authentification, bien pratique pour accéder à ses applis depuis le web.

    Y'a juste un truc que j'ai pas compris comment faire encore, c'est un reverse proxy qui réécrit les urls, pour que les images ou les liens puissent suivre.

    • [^] # Re: Reverse Proxy HTTPS

      Posté par  (site web personnel) . Évalué à 4.

      Y'a juste un truc que j'ai pas compris comment faire encore, c'est un reverse proxy qui réécrit les urls, pour que les images ou les liens puissent suivre.

      Avec Apache tu as mod_rewrite. C'est pas super simple à comprendre au début mais ça permet de « tout » faire dans le domaine.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Reverse Proxy HTTPS

        Posté par  (site web personnel) . Évalué à 1.

        Ouaip, tu as raison, j'ai essayé de me démerder une fois avec ce tuto par exemple : http://httpd.apache.org/docs/current/rewrite/proxy.html
        Jamais réussi à me dépatouiller… :/

        Par exemple, moi j'ai un icecast sur http://localhost:8000/, je veux le rediriger en mappant les urls sur https://localhost/icecast/, mais ca ne marche pas…

        j'ai mis ca comme config mais ca ne gère que la redirection, pas le mod_rewrite :

        ProxyPass /icecast/ http://localhost:8000/
ProxyPassReverse /icecast/ http://localhost:8000/

<Proxy http://localhost:8000/>
  AuthName "Acces protege"
  AuthType Basic
  AuthLDAPBindDN "xxxx"
  AuthLDAPBindPassword "xxxx"
  AuthBasicProvider ldap
  AuthLDAPURL ldap://localhost/xxxx?uid
  Require ldap-filter o=xxxx
</Proxy>

    • [^] # Re: Reverse Proxy HTTPS

      Posté par  . Évalué à 2.

      La plupart du temps c'est le logiciel proxyfié qui doit le gérer, donc à voir au cas par cas.

      Par exemple avec le serveur python paster il utilise bien les variables apaches correspondant à la requête (même si pour faire du proxy https, c'est pas immédiat).

    • [^] # Re: Reverse Proxy HTTPS

      Posté par  . Évalué à 3.

      Le problème se pose quand le service que tu veux faire passer par ton proxy est codé avec les pieds principalement quand les chemin relatif des image,script JS … commence par / (ce qui indique que le chemin commence à la racine du site) les lien ne sont pas réécrit par défaut et donc quand on "rajoute un repertoire" via le proxy il ne retrouve plus les image,scripts,css.

      Par exemple si tu redirige l'interface de gestion de la freebox (je sais ça sert a rien a par pouvoir la taper de depuis mon proxy , donc depuis l'exterieur en http://mondns/freebox/ (je sais ça ne sert a rien mais je fais surtout cela pour le apprendre).

      Tu considère la redirection suivante :

       <Location /freebox/ >

                #config de la redirection
                ProxyPass http://192.168.0.254/
                ProxyPassReverse /
 </Location>

      Ton navigateur veux aller chercher l'image qui est en htmpl snas passer par le proxy il va sur http://192.168.0.254/img/monimage.jpg mais en passant par ton proxy il va faire http://tonproxy/img/monimage.jpg au lieu de http://tonproxy/freebox/img/monimage.jpg à cause du premier slash qui indique qu'il doit aller à la racine du site.

      Tu peux résoudre ça en utilisant mod_proxy_html mais il ne va modifier l'HTML a la volé mais il ne modifie que les chemin dans l'HTML, pas les chemin contenus dans du javascript ou le css et du coup c'est la misère….

      A final il faut utiliser le mod Apache2::ModProxyPerlHtml (via le mod perl d'appache) qui, lui, va en plus réécrire le css et le JS.

      Maintenant j'arrive à faire passé ma freebox par mon proxy et d'autre truc comme subsonic,ect … le tout avec mon petit raspeberry et ça marche du feux de dieu.

      Plus de détail dans les messages que j'ai posté sur le forum quand j'ai eu le problème :
      http://linuxfr.org/forums/linux-general/posts/apache-proxy_html-et-js (la solution est en fin de post)

      En esperant que ça t'aide

  • # sslh

    Posté par  (site web personnel) . Évalué à 5.

    A mentionner aussi sslh qui permet de faire tourner HTTPS et ssh sur le même port. Très utile pour avoir un ssh accessible depuis partout.

  • # ftplol

    Posté par  (site web personnel) . Évalué à 6.

    Ça serait quand même bien d'arrêter d'utiliser FTP et de passer à quelque chose d'un petit peu plus efficace, propre et sûr.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: ftplol

      Posté par  . Évalué à 2.

      sftp ?

    • [^] # Re: ftplol

      Posté par  . Évalué à 3.

      ftps ? sftp ?

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: ftplol

      Posté par  . Évalué à 3.

      Et de moins chiant à proxifiant (ftp passif, ftp actif, toussa)

  • # SNI

    Posté par  (site web personnel) . Évalué à 3.

    Si jamais on veut gérer plusieurs certificats, il est nécessaire de s'assurer de la compatibilité du serveur et des navigateurs web des visiteurs avec la fonctionnalité Server Name Indication.

    Les navigateurs commencent à supporter le SNI relativement bien. Par contre les bibliothèques clientes HTTP pas forcément.

    Un conseil : si vous hébergez une API Web derrière du HTTPS, ne comptez pas sur SNI.

  • # Le seul vrai reverse proxy c'est Delegate

    Posté par  . Évalué à -6.

    Les autres ne sont pas assez ambitieux.
    Il faut pouvoir présenter en NNTP une mailbox SMTP ou en SFTP un serveur FTP ou HTTP, sinon c'est pas un reverse proxy c'est un jouet.
    http://delegate.org/delegate/

    (oui bon je trolle un peu c'est vrai)

  • # Vulture Project

    Posté par  (site web personnel) . Évalué à 2.

    Quelqu'un a-t-il déjà essayé ca ?
    http://www.vultureproject.org/

    C'est un outil de reverse-proxy basé sur apache qui fait plein de choses décrites dans cet article. J'ai lu la doc mais j'ai jamais encore essayé de l'utiliser…

    • [^] # Re: Vulture Project

      Posté par  . Évalué à 4.

      Oui je l'ai utilisé 2/3 ans dans une ancienne boite.

      La problématique c'était d'avoir un reverse donc mais avec une gestion des droits d'accès à partir de compte utilisateur et de groupe issu d'une AD avec également une gestion du SSO pour certains site (souvent des sites eux même connecté à l'AD style Exchange ou Sharepoint mais aussi un intranet sous Drupal ou un CRM Sage) et enfin un portail qui permette aux utilisateurs de retrouver tous les sites auquel ils étaient autorisé a accéder (beaucoup de préproduction et de site de démonstration, à la fin ça tournait autour de 200 sites).
      Vulture c'était ce que j'avais trouvé de plus adapté.
      La mise en place avec la v1 avait nécessité pas mal de petite modifications (dont certaines pas très joli) mais ça tournait.
      C'était devenu beaucoup plus simple avec la v2 que les développeurs avait bien refondu et à laquelle avait été intégré mes quelques demande de correction, évolution et contribution.

  • # Pas toujours si facile

    Posté par  (site web personnel) . Évalué à 5.

    Si tu veux faire du reverse proxy de subversion, il faut ajouter des LIMIT car par défaut, les commandes autres que PUT et GET ne passeront pas. Voila ce que je met chez moi…

      <Limit OPTIONS PROPFIND GET REPORT MKACTIVITY PROPPATCH PUT CHECKOUT MKCOL MOVE COPY DELETE LOCK UNLOCK MERGE>
     Require        ldap-attribute  shadowExpire=0
  </Limit>

    Ensuite, j'ai de nombreux site web dont le chemin n'est pas le même sur le serveur reverse proxy que le serveur lui même… C'est parfois très très chiant à régler et parfois, je n'ai pas trouvé de solution satisfaisante (nagios par exemple).

    Donc, si possible, essayer de mettre des chemins identiques des deux cotés.

  • # Haproxy

    Posté par  (site web personnel) . Évalué à 8.

    Apache n'est pas un bon choix pour un reverse proxy http / https :

    • pas de gestion différencié des timeout côté client et côté serveur
    • modèle un thread / proc par requête (pas de pool)
    • pas de check pour vérifier la santé du backend
    • pas de maximum de connexions par backend
    • pas de stratégie de replie en cas de problème

    Il vaut largement mieux utiliser haproxy, nginx ou varnish qui pourrons de plus vous servir à d'autres choses (mode pop / imap pour nginx, mode tcp pour haproxy, cache pour varnish).

    Personnellement mon coeur me pousse vers haproxy

    Petite exemple amusant :

    On veux rediriger les connexions mysql adressé sur localhost vers une machine distante de façon transparente pour l'utilisateur.

    Le problème est que la libmysqlclient convertie les appels vers localhost en connexion sur la socket unix par défaut. Autrement une simple règle de firewall ne suffit pas. Il faut pouvoir rediriger les connexions à la socket unix vers le port 3306 d'une machine distante. 

    listen  mysql /tmp/mysql.sock
        mode tcp
    timeout server 1h
    timeout client 30s
        server sql0 sqlhost:3306 maxconn 500

    Et hop merki haproxy

    • [^] # Re: Haproxy

      Posté par  (site web personnel) . Évalué à 3.

      Est ce que haproxy sais ré-écrire les pages web. Avec Apache, c'est possible et personnellement, j'utilise beaucoup cette fonctionnalité. Exemple :

      On ajoute à cela certaines ré-écritures des URL dans dans la page toto.html ainsi que les pages voisines selon les sites…

      • [^] # Re: Haproxy

        Posté par  (site web personnel) . Évalué à 3.

        Dans l'exemple que tu donnes je ne vois pas la nécessité de réécrire le HTML. Ceci dit haproxy ne le fait clairement pas. Apache de base non plus d'ailleurs.

        L'approche entre mod-rewrite et haproxy n'est pas similaire. Il faut penser un peu différemment. Mais c'est également très efficace. Je conseille de regarder http://blog.exceliance.fr. il y a beaucoup de recettes intéressantes pour aborder la question

        • [^] # Re: Haproxy

          Posté par  (site web personnel) . Évalué à 3.

          De base avec Apache, tu peux modifier les pages et même modifier les cookies…

          Mon cas était assez simple mais en pratique, avec plusieurs sites, si je suis en interne, j'ai les URL en http et des chemins X et en externe, je bascule tout en https avec d'autres chemins. C'est un peu tordu mais cela marche très bien et permet d'avoir les services en interne sans authentification ni https… (et puis, il y a un peu d'histoire la dessous).

          • [^] # Re: Haproxy

            Posté par  (site web personnel) . Évalué à 2.

            De base avec Apache, tu peux modifier les pages et même modifier les cookies…

            Pour les cookies aucun problème c'est un header comme un autre, mais pour les pages (autrement dit le html), comment fais-tu ? tu utilises mod_substitute pour réécrire tes liens ? Je ne vois pas trop l'avantage par rapport à des liens relatifs (c'est une vrai question) ?

            • [^] # Re: Haproxy

              Posté par  (site web personnel) . Évalué à 2.

              J'utilise un bête ProxyHTMLURLMap, parfois en mode "ProxyHTMLExtended On". Il y a peut être mieux mais j'ai trouvé cela et ça marche bien depuis plusieurs années.

              Par exemple, sur la section du reverse proxy qui s'occupe de la forge, j'ai la ligne suivante.

              ProxyHTMLURLMap   http://intranet.maboite.fr/ /intranet/

              Ainsi, en interne, on accède à la forge en direct et de l'extérieur, on passe en https via le reverse proxy et les URL de l'intranet sont ré-écrite de manière a aussi passer en https par le reverse proxy (plus de nom DNS).

              Je ne suis pas dans un problématique de performance et de cluster web mais d'utilisation d'un reverse proxy pour tout ramener sur une seule URL en externe. L'idée initiale était d'avoir une forge et un intranet accessible en interne en lecture seule mais sans mot de passe afin de faciliter la vie des utilisateurs (et espérer qu'ils les regardent un peu plus).

              Ce serait à refaire, je ferais peut être plus simple tout en https et passant toujours par le reverse proxy…

  • # IPv6

    Posté par  . Évalué à 4.

    Tout ça est bien sûr grandement simplifié avec l'utilisation de l'IPv6. Le problème est que seulement 2,5 % de la population mondiale aura accès à vos services.

    En tout cas, pour ma part, mes machines virtuelles sont accessibles en IPv6 ce qui simplifie grandement l'administration car on peut s'y connecter nativement.

    • [^] # Re: IPv6

      Posté par  (site web personnel) . Évalué à 5.

      Pas forcément… personnellement, j'ai autant d'IP publique que je le demande ;-)

      On peux voir un reverse proxy pour répartir la charge mais on peux le voir aussi comme un portail. Tous mes sites web tourne sur des machines différentes mais l'utilisateur externe n'a que l'IP du reverse proxy qui est juste un apache et fait l'authentification sur LDAP.

      Ainsi, l'authentification est faite sur le reverse proxy via le code Apache en C a qui je fais confiance, pas à l'application web php ou autre dont j'ai bien plus de doute ! L'avantage aussi est qu'il faut passer Apache avant de même voir le moindre bout de code php. Autre avantage, le reverse proxy est une machine qui fait que cela et n'a que très peu de paquetages d'installer. La mise à jour marche à tous les coup même l'upgrade d'une version à l'autre de la distribution. Les mises à jour des N serveurs en dessous faisant N choses différentes est bien moins rapide car parfois, ça ne marche pas aussi bien que prévu ;-)

  • # En plus

    Posté par  (site web personnel) . Évalué à 3.

    Concernant le smtp, l'excellent mimedefang permet d'aller interroger un serveur distant pour valider l'utilisateur, ce qui permet de distribuer ses comptes à moindre frais. 

           sub filter_recipient
       {
           my($recip, $sender, $ip, $host, $first, $helo,
              $rcpt_mailer, $rcpt_host, $rcpt_addr) = @_;
           return md_check_against_smtp_server($sender, $recip,
                                "filter.domain.tld",
                                "mail.domain.tld");
       }

    Par ailleurs, de plus en plus d'applications supportent le proxy protocol (http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt) qui permet de transmettre l'IP à l'origine de la connexion. C'est le cas par exemple de postfix.

    Si ce n'est pas le cas et qu'il n'existe pas d'autre mécanismes spécifique en ce sens (type mod_rpaf pour apache par exemple), la seule façon de conserver l'IP d'origine est d'utiliser la fonctionnalité de proxy transparent fournie par le noyau ( https://www.kernel.org/doc/Documentation/networking/tproxy.txt) : tproxy

  • # cherokee

    Posté par  (site web personnel) . Évalué à 6.

    Pour le http, j'utilise cherokee. L'avantage pour le sysadmin du dimanche que je suis, c'est son interface d'administration très simple à comprendre et à utiliser:

    cherokee

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Autres outils

    Posté par  . Évalué à 2.

    Pour continuer sur les tutoriaux/outils sympas pour gérer tout le bouzin : http://howto.biapy.com/fr

    PAr ex, pour apache, a2tools pour créer vite et bien des virtualhosts à partir de templates : http://howto.biapy.com/fr/debian-gnu-linux/serveurs/apache-2/simplifier-ladministration-dun-serveur-apache-2-avec-a2tools

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.