Quand on lis des résultats sur les ban d’essai, on remarque que nginx est en feu pour servir du contenu statique mais pour ce qui est du contenu généré, il est un peu plus lent que apache. Pour une application maison j’irais avec nginx mais pour faire de l’hébergement web traditionnel j’utilise un mélange des solutions ou un utilise chaque une d’entre elles pour ce qu’elles font le mieux.

Dans cet article j’utilise nginx pour héberger le contenu statique les .png .jpg .css .js et bien d’autres extensions. Pour tout le reste des requêtes, il va les envoyer a son collègue Apache qui traitera la demande. Heureusement les .htaccess sont aussi pris en considération car au bout de la ligne si c’est pas du contenu statique, apache le traite comme si nginx n’était pas la. Ça parait compliqué mais c’est vraiment facile à faire. Il suffit de faire en sorte que apache et nginx écoutent sur un port différent.

Dans la configuration il faut faire:

Listen 0.0.0.0:8081

Ensuite voici un exemple de configuration pour un nginx.

user              apache;
worker_processes  1;
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    # Hide nginx version
    server_tokens off;
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    log_format  main  '$remote_addr - $remote_user [$time_local] '
                      '"$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;
    sendfile        on;
    tcp_nopush      on;
    tcp_nodelay     on;
    keepalive_timeout  15;

    gzip               on;
    gzip_min_length    1100;
    gzip_buffers       4 32k;
    gzip_disable       msie6;
    gzip_static        on;
    gzip_comp_level    2;
    gzip_proxied       any;
    gzip_types         text/plain 
                       application/x-javascript
                       text/xml
                       text/css;

    ignore_invalid_headers on;

    client_header_timeout  3m;
    client_body_timeout    3m;
    send_timeout           3m;
    connection_pool_size   256;
    client_header_buffer_size    4k;
    large_client_header_buffers  4 32k;
    request_pool_size      4k;
    output_buffers         4 32k;
    postpone_output        1460;

    include /etc/nginx/conf.d/www.example.com.conf;

}

Ensuite dans le fichier /etc/nginx/conf.d/www.example.com.conf

server {
    error_log /var/log/nginx/www.example.com-error_log warn;
    listen 0.0.0.0:80;
    server_name example.com www.example.com;
    access_log /var/log/nginx/www.example.com.access.log main;
    error_log  /var/log/nginx/www.example.com.error.log;
    root /var/www/html/www.example.com/public_html;
    location / {
        location ~.*\.(3gp|gif|jpg|jpeg|png|ico|wmv|avi
                      |asf|asx|mpg|mpeg|mp4|pls|mp3|mid
                      |wav|swf|flv|html|htm|txt|js|css
                      |exe|zip|tar|rar|gz|tgz|bz2|uha
                      |7z|doc|docx|xls|xlsx|pdf|iso)$ {
            expires 7d;
            try_files $uri @backend;
        }
        error_page 405 = @backend;
        add_header X-Cache "HIT from Backend";
        proxy_pass http://127.0.0.1:8081;
        include proxy.inc;
    }

    location @backend {
        internal;
        proxy_pass http://127.0.0.1:8081;
        include proxy.inc;
    }

    location ~ .*\.(php|jsp|cgi|pl|py)?$ {
        proxy_pass http://127.0.0.1:8081;
        include proxy.inc;
    }

    location ~ /\.ht {
        deny all;
    }
}

Dans le fichier proxy.inc

proxy_connect_timeout 59s;
proxy_send_timeout   600;
proxy_read_timeout   600;
proxy_buffer_size    64k;
proxy_buffers     16 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
proxy_pass_header Set-Cookie;
proxy_redirect     off;
proxy_hide_header  Vary;
proxy_set_header   Accept-Encoding '';
proxy_ignore_headers Cache-Control Expires;
proxy_set_header   Referer $http_referer;
proxy_set_header   Host   $host;
proxy_set_header   Cookie $http_cookie;
proxy_set_header   X-Real-IP  $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Ces exemples proviennent en partie de la configuration généré www.nginxcp.com. Mon setup personnel est très similaire.

