Ours & Hippy — le blog [crous]

Arrivé sur Grenoble, j’étais tout content de découvrir que le CROUS m’offrait gratuitement l’accès à Internet par le biais de Renater et d’installations Wifi. J’ai vite déchanté en voyant la qualité de la connexion. Autant le débit est tout à fait acceptable pour une connexion partagée (il va de soi qu’en téléchargement montant vous n’avez rien ou presque, ceci dit), autant la stabilité de la connexion laisse tout à fait à désirer.

Ce petit guide sans prétention vous fait part de mon expérience avec ce réseau capricieux ainsi que mes petites astuces sur comment y survivre malgré tout.

Avant d’entrer dans le vif du sujet

Je tiens à préciser que ceci n’est pas un guide de configuration (mais plutôt de dépannage), parce que j’estime qu’il y en a déjà suffisamment sur la Toile, mais surtout parce que j’ai la flemme !

Afin de vous donner quelques pistes de recherche, toutefois, voici les programmes dont vous aurez besoin pour faire tourner la machine. Mieux vaut les avoir préparés avant d’atterrir sur le campus !

• Un noyau qui supporte votre carte Wifi, c’est bête mais…

• wpa_supplicant, pour établir la connexion avec les points d’accès du CROUS. En vérité, celle-ci s’opère sans authentification (déléguée au VPN), mais wpa_supplicant, malgré son nom, gère également les réseaux en WEP, ou sans sécurité aucune. Entre autres, il permet de gérer plusieurs réseaux alternatifs, ce qui permet de faire cohabiter votre réseau à la maison familiale, pour quand vous rentrez chez vous, avec celui de votre école (p.ex. l’Ensimag a son propre réseau), et celui du CROUS, par exemple.

  Vous pourriez être tenté d’utiliser quelque chose comme NetworkManager. Si tel est le cas, sachez que ce guide ne vous sera pas d’une grande utilité, car ce logiciel a tendance à masquer toutes les manipulations que je présente ici, et je ne saurais dire si les commandes que je donne auront les effets escomptés en présence de NetworkManager.

• dhclient (ou un autre client DHCP), sans quoi vous aurez une connexion sans avoir d’IP…

• vpnc, le client libre compatible avec les réseaux VPN de Cisco. Le client officiel, sous licence propriétaire, est à la fois instable et indisponible sous BSD.

• OpenSSH, si vous souhaitez utiliser des tunnels (et si vous avez un serveur pour les héberger, celui de votre école peut faire l’affaire). Si votre utilisation d’Internet ne se limite pas au Web, vous en aurez sans doute besoin.

Le VPN (Very Private Network)

Il y a beaucoup de gens qui appréhendent l’usage de cette chose qu’est le VPN, alors qu’en vérité, les problèmes commencent après. L’usage du VPN est simple, il suffit de suivre les divers guides (disponibles pour Linux et Unix !) mis à votre disposition, ou de demander à quelqu’un du service informatique de votre école. Ou encore, plus simplement, il vous suffit d’installer vpnc (p.ex. via le gestionnaire de paquets de votre distribution Linux), et de récupérer les paramètres du réseau VPN, voire un fichier de configuration déjà fait (ne pas oublier de le convertir, s’il est au format Cisco VPN, avec pcf2vpnc).

Limitations explicites du réseau

Officiellement, vous êtes encouragé à vous limiter à des activités purement scolaires au sein du réseau ; certains manuels sont plus indulgents et parlent de trafic personnel raisonnable. Il va de soi que je ne vous conseille pas de faire de gros téléchargements depuis le réseau du campus ; ce serait une perte de temps pour vous et un dérangement pour les autres.

Cependant, la tentative de contrôle imposée par l’administration du réseau, consistant à bloquer certains ports en sortie, peut être très gênante pour un nombre de choses utiles, notamment vous connecter en SSH à votre serveur à votre domicile familial, par exemple pour faire une sauvegarde de vos données importantes (on n’est jamais trop prudent). Le FTP ne marche d’ailleurs pas mieux.

Sessions et tunnels SSH

Si votre école vous offre un environnement moins restrictif (et c’est mon cas, avec l’Ensimag),^α vous pouvez vous connecter en SSH là-bas pour ensuite faire vos petites manipulations. Ou vous pouvez créer un tunnel SSH. Si vous ne connaissez pas, il s’agit de l’option -L de la ligne de commande ou LocalForward du fichier de configuration.

Par exemple :

$ ssh -L 2806:chez.moi:22 telesun

sshd sur un autre port

Si vous avez un peu de contrôle sur votre réseau à votre domicile et que le port 80 n’est utilisé par rien d’autre, simplement faire écouter sshd sur celui-ci marche bien et le réseau du campus ne bronche pas quand vous parlez SSH sur le canal normalement réservé au HTTP.

Vous pouvez également utiliser le port 443, celui d’HTTPS, qui est également ouvert, sur le réseau du campus, si cela vous convient mieux. C’est ce que je fais.

Améliorations : clés SSH et ssh-agent

Honnêtement, si vous prévoyez d’utiliser massivement SSH, pour rediriger votre trafic sur une machine qui vous permet d’accéder à des services indirectement, je vous conseille vivement de vous créer une paire de clés publique/privée et un compte dédié sur votre serveur, acceptant ces clés, dénué de tout droit et servant uniquement à la mise en place du tunnel.

