Le LAN de mon domicile (simplifié)
I'm just a poor wayfaring stranger
Traveling through this world bellow
There is no sickness, no toil, no danger
In that bright land to which I go
I'm going there to see my Father
And all my loved ones who've gone home
I'm just going over Jordan
I'm just going over home
I know dark clouds will gather 'round me,
I know my way is hard and steep
Yet beauteous fields arise before me
Where God's redeemed their virgils keep
I'm going there to see my mother
She said she'd meet me when I come
So I'm only going over Jordan
I'm just going over home
Wayfaring Stranger tel que chanté par Johnny Cash
J'étais à la maison. C'était parfait. J'avais un beau logiciel de messagerie [MUA] (MessengerPro), un logiciel de transport de courrier [MTA] (POPstar) et un anti spam très puissant (SpamStamp par Jan-Jaap van der Geer) tournant sur mon ordinateur. Cela marchait impeccablement, c'était presque trop. Mon courrier était collecté depuis quattre sources différentes, filtré de ses éléments indésirables (75%) et archivé d'un manière réfléchie avec notament des filtres automatiques pour les mailing lists. Tout se passait sans aucun accro car j'avais une connection ADSL à 2Mb pour être connecté en permanance au travers de mes switchs et de mon modem/routeur NetGear.
Le LAN de mon domicile (simplifié)
Et puis il a fallu que je quitte mon appartement, pour travailler puis pour prendre des vacances. Je me suis senti perdu. Je pouvais utiliser des interfaces de webmail pour certains de mes comptes, selon leur source, mais ce n'était pas terrible et je n'avais pas accès à mes précieuses archives, sans parler de tout ces spams. C'était une perte de temps vraiment très inconfortable au point que j'ai failli renoncer.
J'ai décidé de reprendre les choses en main et de faire quelque chose moi-même.
Au cours d'une session de navigation aléatoire sur internet, j'ai découvert sur le site de R-Comp qu'il existe un produit qu'ils appellent MessengerPro Server edition. Ils en faisaient la publicité en disant que ce logiciel permetait de "partager votre email sur le réseau de votre domicile de manière à pouvoir facilement y accéder depuis d'autres machines, même si ce sont des PCs ou toutes autres platformes"
. Après quelques échanges d'e-mail avec les personnes de cette société qui offre un support excellent, j'ai fini par comprendre que ce produit était en fait le même MUA que j'utilisais mais qu'il pouvait en plus se comporter comme un serveur IMAP 4 rev 1. J'ai tout de suite tilté même si ce n'était pas donné en terme de prix (upgrade à 60£).
J'ai toujours bien aimé l'idée du protocole IMAP mais je ne me suis jamais retrouvé dans un contexte où j'aurais à l'utiliser à titre personnel avec mon MUA. Le concept me plaisait. Je me suis dit que si mon riche MUA pouvait se transformer en serveur IMAP, mon routeur pouvait bien router son trafic du réseau domestique [LAN] à l'internet [WAN], ce monde extérieur où j'avais si peu.
Pour tester la faculté de mon routeur de rediriger le flux rentrant de données, j'ai installé sous windows un serveur FTP TYPSoft que j'aime bien car il est simple, facile à configurer, robuste et apparament sain. Je suis allé sur l'interface web de mon modem/routeur NetGear. Dans la section port worwarding (redirection de port), j'ai choisi le service FTP (port 21) et ai entré l'IP LAN de Piotr, Piotr étant le nom réseau de ce PC. J'ai fait des essais avec des amis et tout a fonctionné comme prévu.
Le problème avec ma connection ADSL Wanadoo est que je n'ai pas d'IP fixe. C'est une option qui coûte 15 € par mois et j'ai décidé que c'était trop cher. En plus, j'aime bien le fait de ne pas avoir d'IP fixe pour des raisons de sécurité que vous comprendrez facilement. Sans IP fixe, comment allais-je faire la connection entre le WAN et mon LAN ?
La premièreidée qui m'est venue fût d'utiliser un service comme DynDNS. C'était LA solution mais cela impliquait une procédure d'enregistrement auprès d'eux ainsi que l'installation d'un logiciel spécifique sur mon PC, donc j'ai décidé de faire autre chose. Je cherchais en fait un moyen de me publier mon IP temporaire.
Perl est venu à mon secours. Ma première idée fût de placer sur un de mes serveurs internet un petit script qui ne ferait pas grand chose à part simplement afficher l'IP actuelle du visiteur. C'est très simple à faire. Par exemple, cela peut se coder comme ça :
#!/usr/bin/perl
use CGI;
$query = new CGI;
$ip = $ENV{'REMOTE_ADDR'};
print "Content-type: text/html\n\n";
print "$ip";
exit(0);
Trop simple, non ? Beaucoup trop simple. Le problème est que mes différents sites sont hébergés sur des serveurs mutualisés qui sont parfois mal surveillés et donc peu fiables. L'autre conssidération est que cela allait générer du trafic indu, manger de la bande passante et du temps processeur pour pas grand chose. J'ai cherché sur Google et je me suis retrouvé sur ce site, ShowMyIP.com dont le but principal et presque unique est de montrer à son visiteur l'IP qu'il utilise, chose que je recherchais. C'est un service gratuit, les robots y sont les bienvenus et il n'y a pas besoin d'enregistrement. On est juste autorisé à faire 1500 requêtes par jour mais c'est déjà bien plus que ce dont j'ai besoin. Ils ont des interfaces XML/SOAP/RSS mais mon choix s'est porté sur l'interface la plus simple http://simple.showmyip.com/ qui est en mode texte. Une requête renvoi quelque chose comme ça :
82.123.61.89 (FR-France) http://www.showmyip.com Sat, 04 Sep 2004 06:35:21 GMT (5 of 1500 allowed today) alternate access in XML format at: http://www.showmyip.com/xml alternate access via SOAP at: http://www.showmyip.com/soap/server.php alternate access via RSS feed at: http://www.showmyip.com/rss.php
Cela bien plus d'information que ce dont j'ai besoin !
J'ai fait tout un paquet d'essais avec ce service et je me suis rendu compte du temps que cela prennait et j'ai envisagé le cas où le service serait interrompu pour une raison X ce qui est toujours possible bien qu'improbable. Je voulais une solution définitive. Mon idée était que si mon ordinateur connaît sa propre IP (192.168.0.21) sur le LAN, le routeur qui se trouve à l'intersection du LAN et du WAN connaît l'IP WAN de mon réseau domestique. J'ai fait des recherches sur le moyens de parvenir à récupérer ces données par un hack. Mon modem/routeur DM602 Netgear a une jolie interface web mais elle nécessite une identification administrateur et elle renvoie du code HTML bien compliqué. Cela n'allait pas m'empêcher de trouver les informations dont j'avais besoin en utilisant des techniques avancées d'extraction.
Le code qui suit doit être spécifique au modèle de routeur que j'utilise mais je suis sûr que vous trouverez des moyens de l'adapter à votre situation. J'utilise classiquement le module LWP mais avec les credentials puis j'utilise une expression régulière pour me débarrasser du code HTML superflu. Voila ce que cela donne :
use LWP;
$browser = LWP::UserAgent->new;
$browser->credentials('192.168.0.1:80','DM602','admin'=>'password');
$answer = $browser->get("http://192.168.0.1/PopOutPage?id=2");
$html = $answer->content;
$html =~ /(\d+\.\d+.\d+\.\d+)/;
$ip = $1;
En fait, c'est pas si compliqué. Le gros avantage de cette approche est que les données que j'obtiens sont forcément les plus à jour et je peux les vérifier aussi souvent qu'il me plaît. Pas de quotas ou limitations du nombre de requêtes, pas d'interruption du service, bref, la situation idéale. Pour que mes dévellopements suivants soient plus universels, je vais continuer sans cette méthode de localisation intelligente, ce petit hack d'optention d'IP car il est trop spécifique à la marque et au modèle de routeur que j'utilise.
Mon diffuseur d'IP est relativement simple pour le moment mais j'ai le projet dans un futur incertain de le transformer en un véritable service windows en utilisant le module perl Win32::Deamon. Il tourne sur le PC car pour le moment, RISC OS ne dispose pas encore d'une distribution de perl suffisament complête. Mon choix de méthode de publication est bien évidement le protocole FTP. Mon programe est en perl sans modules exotiques absents d'une distribution classique. Ayant des difficultées avec l'agent de Tâches planifiées de windows, j'ai décidé de faire de mon programe ce que l'on appelle un daemon, c'est à dire une application travaillant en tâche de fond sur une boucle infinie et passant le plus clair de son temps à dormir. Ca peut donner ça :
#!perl -w
use LWP::Simple;
use Net::FTP;
$s = 1;
$pip = "10.0.0.10";
$ip = "192.169.0.1";
until ($s == 2) {
# Fetch the IP
$html = get ("http://simple.showmyip.com");
$html =~ /(\S*)\s/;
$ip = $1;
# Si l'IP a changé alors FTP
if ($ip ne $pip) {
# Ecrire le fichier local
open (FILE, "> F:/ip.txt");
print FILE $ip;
close (FILE);
# Le transfer FTP lui-même
$didit = 1;
$ftp = Net::FTP->new("ftp.myhost.com");
if ($ftp->login("mylogin","mypwd")) {
$ftp->ascii;
$ftp->cwd("/web");
$ftp->put("C:/ip.txt","lanip.txt") or $didit = 0;
$ftp->quit;
} else {
$didit = 0;
}
if ($didit == 1) {
# if ftp transfer seems OK
$pip = $ip;
} else {
# if ftp transfer got wrong, let it try again next time
$pip = "10.0.0.10";
}
unlink ("F:/ip.txt");
}
# Temps de someil du daemon
sleep 60*10;
}
exit(0);
La seule partie intéressante du script est l'expression régulière qui extrait l'IP du résultat de la requête ShowMyIP et le fait que pour économiser de la bande passante, je ne transfère l'IP vers mon hôte que si elle a changé. Notez que si le script n'arrive pas à se connecter au serveur FTP, il remet à zéro la variable de l'IP précédente pour que la prochaine fois qu'il s'active et essaye encore, il pense que c'est une nouvelle IP donc qu'il doit la transférer. En passant je vous dis, car j'ai rencontré ce problème, qu'il peut être une bonne idée de publier l'IP sur un second serveur internet car on n'est jamais sûr de la fiabilité de ces machines distantes. Tant qu'à faire, mieux vaut deux fois qu'une. Dans le même ordre, faire tourner le daemon sur une deuxième machine si possible.
Maintenant je peux trouver quelque part sur internet l'IP de mon LAN à un endroit que moi seul connaîs. Je garde cette addresse secrête pour des raisons de sécurité même si à priori je suis bien protégé. Si mon IP a changé, comme cela arrive au moins une fois par jour, alors il n'y aura qu'un délai maximum de 10 minutes avant que ma nouvelle IP soit présente sur le serveur. J'aurais pu facilement abaisser ce délai à une minute vu le quota accordé par ShowMyIP.com mais je me suis dit qu'il fallait bien se comporter vers à vis de ces gens et réduire le nombre de requêtes. Si vous utilisez ma requête intelligente du paragraphe précédent en obtenant l'IP directement du routeur, alors ne vous privez surtout pas pour réduire le temps de someil de daemon.
Pendant que le PC est occupé à récupérer des données et a les envoyer, je me suis dit qu'il pouvait aussi vérifier que Iyonix vas bien. J'utilise l'excellent StatusD par Chris Williams pour garder un oeil sur ce que fait mon Iyonix pendant que je ne suis pas là. Il génère des statistiques, récupère différentes informations sur ma machine et envoye son rapport sur mon site web en utilisant FTPc. La page web ainsi générée par cette méthode se trouve ici. C'est exactement ce qu'il me faut pour m'assurer que mon Iyonix est en parfait état de fonctionnement et qu'il est prêt à servir des données. Toutefois, j'ai pensé que, dans la mesure où j'ai configuré StatusD pour n'envoyer ses données que tout les 150 minutes, je pouvais bien ajouter quelques lignes à mon diffuseur à des fins de double vérification. Je fais just un ping du PC sur l'Iyonix et je n'écris sur le fichier IP que s'il a quelque chose qui ne vas pas :
use Net::Ping;
$p = Net::Ping->new();
print FILE "Iyonix down " unless $p->ping("192.168.0.21");
$p->close();
Si l'Iyonix avait un support pour la fonction WakeOnLAN et si j'avais des connaissances en domotique, je pourais faire en sorte que mon PC fasse quelque chose pour mon Iyonix en cas de problème, mais pour le moment ce n'est qu'un rêve distant.
Comme l'adresse précise où je stocke mon IP sur internet est censée rester secrête, je dois faire le maximum pour qu'elle le reste. J'ai un téléphone cellulaire Nokia donc je me suis dit que ce serait une bonne idée d'utiliser un service WAP pour obtenir cette IP si précieuse. C'est facile à faire, il suffit de générer un fichier WML et de l'envoyer sur le serveur. WML est encore un de ces languages de markup que je ne connais pas mais je me suis débrouillé pour obtenir un petit truc qui marche. Voilà la structure minimale du fichier que je génère puis transfère :
<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <card id="card1" title="ip"> <p>21.33.161.193</p> </card> </wml>
La première chose que j'ai du changer dans mon installation a été de donner à mon Iyonix un IP fixe sur le LAN plutôt que par DHCP comme je le faisais avant. Ainsi il est beaucoup plus facile de router le trafic vers cette machine. Ensuite, j'ai mis à jour le port forwarding de mon routeur de manière à ce que le flux rentrant du port 143 se dirige vers l'Iyonix car c'est le port du protocole IMAP.
Une fois que j'ai reçu MessengerPro Server de la part de RComp, il suffisait de copier les fichiers par dessus ma copie précédente de MessengerPro et de le configurer en more Messenger Network Server en deux clics de souris. Alors commence une phase de ré-indexation de mes message qui ne pris pas plus d'une minute. C'est tout, prêt à partir. Pour des raisons de sécurité, j'ai donné quand même un mot de passe à mon utilisateur principal sous Messenger. Avant d'aller plus loin, j'ai fait un premier test sur le LAN de mon domicile. Sur Piotr, j'ai lancé Mozilla et configuré la messagerie en IMAP et tout s'est bien passé. La vitesse était impressionante sur mon LAN à 100MB switché, bien que les notes d'installation de RComp font mention d'un avertissement de Castle selon lesquels il y aurait un risque de débordement du réseau à une telle vitesse mais je n'ai rien eût de tel. Maintenant que cela marchait sur le LAN, il faillait passer au mystères du WAN, l'internet grandeur nature.
A ce point, il y a un serveur IMAP tournant à un endroit que moi seul connaîs si tout vas bien. Le temps est peut-être venu enfin de revenir aux idées globales que j'ai eu à propos de toute cette manoeuvre et des choix que j'ai opérés. Comme je voulais accéder à mon mail, je devais conssidérer le pire des cas que je puis imaginer, avoir à faire avec un ordinateur, sous windows par exemple, avec uniquement les logiciels de base et sans aucun droit d'en installer de nouveaux. Je m'imaginais que je n'aurais qu'un navigateur internet et peut-être un client telnet.
Je vous parle d'un client telnet car mon idée première était de faire tourner sur Piotr (vous savez, mon PC) un serveur telnet et d'utiliser aussi un port du meilleur MUA en mode texte dont j'ai entendu parler, Mutt. C'eût été bien car la réputation de Mutt sous linux est excellente. Cela aurait peut-être été délicat à installer car il requiert Cygwin. Ca avait l'air bien malgré tout. C'est domage que je n'ai pas d'ordinateur sous linux sur mon LAN.
Ensuite, j'ai eu des doutes sur la disponibilité d'un client telnet dans mon pire scénario. J'en conclus que je devais m'en tenir au navigateur internet, donc trouver une solution de type webmail pour accéder à mon serveur IMAP. Il y avait deux solutions : la première est de faire tourner un serveur web sur mon LAN (Apache sous windows ou WebJames sous Risc OS) et de lui faire éxécuter un webmail en perl ou en PHP, ou alors de trouver un site sur internet permettant cette connexion.
L'option locale semblait la plus sure et j'avais déjà écrit par le passé un webmail POP3 en perl. Le problème est que le port d'Apache sous windows a mauvaise réputation et que le perl sous Risc OS est trop minimal pour être utilisable mais ce n'est pas cela qui emporta ma décision : Je voulais absolument m'occuper de mes emails privés sous la protection d'une connection cryptée SSL sous https et je n'avais aucune idée de la manière d'opérer cela dans un cadre privé sur mon serveur local. Les certificats nécessaire ne sont pas faciles ni surtout gratuits à obtenir. J'ai donc opté pour la deuxième solution, un site internet de webmail compatible IMAP.
Je n'ai pas cherché longtemps un tel site. J'ai vu qu'il y avait du choix, certes, mais les conseils du support technique de R-Comp m'ont directement orienté vers mail2web.com. Ils semblent avoir une bonne réputation, ils offrent une connection cryptée RC4 128 bit et ils acceptent l'IMAP. J'avais ma solution universelle. Je vais donc sur mail2web.com (qui dispose même d'une interface en français si l'on veut), je choisis advanced login puis secure login, j'entre mon IP, mon login et mon password et je suis connecté à mon courrier. La vitesse est correcte et l'interface bien. Partout dans le monde connecté, je reste un petit peu chez moi même si le confort de mon MUA me manque. J'accède à tout, c'est à nouveau parfait.
Mon utilisation de MessengerPro Server
Après quelques semaines de tests du Japon vers la France, mon conseil est de bien s'assurer que votre machine ne fait fonctionner aucun logiciel présentant un risque de planter ou d'émettre un évenement qui ne soit pas multi-tâche. A distance, la meilleure solution est bien évidement un véritable client IMAP car c'est plus agréable à utiliser qu'un webmail mais c'est bien de savoir que cette solution de rechange existe si l'on a pas le choix. Comme client IMAP j'aurai aimé recommander Mozilla mais au moment où j'écris il y a encore des problèmes quand on accède à des boites d'archives de grande taille, mais une fois de plus n'importe quel client IMAP peut faire l'affaire à partir du moment où il supporte bien la version 4 qui est la plus répandue. Même microsoft Outlook peut être une solution si vous n'avez pas le choix.
A des dizaines de milliers de kilomètres, avec des connexions ADSL standard des deux côtés, la vitesse est encore très bonne et l'usage agréable. La configuration du client IMAP est très facile, il suffit d'entrer l'adresse IP actuelle, le login et le mot de passe. Pour ce qui est du serveur SMTP, je préfère utiliser celui local de l'hôte distant plutôt que de faire appel à la fonction de SMTP relay de MessengerPro pour des raisons de sécurité, même si j'utilise cette option sur mon réseau local avec les restrictions d'IP nécessaires.