Pour certain site que je gère moi-même, j’ai modifié la config pour utiliser une cache memcached qui semble être excellente coté vitesse mais malheureusement je dois repartir memcached régulièrement quand mes modifications ne prennent pas effet assez rapidement bref encore du pain sur la planche

Mon scénario est très simple: j’ai un client qui de temps à autre utilise trop de ressources pour être seul sur son serveur. Vous savez ces fameux chroniqueurs politiques, ils passent aux nouvelles de 18h et pouf 18h02 une montagne de trafic, le serveur ralentis, les gens voient que le site se comporte bizarrement, ces gens deviennent des cliqueurs agressifs de piton reload croyant que ça va aider les choses.

Le setup que j’ai configuré inclut trois serveurs. Idéalement il en faudrait plus, surtout si on vise devenir redondant et à l’épreuve des pannes. Que se soit un bris de matériel, une panne réseau, une panne électrique ou simplement une mise à jour qui tourne mal le résultat est le même: Site Web = DOWN = client pas content!

Sur mon backend j’avais deux serveurs web qui pourraient facilement être hébergés n’importe où sur le web même sur Amazon EC2. Ici on utilise des Smart Server car l’objectif est de tester et d’utiliser leur réseau privé. Cela ajoute une couche de sécurité puis que web1 et web2 n’ont pas à être directement accessible sur Internet. Dans notre cas, le serveur agissant comme loadbalancing fait du ProxyPass. Ce setup fonctionne assez bien quand le client ne fait pas trop de modifications à son site, lire: upload d’images, changement de template, mises à jour!

Ce que j’ai fait c’est que j’ai isolé le /wp-admin/ afin qu’il tombe toujours sur le même serveur, le proxy dans mon cas et j’y ai ensuite configuré un petit cron avec une commande rsync pour synchroniser les fichiers aux 10 minutes. Pour le moment ce scénario me satisfait même s’il est loin d’être idéal ou parfait. Il y aurait moyen d’automatiser un synchronisme des fichiers sur l’ensemble des serveurs, mais je n’ai pas vraiment expérimenté avec des solutions telles que FAM ou DRBD.

En gros, j’ai effectué mon installation standard de wordpress sur le serveur qui fait le ProxyPass. Ensuite, j’ai configuré le site ainsi qu’installé les extensions et templates. J’ai configuré une BD SQL sur ce serveur, dans notre cas c’est aussi le proxy mais il serait idéal de l’isoler seul sur son serveur ou de l’off loader sur Amazon RDS voir même sur un DaaS comme Xeround. Dans mes configurations de wordpress, apache, mysql, et memcached je spécifie toujours les IP du réseau privé interne puisque tous mes serveurs sont chez iWeb sont des Smart Servers. Cela élimine du trafic sur le réseau public. Ça rend le setup beaucoup plus sécuritaire.

Tous les serveurs ont subi un durcissement de base dont j’ai déjà donné les grandes lignes. Ils ont iptables sur les deux interfaces réseau, ne relayent pas de trafic entre les deux interfaces réseau. Ils ont le service memcached de configuré sur le réseau privé. Il parait qu’on n’en a jamais assez de cette cache.

Sur web1 et web2, j’ai configuré les serveurs Apache pour écouter uniquement sur le réseau privé, pas de ftp de bd sql. J’ai bloqué presque tout le trafic sur le réseau public et autorisé seulement les protocoles utilisés sur le réseau privé.

Sur le serveur qui fait face à Internet, j’ai configuré mysql pour écouter uniquement sur le réseau privé. Apache et vsftpd, eux, écoutent sur le réseau public. J’ai configuré des clefs ssh afin de pouvoir synchroniser facilement mon DocumentRoot via rsync. J’ai alors laissé le temps me faire parvenir les fichiers. Quelques minutes plus tard, après le passage du cron, je me retrouve avec une belle installation de WordPress! Ajouter un web3, 4, etc. devient un jeu d’enfant.

