Looking for Computer Science & Information Technology online
courses ?
Check my new web site: https://www.yesik.it !
Ça y est: vous avez installé OpenWrt sur une machine! Avant d'aller plus loin et de vous atteler à la configuration spécifique que vous voulez pour celle-ci, il y a tout d'abord quelques pas à faire systématiquement. Rien de long ou de compliqué. Mais je préfère les résumer ici afin de ne rien oublier et de partir du bon pied. J'en profiterai au passage pour introduire uci et opkg qui sont les commandes de base pour l'administration et la personnalisation d'un système OpenWrt.
Sommaire
Point de départ
Pour cet article, je reprends les choses juste après l'installation (le flashage) d'OpenWrt. Quelque soit la manière employée, vous vous retrouvez donc avec une cible qui va booter pour la première fois sous OpenWrt.
Par défaut, sous Backfire, un certain nombre de services sont disponibles dès ce premier boot. Et il est possible d'utiliser plusieurs moyens pour ouvrir une session sur votre cible et interagir avec. Ainsi, si vous avez accès à la console série de votre cible, vous pouvez utiliser un émulateur de terminal comme screen. J'ai déjà expliqué cette technique ailleurs. Souvenez vous juste que par défaut sous OpenWrt, pour ouvrir un shell root à partir de la console il suffit de presser entrée – sans login ni mot de passe.
Mais laissons la console série de côté: en effet, je vais plutôt considérer le cas d'une cible dotée d'un port Ethernet. Normalement OpenWrt a dû le détecter et l'activer. Reliez donc votre ordinateur à votre cible par une liaison Ethernet. L'adresse IPv4 par défaut de la cible est 192.168.1.1. Si votre cible est dotée de plusieurs ports Ethernet (cas d'un routeur, par exemple) c'est le port LAN qui possède cette adresse. Le port WAN étant configuré pour obtenir une adresse par DHCP. Un ping(8) vous permettra de vous assurer que vous êtes connecté au bon port:
# Vérifier la connectivité entre l'ordinateur et la cible sh$ ping -c 3 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=0.320 ms 64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.305 ms 64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=0.322 ms --- 192.168.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.305/0.315/0.322/0.021 ms
Liste des services initiaux
Dès que la cible répond, nous pouvons pousser un peu plus nos investigations en utilisant nmap pour découvrir les ports ouverts:
sh$ nmap 192.168.1.1 Interesting ports on 192.168.1.1: Not shown: 996 closed ports PORT STATE SERVICE 22/tcp open ssh 23/tcp open telnet 53/tcp open domain 80/tcp open http
Voilà qui est intéressant: en standard, sur une installation neuve d'OpenWrt, l'administration est possible par ssh, telnet et http (interface Web LuCI). On peut aussi voir qu'un serveur DNS est à l'écoute sur cette interface (port 53).
Accès par telnet
Attention:
À ce stade, l'accès administrateur à votre cible OpenWrt est ouvert à tous! N'importe qui pouvant y accéder par le réseau peut vous prendre de vitesse pour s'y connecter. Par ailleurs, puisque nous allons utiliser telnet pour changer le mot de passe, et que le trafic telnet passe en clair, il y a aussi un risque d'interception du mot de passe administrateur...
Pour ces deux raisons, je vous conseille de relier directement la cible à votre ordinateur – sans passer par le réseau local. Ce n'est qu'une fois l'accès SSH opérationnel et l'adresse réseau définitive assignée à votre cible que vous pourrez la mettre sur le réseau.
À ce stade, on ne peut pas accéder à OpenWrt par ssh car le serveur est configuré pour refuser les connexions sans mot de passe. Or, pour l'instant root n'a toujours pas de mot de passe sur la cible. Par conséquent, la connexion initiale ne peut donc se faire que par telnet (ou la console série):
sh$ telnet 192.168.1.1 Trying 192.168.1.1... Connected to 192.168.1.1. Escape character is '^]'. === IMPORTANT ============================ Use 'passwd' to set your login password this will disable telnet and enable SSH ------------------------------------------ BusyBox v1.15.3 (2011-07-07 02:30:22 CEST) built-in shell (ash) Enter 'help' for a list of built-in commands. _______ ________ __ | |.-----.-----.-----.| | | |.----.| |_ | - || _ | -__| || | | || _|| _| |_______|| __|_____|__|__||________||__| |____| |__| W I R E L E S S F R E E D O M Backfire (10.03.1-RC5, r27608) -------------------------- * 1/3 shot Kahlua In a shot glass, layer Kahlua * 1/3 shot Bailey's on the bottom, then Bailey's, * 1/3 shot Vodka then Vodka. --------------------------------------------------- root@OpenWrt:/#
Un message d'avertissement vous le rappelle: il est important de donner un mot de passe pour l'administrateur de votre machine sous OpenWrt. Si vous avez ne serait-ce qu'un peu utilisé un autre système Unix-like vous connaissez la commande passwd qui permet de changer de mot de passe. C'est tout ce que nous ferons avec cette session telnet:
root@OpenWrt:/# passwd Changing password for root New password: ********* Retype password: ********* Password for root changed by root root@OpenWrt:/# exit Connection closed by foreign host.
Remarque:
Comme indiqué également dans le message à l'ouverture de la session telnet, une fois le mot de passe root défini, il ne sera plus possible de se connecter à la cible par telnet.
En réalité, le serveur telnet tournera toujours sur la cible sous OpenWrt jusqu'au prochain reboot, mais il fermera instantanément les connexions.
Accès par ssh
Dès que le mot de passe root est défini, il devient possible d'utiliser SSH (Secure Shell) pour se connecter à la cible OpenWrt. La console série reste opérationnelle, mais plus l'accès par telnet. Désormais, ce sera uniquement par ssh que j'accèderai à ma cible. Comme toujours, lors de la première connexion, le client ssh vous demandera de valider l'identité de la machine à laquelle vous vous connectez. Pour éviter tout risque d'attaque man-in-the-middle, cette première connexion par ssh se fera donc de préférence avec une liaison directe entre la cible et votre ordinateur:
sh$ ssh root@192.168.1.1
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
RSA key fingerprint is 6a:cb:5c:56:77:60:1d:41:ba:0a:25:ce:2f:11:e7:c2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.1' (RSA) to the list of known hosts.
root@192.168.1.1's password: *********
BusyBox v1.15.3 (2011-07-07 02:30:22 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
Backfire (10.03.1-RC5, r27608) --------------------------
* 1/3 shot Kahlua In a shot glass, layer Kahlua
* 1/3 shot Bailey's on the bottom, then Bailey's,
* 1/3 shot Vodka then Vodka.
---------------------------------------------------
root@OpenWrt:~#
À partir de maintenant, vous pouvez vous connecter à la cible de manière sécurisée et cryptée. Et par ailleurs, vous êtes en mesure de vérifier l'identité de celle-ci à la connexion. Par contre, il va encore falloir attendre de lui donner une adresse satisfaisante avant de la placer à son emplacement définitif sur le réseau...
Configurer l'adresse IP de la cible
Par défaut, l'adresse IPv4 d'usine du port LAN d'une cible OpenWrt est 192.168.1.1. C'est l'adresse que nous avons utilisée jusqu'ici. Mais pas nécessairement une adresse adaptée à votre réseau. Une tâche de base de la configuration de toute cible est donc de fixer son adresse. Et accessoirement de lui fournir d'autres informations sur votre réseau telles que l'adresse de la passerelle, le masque de réseau, l'adresse du serveur DNS, etc.
Pour la configuration d'OpenWrt, je vais utiliser ici UCI (Unified Configuration Interface – Sous OpenWrt, l'outil d'administration en ligne de commande introduit par backtrace) . À partir de Backfire, UCI est l'outil de configuration standard pour OpenWrt. C'est une surcouche qui permet de modifier les fichiers de configuration situés sous /etc/config. UCI fonctionne en ligne de commande. C'est donc un outil adapté si vous vous connectez à votre cible par ssh ou par la console série. Il se révèle également pratique pour lire ou modifier la configuration à partir de scripts. Comme vous le verrez ci-dessous, la commande uci set permet de modifier une option de configuration. Les différentes options modifiées ici s'expliquent d'elles-même:
root@OpenWrt:~# uci set network.lan.proto=static root@OpenWrt:~# uci set network.lan.ipaddr=10.129.38.123 root@OpenWrt:~# uci set network.lan.netmask=255.255.255.0 root@OpenWrt:~# uci set network.lan.gateway=10.129.38.99 root@OpenWrt:~# uci set network.lan.dns=10.129.36.245
Dans uci, une option est identifiée par un triplet contenant le nom du fichier de configuration, la section correspondante dans le fichier, et finalement par le nom de l'option. Toutes les options ci-dessus correspondent dont à des options de la section lan du fichier /etc/config/network. On peut retrouver ces options en examinant directement le fichier de configuration – et accessoirement les modifier directement dans ce fichier:
root@OpenWrt:~# cat /etc/config/network
[...]
config 'interface' 'lan'
option 'ifname' 'eth0.1'
option 'type' 'bridge'
option 'proto' 'static'
option 'ipaddr' '192.168.1.1'
option 'netmask' '255.255.255.0'
[...]
Cette petite digression au sujet des fichiers de configuration me permet de vous montrer que les modifications faites avec uci set ne sont pas immédiatement appliquées. En effet, le fichier de configuration contient encore les anciennes valeurs. Pas celles que j'ai modifiées à avec uci set. Pour que les modifications soient propagées, il faut utiliser uci commit. Mais avant d'appliquer les changements, vous pouvez vérifier les paramètres modifiés afin de vous assurer qu'il n'y a pas d'erreur:
root@OpenWrt:~# uci changes network.lan.ipaddr=10.129.38.123 network.lan.gateway=10.129.38.99 network.lan.dns=10.129.36.245
Ici, je constate que network.lan.proto et network.lan.netmask n'apparaissent pas dans la liste des modifications. C'est simplement qu'ils avaient déjà les mêmes valeurs. En cas de doute, il est possible aussi d'interroger uci pour obtenir la valeur de ces options:
root@OpenWrt:~# uci get network.lan.proto static root@OpenWrt:~# uci get network.lan.netmask 255.255.255.0
Piège:
uci get renvoie la valeur actuellement configurée d'une option. Pas sa valeur en cours. Ainsi, pour l’instant, ma cible a toujours pour adresse LAN 192.168.1.1, mais uci get renvoie la valeur configurée:
root@OpenWrt:~# uci get network.lan.ipaddr 10.129.38.123
Par ailleurs, comme nous l'avons vu plus haut, c'est toujours l'ancienne valeur qui est stockée dans le fichier de configuration. Cela crée une petite fenêtre d'incohérence pendant laquelle un même paramètre est susceptible d'avoir une valeur différente selon qu'un programme utilise la valeur courante, celle contenue dans un des fichiers du répertoire /etc/config ou uci get.
Quand vous êtes convaincu que les nouvelles valeurs sont correctes, il reste à appliquer les changements:
root@OpenWrt:~# uci commit
Vous serez peut-être surpris de constater que la liaison ssh est toujours opérationnelle. Ce qui ne devrait pas être le cas si l'adresse a réellement changé. Pour être tout à fait précis, uci commit se contente de propager les modifications aux fichiers de configuration standard des services concernés. Ces modifications ne sont pas nécessairement prises en compte automatiquement. Ainsi, dans le cas des services réseau, il est nécessaire de demander explicitement de relire la configuration:
root@OpenWrt:~# /etc/init.d/network reload
Note:
On peut aussi redémarrer un service:
root@OpenWrt:~# /etc/init.d/network restart
Ici, la connexion ssh devrait apparaitre bloquée: c'est normal, votre cible a changé d'adresse. Comme le client ssh ne se rend pas immédiatement compte que la connexion est rompue, vous devrez y mettre fin manuellement en pressant ↵;~. (return tilde point) Au pire, vous pouvez aussi simplement fermer la fenêtre...
Toujours est-il que pour continuer à configurer votre cible, vous devrez ouvrir une nouvelle session ssh en la contactant à sa nouvelle adresse. Ce qui fera croire à ssh que c'est une nouvelle machine – et donc va requérir que vous validiez son identité:
sh$ ssh root@10.129.38.123
The authenticity of host '10.129.38.123 (10.129.38.123)' can't be established.
RSA key fingerprint is 6a:cb:5c:56:77:60:1d:41:ba:0a:25:ce:2f:11:e7:c2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.129.38.123' (RSA) to the list of known hosts.
root@10.129.38.123's password: *********
BusyBox v1.15.3 (2011-07-07 02:30:22 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
Backfire (10.03.1-RC5, r27608) --------------------------
* 1/3 shot Kahlua In a shot glass, layer Kahlua
* 1/3 shot Bailey's on the bottom, then Bailey's,
* 1/3 shot Vodka then Vodka.
---------------------------------------------------
root@OpenWrt:~#
Enfin, si vous le souhaitez, vous pouvez placer votre cible à son emplacement définitif sur le réseau: en effet, celle-ci est maintenant accessible en toute sécurité par ssh via son adresse définitive.
Accès internet
Par Ethernet
Si vous avez configuré l'accès au réseau local comme décrit précédemment et qu'Internet est accessible via la passerelle indiquée sur ce réseau local, votre routeur devrait déjà avoir l'accès Internet:
root@OpenWrt:~# ping -c 3 www.openwrt.org PING www.openwrt.org (78.24.191.177): 56 data bytes 64 bytes from 78.24.191.177: seq=0 ttl=45 time=79.416 ms 64 bytes from 78.24.191.177: seq=1 ttl=45 time=79.388 ms 64 bytes from 78.24.191.177: seq=2 ttl=45 time=81.007 ms --- www.openwrt.org ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 79.388/79.937/81.007 ms
Le succès de ce ping démontre que la passerelle et le serveur de nom (DNS) sont tous deux accessibles par votre cible. En cas d'échec, vérifiez l'adresse de la passerelle (network.lan.gateway) et celle du serveur DNS (network.lan.dns). La commande uci show qui affiche l'arborescence des options d'une section peut aider ici:
root@OpenWrt:~# uci show network.lan network.lan=interface network.lan.ifname=eth0.1 network.lan.type=bridge network.lan.proto=static network.lan.netmask=255.255.255.0 network.lan.ipaddr=10.129.38.123 network.lan.dns=10.129.36.245 network.lan.gateway=10.129.38.99
Piège:
Un piège dans lequel je suis tombé, c'est que uci set n'est pas en mesure de vérifier la validité d'une option. Cela veut dire que vous êtes à la merci d'une faute de frappe. Par exemple, lors de la rédaction de cet article, je me suis creusé la tête un moment pour savoir pourquoi OpenWrt ne voulait pas utiliser la passerelle comme route par défaut. Voici ce que montrait uci show:
root@OpenWrt:~# uci show network.lan network.lan=interface network.lan.ifname=eth0.1 network.lan.type=bridge network.lan.proto=static network.lan.netmask=255.255.255.0 network.lan.ipaddr=10.129.38.123 network.lan.dns=10.129.36.245 network.lan.getaway=10.129.38.99
Tout semblait en ordre, jusqu'à ce que je remarque enfin que j'avais orthographié getaway au lieu de gateway. Une fois cela constaté, la correction était rapide:
root@OpenWrt:~# uci del network.lan.getaway root@OpenWrt:~# uci set network.lan.gateway=10.129.38.99 root@OpenWrt:~# uci commit root@OpenWrt:~# /etc/init.d/network reload
Si votre cible dispose d'un port WAN – comme dans le cas par exemple d'un routeur – vous préfèrerez peut-être utiliser celui-ci pour l'accès externe. Dans ce cas, il vous faudra reprendre les commandes de la section précédente, mais en remplaçant lan par wan:
root@OpenWrt:~# uci set network.wan.proto=static root@OpenWrt:~# uci set network.wan.ipaddr=10.129.39.123 root@OpenWrt:~# uci set network.wan.netmask=255.255.255.0 root@OpenWrt:~# uci set network.wan.gateway=10.129.39.99 root@OpenWrt:~# uci set network.wan.dns=10.129.36.245
Si vous configurez à la fois le port LAN et le port WAN, vous souhaiterez sans doute les placer sur des réseaux différents. Ainsi, dans mon exemple, le LAN est sur le réseau 10.129.38.0/24 et le WAN sur 10.129.39.0/24.
Par modem interne
N'ayant pas le matériel nécessaire, je n'ai pas pu tester ces manipulations. Je me contenterai donc de vous renvoyer aux documentations correspondantes du site OpenWrt.org:
- Pour un accès xDSL
- voir PPP, PPPoE ou PPPoA. Cette dernière possibilité est sans doute à considérer si votre cible intègre un modem ADSL.
- Pour un accès câble (DOCSIS)
- je ne pense pas qu'il y ait de support spécifique pour cette technologie. La solution est de se connecter au modem de votre fournisseur d'accès par une liaison Ethernet.
- Pour un accès mobile (HSDPA/UMTS/EDGE/GPRS/GSM)
- voir 3G.
Dans tous les cas, vous souhaiterez peut-être configurer la cible pour partager l'accès Internet au travers d'un NAT.
Changer le nom d'hôte de la cible
Vous pouvez changer le nom d'hôte de votre cible en jouant sur l'option hostname de la configuration system:
root@OpenWrt:~# uci set system.@system[0].hostname='MyTarget' root@OpenWrt:~# uci commit
La modification ne sera effective qu'au redémarrage de la cible.
root@OpenWrt:~# reboot
Ceci dit, vous pouvez différer de quelques minutes ce redémarrage, le temps de configurer l'heure et le fuseau horaire, comme nous allons le faire maintenant.
Réglez la date et l'heure
Par défaut, OpenWrt utilise NTP sur le port WAN pour régler l'heure du système. Si votre accès Internet est plutôt sur le port LAN, vous devrez modifier l'option system.@rdate[0].interface:
root@MyTarget:~# uci set system.@rdate[0].interface=lan root@MyTarget:~# uci commit root@MyTarget:~# /etc/init.d/network restart
Dans tous les cas, vous souhaiterez sans doute configurer le fuseau horaire (timezone). Vous trouverez un tableau des codes de fuseau horaire sur le site d'OpenWrt. Pour ne citer que quelques exemples, Paris, Bruxelles, Zurich et Monaco sont sur le fuseau CET-1CEST, Montréal est sur EST5EDT, Casablanca est sur WET0 et Dakar est sur GMT0.
Pour ma part étant en France métropolitaine, donc sur le même fuseau horaire que Paris, j'ai modifié ma configuration ainsi:
root@MyTarget:~# uci set system.@system[0].timezone=CET-1CEST
Comme pour le nom d'hôte, le changement de fuseau horaire ne semble pris en compte qu'au redémarrage de la cible:
root@MyTarget:~# reboot
Supprimer l'interface web
Pour terminer, je vais profiter de cet article pour introduire opkg, l'outil de gestion de paquets d'OpenWrt. Comme ses homologues apt-get, yum, etc. d'autres distributions Linux, opkg permet d'installer et désinstaller des packets tout en vérifiant les dépendances entre paquets afin d'assurer la cohérence du système.
Pour rapidement illustrer l'utilisation de ce programme, voici comment désinstaller LuCI sur votre cible OpenWrt, si, comme moi, vous préférez utiliser ssh pour administrer votre machine plutôt que l'interface web. Quelques tâtonnements m'ont permis de déterminer que luci-lib-core est le paquet de base desquels tous les autres paquets de LuCI dépendent. Et, comme vous le constaterez, j'utilise l'option --force-removal-of-dependent-packages pour demander à opkg de supprimer également les paquets qui dépendent de luci-lib-core:
root@MyTarget:~# opkg remove luci-lib-core --force-removal-of-dependent-packages Removing package luci-app-firewall from root... Removing package luci-mod-admin-full from root... Removing package luci-mod-admin-core from root... Removing package luci-theme-openwrt from root... Removing package luci-theme-base from root... Removing package luci-lib-web from root... Not deleting modified conffile /etc/config/luci. Removing package luci-lib-nixio from root... Removing package luci-lib-core from root...
Et puisque LuCI est désinstallé, plus besoin non plus du serveur web uhttp:
root@MyTarget:~# opkg remove uhttpd Removing package uhttpd from root...
Remarque:
En plus de l'ajout et de la suppression de paquets, opkg supporte aussi la sous-commande opkg upgrade pour faire des mises à jour de paquets déjà installés. Mais, contrairement à ce que vous faites avec vos distributions Linux habituelles, ce n'est pas conseillé sous OpenWrt.
L'explication réside dans l'organisation de la mémoire sous OpenWrt: en effet, dans la majeure partie des installations, le système installé avec le firmware l'est dans une partition SquashFS. Ce type de partition a pour avantage un grand taux de compression. Mais il est en lecture seule. Pour donner l'illusion que le système peut être modifié, OpenWrt utilise un système d'overlay qui s'apparente à un système de copy-on-write: l'overlay contient essentiellement toutes les différences entre le système de fichier courant et celui qui a été flashé lors de l'installation d'OpenWrt – la partition SquashFS restant toujours identique à ce qu'elle était à l'installation [1]. Si vous êtes curieux, sur votre cible, le système SquashFS est accessible à partir du point de montage /rom. Alors que le contenu de l'overlay l'est à partir du point de montage /overlay. En comparant les deux, vous constaterez que l'overlay contient bien tous les fichiers modifiés ainsi que des informations supplémentaires concernant les fichiers supprimés.
Ainsi, supprimer ou modifier un fichier du système de base ne libère pas de place sur celui-ci, mais en occupe sur l'overlay. La mise à jour des paquets d'une installation OpenWrt est donc susceptible de consommer une place non négligeable sur le système d'overlay.
Par conséquent, si vous envisagez de supprimer de nombreux paquets ou de basculer sur des versions plus récentes, il sera préférable de compiler un nouveau firmware OpenWrt personnalisé puis de l'installer sur la cible.