Une alternative, si l’idée d’un tel compte vous semble inacceptable, est d’utiliser ssh-agent, pour n’avoir à taper votre passphrase qu’une seule fois.

Vous pouvez même pousser le vice plus loin en ajoutant le module d’authentification PAM pam_ssh à la configuration de votre gestionnaire de connexion (si bien sûr il utilise PAM). Il s’agit d’inclure une ligne de ce genre au début du fichier du service PAM concerné :

auth	sufficient	pam_ssh.so	no_warn try_first_pass

pam_ssh vous permet de taper votre passphrase en guise de mot de passe de connexion et se charge de lancer ssh-agent pour vous. Que demander de plus ?

Problèmes avec le Wifi

Des problèmes avec le Wifi, j’en ai rencontré un certain nombre : les deux plus agaçants étant, en grand numéro 1, les fréquentes déconnexions, suivi, de très loin par le débit qui décroît parfois assez violemment.

Régulièrement, le VPN ou le Wifi, ou les deux, va périr. Pour diagnostiquer la panne, plusieurs méthodes. Aucune n’est 100% fiable, mais elles donnent toutes des informations utiles, selon le cas.

1. Le premier réflexe est de regarder la liste des processus. Si certains manquent, vous savez d’où vient le problème…

2. Un autre moyen de dépister le problème (dans le cas du Wifi, ça ne marche évidemment pas pour le VPN), et qui est peut-être meilleur (entendez par là qu’il s’agit peut-être du problème le plus courant), est d’utiliser wpa_cli status. Regardez par exemple la ligne wpa_state.

3. Si cela ne résout pas le problème, la netstat -r peut vous aider à y voir plus clair : ils permettent d’identifier les chemins (littéralement « itinéraires », routes en anglais) empruntés par les paquets du réseau.

   En temps normal, vous devriez voir une interface tun (le tunnel VPN) et une interface correspondant à votre carte Wifi (p.ex. wlan sous Linux, ou wpi pour ma carte Intel sous NetBSD).

   En cas de problème, certains chemins au réseau peuvent disparaître. Si l’interface tun n’est plus présente, c’est vpnc qui est mort. Si c’est l’interface de votre carte Wifi, c’est le Wifi qui est en cause.

   Un autre problème assez courant est que certains chemins demeurent alors même que la connexion est morte ou a changé. Les symptômes sont typiquement : vous êtes connecté et wpa_cli status vous retourne des informations crédibles mais vous ne pouvez accéder à aucun autre hôte du réseau, même pas votre passerelle ou vos serveurs DNS. Dans ce cas, il faut supprimer les chemins erronés avec route del (Linux) ou route delete (NetBSD) (généralement la passerelle par défaut, default, suffit) et rétablir la connexion.

4. Enfin, un simple ping sur TCP (ICMP est bloqué, vous pouvez utiliser par exemple echoping) peut également vous être utile pour apprécier l’état général de la connexion.

Solutions

Si c’est vpnc, il suffit de le relancer, en revanche, si c’est le Wifi (et il m’a fallu pas mal de temps pour m’en rendre compte), c’est probablement que vous avez été déconnecté et qu’en même temps, votre liste de points d’accès s’est vidée ! La solution ? Rescanner la liste des points d’accès, avec par exemple :

# wpa_cli scan

Quelques fois, wpa_cli status vous indiquera un état valide (ASSOCIATED) mais vous n’aurez aucune IP attribuée : relancer le client DHCP peut être nécessaire. La plupart du temps, il s’agit de dhclient, mais selon le système, cette démarche peut être couplée avec le redémarrage du service réseau tout entier : par exemple, /etc/init.d/net.wlan0 restart sous Gentoo mais simplement /etc/rc.d/dhclient restart sous NetBSD.

Quant au problème de débit misérable, si iwconfig (sous Linux) ou autre wlanctl (sous NetBSD) vous indique un [Bit] rate minable, vous pouvez sans doute y remédier avec un wpa_client reassociate.

Automatiser le processus

Toute cette surveillance est fastidieuse et l’on est vite tenté de vouloir l’automatiser. Cela peut se faire par exemple avec un script tournant en fond qui échantillonne périodiquement l’état de la connexion et tente de remédier aux problèmes.

Ce n’est pas une tâche aisée, cependant, car le diagnostic peut être délicat. Un petit script peut toutefois du moins vous épargner de retaper les trois ou quatre commandes servant à relancer l’ensemble des services nécessaires.

Je vous mets à disposition mes deux petits scripts pour NetBSD, qui sont très loin d’être parfaits (je me retrouve de temps en temps à devoir faire sudo do_wifi all à la main), mais qui peuvent servir de point de départ ou de source d’inspiration pour élaborer les vôtres. :)

do_wifi

Le script principal.

do_sshtunnel

Trois lignes de shell qui démarrent mon tunnel SSH.

Fin

Bah voilà, c’est fini et c’est la vie, mais avec ça et un peu de documentation, vous devriez avoir une connexion Internet correcte sur le campus, si ce n’était pas déjà fait, mais cette fois, aux frais du CROUS.