Sur mes serveurs web1 et web2 j’ai fait une configuration similaire à celle-ci en utilisant le port 488 puisqu’il est déjà autorisé dans SeLinux.

NameVirtualHost 10.X.Y.Z1:488
<VirtualHost 10.X.Y.Z1:488>
    ServerAdmin webmaster@horizonlinux.org
    DocumentRoot /usr/local/sites/www.horizonlinux.org
    ServerName 10.X.Y.Z1
    ErrorLog logs/www.horizonlinux.org-error_log
    CustomLog logs/www.horizonlinux.org-access_log combinedio
</VirtualHost>

Sur le serveur proxy voici la configuration que j’ai utilisée.

<VirtualHost www.horizonlinux.org:80>
    ServerAdmin webmaster@horizonlinux.org
    ServerName www.horizonlinux.org
    ServerAlias horizonlinux.org
    DocumentRoot /usr/local/sites/www.horizonlinux.org
    ErrorLog logs/www.horizonlinux.org-error_log
    CustomLog logs/www.horizonlinux.org-access_log combinedio

    ProxyRequests Off
    ProxyPreserveHost On
    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    ProxyPass /balancer-manager !
    ProxyPass /wp-admin !
    ProxyPass / balancer://mycluster/ stickysession=BALANCEID nofailover=On
    ProxyPassReverse / http://10.X.Y.Z1:488/
    ProxyPassReverse / http://10.X.Y.Z2:488/
    <Proxy balancer://mycluster>
        BalancerMember http://10.X.Y.Z1:488 route=hrz1
        BalancerMember http://10.X.Y.Z1:488 route=hrz2
        ProxySet lbmethod=byrequests
    </Proxy>

    <Location /balancer-manager>
        SetHandler balancer-manager
        Order deny,allow
        Allow from all
    </Location>
</VirtualHost>

Je savais qu’il y avait plusieurs initiatives pour motiver les gens à utiliser des versions récente de php. Le gros problème est pas que php évolue si rapidement que ça, c’est que les produits de type entreprise se base sur une version « établie depuis un boute » avant le lancement du os … supporté 5ans ensuite un « end of life mode » ou il y a seulement les updates de sécurité qui sont corrigé. Ils ne peuvent tout simplement pas suivre l’évolution car php n’est pas 100% backward compatible assez longtemps. Moi je voterais pour un mod_oldschool_php_jéatek’tupgrade:)genre de module.

Dernièrement j’ai eu plusieurs demandes pour un php plus récent sur un de mes serveur de production. Je savais que migrer de php 5.1.6 vers 5.3.x brise certaine choses tel-que le jeux de fonctions basé sur ereg.

Pour les gens qui programment en php depuis longtemps, au début il était recomendé d’utiliser les ereg* car preg faisait un peu trop allusion a « Perl Compatible Regular Expression » et tranquillement ils ont suggéré de passer a preg_* pour finallement enlever les ereg* dans la version php-5.3. C’est bien le fun sauf quand tu as des clients qui ont fait leur site web il y a 5, 6ans ou même plus ans avec les façon de procéder de l’époque. En tant qu’admin, tu te retrouve avec des sites qui sont « téteux » sur les versions de php. Faire la mise à jour majeur de php peut rendre certain sites non fonctionnels en quelques secondes.

La difficulté c’est lorsque tu héberge plusieurs centaines sites web et que tu te dit, hummm pourquoi pas updater php j’ai quelques clients qui ont besoin de 5.3 ou qui rêverais que je roule avec la 5.4-beta … j’imagine que ça ne devrait pas rien briser …

Il y a plusieurs façon de contourner ce problème, c’est plus simple si on utilise pas de pannel de gestion comme cpanel ou plesk. Le hic c’est que la plus part des clients s’attendent à avoir un panel de gestion pour gérer leurs bébelles. Perso je ne les aime pas mais l’industrie étant ce qu’elle est, je deal avec

Il y a moyen de rouler plusieurs version de php sur un même serveur mais ça cause des problèmes de sécurité et à mon avis c’est vraiment à utiliser comme plaster temporaire quand on vraiment mais vraiment pas le choix.

Depuis quelque temps pour mes environment de shared hosting je roule avec plusieurs serveurs Ceux-ci utilisent différente versions de php, je trouve cela beaucoup plus simple à gérer. Si un client veut plus récent, go je le migre. S’il ne me spécifie pas quel version, la dernière sera celle choisie. En cas de problèmes, je peux le déplacer rapidement sur des versions précédente. En gros je conserve 5.1.X, 5.2.X et 5.3.X quand 5.4 sera stable et que le 5.4.1 ou .2 sera sortie et que des clients en feront la demande, je vais en déployer un autre serveur, utilisant une procédure comme celle ci-bas qui montre comment updater php 5.1.6 vers 5.2.17 dans un environment plesk.

wget http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/i386/epel-release-5-4.noarch.rpm
wget http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/i386/ius-release-1.0-8.ius.el5.noarch.rpm
rpm -ihv epel-release-5-4.noarch.rpm ius-release-1.0-8.ius.el5.noarch.rpm
yum install rpm-build yum-plugin-replace
cd /usr/src/redhat/SPEC

vim php.spec

Summary: Empty PHP
Name: php
Version: 0
Release: 0
License: Public
Group: Applications/System
%description
Empty PHP RPM
%files

rpmbuild -bb php.spec
# On install un rpm vide de php pour
# contourner des bug de compatibilité
rpm -ihv /usr/src/redhat/RPMS/i386/php-0-0.i386.rpm
yum replace php --replace-with php52
/usr/local/psa/admin/sbin/websrvmng -a
service httpd restart

]]> http://www.horizonlinux.org/2011/09/15/php-et-ca-compatibilite-entre-ses-versions/feed/ 0 http://www.horizonlinux.org/2011/08/12/serveur-smart-avec-ou-sans-la-couche-super-smart-layer-iweb/ http://www.horizonlinux.org/2011/08/12/serveur-smart-avec-ou-sans-la-couche-super-smart-layer-iweb/#comments Fri, 12 Aug 2011 14:42:38 +0000 Charles http://www.horizonlinux.org/?p=87 Continue reading →]]> Depuis quelques mois j’utilise les fameux Smart Servers d’iWeb et je peux dire que je suis très agréablement surpris, le prix est bon, ils sont fiable et l’interface pour gérer son parc de serveurs est assez jolie. On a accès a une console virtuelle pour faire des shutdown si le serveur ne répond plus, etc.

Dernièrement iWeb a lancé une série de fonctionnalités supplémentaires qu’ils appellent l’option SuperSmart. C’est toujours intéressant de voir ce qu’ils nous proposent:

• Une mise à jour transfert de données de 10 000go à 20 000go.
• Un Firewall externe à votre serveur.
• Un Réseau local de 1 Gigabit, intéressant si on a plusieurs Smart Servers.

Pour le surplus de bande passant, si un jour je pousse 10 000 Go de trafic, il me fera plaisir de débourser 20$ de plus par mois pour activer cette option « Super Smart ». Mais en ce moment je me force pour atteindre mon 10 000 Go et j’en suis incapable (je sauvegarde le serveur d’un ami à toutes les nuits et je synchronise mes données sur le cloud).

Pour ce qui est du firewall, il est bien pour les gens qui s’achètent un dédié avec cPanel et qui ne connaissent pas vraiment les astuces pour sécuriser son serveur. Par défaut ce firewall est assez permissif. Il y a cependant un truc qui je trouve génial, c’est qu’il est externe à notre serveur donc si on se bloque en faisant une erreur de manipulation, 2-3 clics et bingo on a accès à nouveau à notre serveur.

J’ai fait divers test sur le backnet et c’est vraiment un beau produit. À première vue ça me semble bien isolé, il y a probablement 1 vlan par client avec un subnet /27 ce qui est amplement suffisant pour mes besoins. J’ai essayé rapidement de scanner avec nmap sur le backnet, j’ai sniffé voir si je ne verrais pas quelque chose mais je vois que iWeb a bien prévu le coup.

Ce que j’aime le plus des Serveurs Smart ce sont les possibilités que le backnet peut m’offrir. Je suis entrain d’élaborer un beau projet avec un ami de longue date et à moyen terme ce backnet nous sera très utile. On risque bien d’utiliser l’option SuperSmart pour le surplus de bande passant ainsi que le backnet de 1 gig non monitoré. Je vais certainement activer le firewall juste parce qu’il est là mais je vais aussi compléter en utilisant iptables pour faire un filtrage plus précis. Voici notamment les réglages que je juge importants pour un bon firewall et que je n’ai pas retrouvé dans leur interface pour gérer les règles de sécurité:

• Filtrer selon l’adresse source.
• Filtrer selon l’adresse destination.
• Filtrer sur le réseau privé.
• Filtrer dans la table Forward voir même jouer dans la table NAT.

Mais au moins les port scan seront bloqués avant de se rendre à moi

Ma conclusion: SuperSmart en vaut plus que le prix, particulièrement si:

• on est pas très familier avec iptables, et la sécurité en général.
• on a besoin de plus que 10 000 go de bande passante.
• on prévoit transférer beaucoup de données sur le backnet.

Cependant connaissant bien iWeb, je sais pertinemment qu’il y aura d’autres agréables surprises qui vont s’y ajouter!

Vraiment génial comme petit authenticator pour son compte google. Ils ont aussi relaché un module PAM, donc à peu prèt tout ce qui est sur unix/linux peux être accroché avec ce petit module. Il y a un autre projet que je n’ai pas testé encore pour faire du web based 2 factorauthentication sous apache!

Je me suis amusé avec le module PAM, et en fait j’ai activé cela sur tout mes connexion SSH. Je ne voulais pas mettre en péril mon smart serveur et ne pas pouvoir le booter en recovery afin de l’arranger. J’ai jugé que d’activer du 2 factor authentication sur tout les connexions SSH était suffisent. J’ai tout de même des clients qui transfert leur sites web via ftp et je ne voulais pas les obliger à utiliser cela. J’aurais aussi pu faire en sorte les sudo et les su soient authentifié via ce 2 factor, mais mon serveur est chez iWeb et je ne voulais pas courrire le risque que je ne puisse plus devenir root d’aucune autre façon qu’avec le recovery cd si le module décidais de bugger pour une raison ou une autre. Bref, j’ai toujours accès via un kvm ip sane le 2 factor en backup alors cela me conviens.

L’installation est hyper simple mais requière que vous avez déjà installé l’app sur votre smart phone.

Il faut les répository EPEL pour mercurial.

# yum install mercurial pam-devel

# hg clone https://google-authenticator.googlecode.com/hg/ google-authenticator/

# cd google-authenticator/libpam/
# locate libdl.so ( Si le make fail .. c’est fort probablement le patch dans le Makefile qui est pas bon )
# make
#  make install

# vim /etc/pam.d/sshd
auth required pam_google_authenticator.so

# vim /etc/ssh/sshd_config

ChallengeResponseAuthentication yes

su – mon_user_pas_root

$ google-authenticator

Répondre aux questions, paster le lien dans votre navigateur web et scanner le QR code pour l’ajouter a votre appareil!
Notez les emergency scratch codes car ils peuvent vous sauver les fesses si votre téléphone est à plat, perdu!

Première chose que j’ai fait c’est de lire attentivement ce document: [RHEL5 Guide|http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf]. Je sais qu’il est très long mais il couvre énormément de choses et c’est un très bon point de départ pour partir du bon pied comme on dit. Je n’enterai pas dans tout les détails de cette configuration car elle beaucoup trop vaste pour un billet sur mon blog, en plus elle est très bien expliqué dans le RHEL5 Guide.

Les grosse étapes pour sécurier un serveur:

1. Déactivéer/déinstaller tout ce qu’on a pas besoin.

2. Sécuriser le file system:

• Mettre des nodev, noexec, nosuid, nosgid
• Faire un bind mount pour /var/tmp
• Surveiller le filesystem pour tout changements.
• Vérifier l’intégrité des fichiers.
• Vérifier l’intégrité des packages.
• Vérifier les permissions sur certain fichiers critique.
• Surveiller les changements pour les fichiers suid/sgid.
• Trouver les fichier n’ayant pas de owner.
• Surveiller les dossier et fichier world writable.

3. Sécuriser le OS

• Déactiver core dumps.
• Déactiver prelinking.
• Activer ShiledExec.
• Déactiver les filesystem qu’on utilise pas ex: clef-usb, floppy…
• Garder selinux enforcing,targetted mode.
• Effectuer divers modifications à Syslog afin que tout soit écrit à quelquepart.
• Utiliser Auditd.
• Rehausser la sécurité des login.
• Configurer une déconnection automatique.
• Remettre en fonction le fameux group Wheel.
• Définir une stratégie de mot de passe plus adécoite.
• Changer le hashage de mot de passe pour utiliser SHA512.
• Verrouiller les comptes après plusieur écheque de login.
• Verrouiller tout les comptes système et changer leur shell pour /sbin/nologin.
• Implementer du 2 factor authentication pour les comptes SSH

4. Réseau

• Ajouter quelques options sysctl.
• Batir un firewall solide.
• Sécuriser les divers services utilisé.
• Déactiver le support IPv6 étant donné que iWeb n’offre pas encore ce service sur leur smart servers. ( hint, hint! )

Une fois qu’on a passé à travers ceci, il est temps d’installer nos services voulu.
Dans mon cas j’ai ajouté quelques repo, principalement pour avoir un php5.2 ou 5.3 (ius) et j’ai aussi installé celui de (epel) qui me permet d’installer des truc comme nginx, iotop, phpmyadmin, divers module perl sans avoir à compiler manuellement.

En utilisant ces repo extérieur il faut absoluement faire attention et s’assurer qu’on autorise seulement les packages voulu de ces repository avec la ligne ‘includepkgs’

Une fois rendu ici, le fun commence. La guerre est officiellemnt déclaré entre moi et SeLinux car certain services sont plus compliqués à faire fonctionner ensemble mais rien de terrible quand on sait comment s’y prendre.

Ceci n’est qu’un exemple de ce qui peut arriver car sur la plus part des sites web, il y a une authentification qui se fait dans un canal sécurisé et une fois que le site sais qui tu es, il te donne un espèce de jeton appelé cookie que tu lui transmet à chaque requête. Cela permet de maintenir la connexion ouverte sans avoir à ré-authentifier chaque clique, chaque reload… Chose qui serait très désagréable pour l’utilisateur. La problématique en arrière de cela est que les sites n’utilisent pas le protocole HTTPS afin de sécuriser de bout en bout la connexion une fois l’authentification faite. Ça laisse donc la porte ouverte pour des gens avec un sniffer de capturer ces cookies et de les ré-utiliser ou tout simplement enregistrer et se faire passer pour vous.

Cette pratique est beaucoup plus simple à effectuer via les réseaux WiFi que sur un réseau câblé. Étant donné que tout passe dans les air, il est facile d’intercepter les communications si elle n’est pas chiffré de bout en bout. Certaine technologies wireless comme Aruba sont drôlement plus complexes voir presque impossibles à intercepter la communication. Via les réseaux câblé il faut un peu plus de gymnastique mais on peut y arriver avec de arp poisoning mais encore la ça dépend du commutateur.

Bref, une opération qui nécissitais de bien comprendre ce qui se passe en dessous du navigateur web se fait maintenant en quelque cliques!! C’est assez épurant de voir tout ce qui est disponible et maintenant très facilement accessible.

En espérant que les sites populaire, pour ne pas dire tout les sites vont réagir et chiffrer leur communications afin que cela ne soit plus possibles.

Lien intéressant sur FireSheep
Autre article sur FireSheep

Depuis plusieurs années, j’utilise OpenVPN dès que j’ai besoin d’une solution vpn. Simple, stable, sécuritaire, supportant plusieurs niveau d’authentification, du proxy http, bref rien à dire de plus pour me convaincre. Il y a même des outils hyper simple à utiliser pour faire la gestion des clef SSL.

La première étape est de se configurer un serveur OpenVPN.

Voici mon setup. J’utilise Centos 5.5, mais n’importe quelle version de linux/bsd ferait le travail tout aussi bien. Il se peut que les path des logiciel ne soient pas au même endroit, mais le concept reste le même.

Voici les grande lignes:

• Installer OpenVPN sur le serveur
• Générer les clefs SSL
• Éditer le fichier server.conf
• Paramétrer notre firewall
• Copier certaines clefs vers nos clients ( portable, téléphone cellulaire, etc. )
• Configurer notre client pour se connecter sur notre serveur.

yum install openvpn
cd /etc/openvpn/
cd easy-rsa
### configurer le fichier "vars" et répondre aux questions qui nous sont demandées.
. ./vars
sh clean-all
sh build-ca
sh build-key-server my-srv
sh build-key my-cli1
sh build-key my-cli2
sh build-key my-cli3
sh build-dh
openvpn --genkey --secret ta.key
cp keys/*.crt ../keys/
cp keys/*.key ../keys/

Quant à la configuration du firewall, je n’entrerai pas dans les détails. Brièvement, j’utilise du SNAT étant donné que j’ai une ip fixe ( chez iWeb ), mais si j’étais hébergé à la maison j’utiliserais fort probablement du Masquerade et un Dyndns.

Éditer /etc/sysctl.conf et s’assurer que les lignes suivantes sont présentes:

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
# relire notre config et l'appliquer
sysctl -p
iptables -t nat -A POSTROUTING -s 10.18.137.0/255.255.255.0 \
    -o eth0 -j SNAT --to-source 72.55.147.X
iptables -I RH-Firewall-1-INPUT -d 72.55.147.X \
    -p udp -m udp --dport 1194 -j ACCEPT
service iptables save

Ensuite, on peut éditer /etc/sysconfig/iptables ou votre quelconque script de firewall.

Voici mon fichier de configuration

local 72.55.147.X
port 1194
proto udp
dev tun
ca keys/ca.crt
cert keys/serveur.crt
key keys/serveur.key  # This file should be kept secret
dh keys/dh2048.pem
server 10.18.137.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
push "dhcp-option DNS 10.18.137.1"   # rediriger son dns sur une machine qu'on contôle!
keepalive 10 120
tls-auth keys/ta.key 0 # This file is secret
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

Ensuite il faut copier nos clef « clients » vers nos ordinateurs portables. Dans mon cas, j’utilise TunnelBlick sur macosx et le client OpenVPN qui vient avec Android.

Pour utiliser OpenVPN sur son cellulaire il faut malheureusement l’avoir préalablement rooté son appareil. Je n’entrerai pas dans ces détails, mais sur ce site ils ont tout expliqué comment faire: http://www.cyanogenmod.com/ Lorsque CyanogenMod-6.0, de préférence, est installé, on va dans le Market, on installe OpenVPN-Installer et OpenVPN-Settings. Ensuite, il faut copier les clefs ca.crt, ta.key, my-cliX.crt. my-cliX.key dans un répertoire qui s’appelle openvpn à la racine de notre carte SD.

Voici le fichier de configuration que j’ai sur mon appareil:
Notez qu’il a été créé par OpenVPN-Settings et qu’il est ensuite facilement éditable à partir de notre ordinateur.

client
dev tun
proto udp
remote 72.55.147.X 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert my-cliX.crt
key my-cliX.key
tls-auth ta.key 1
comp-lzo
verb 4

Ceci étant fonctionnel, j’ai tout de même quelques désagréments. Le vpn ne s’accroche pas automatiquement au démarrage du wifi. Si le téléphone tombe en veille ça cause parfois problème lors du réveil. Quand on est dans un environnement où il y a plusieurs bornes ( cégep, université, etc ), il se peut qu’en se déplaçant, et qu’on change de borne, le routing se brise, mais rien de terrible… Off/On du vpn et le tour est joué.

Attention à votre batterie! Elle se vide à vue d’oeil.