Suport technique et veille technologique
Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
- Juillet 2022 -
La lecture d'une excellente étude faite à l'université
de Twente m'a motivé pour faire un court article sur une
question qu'on se pose trop rarement : sur un réseau comme
l'Internet, les
paquets IP passent-il vraiment là où le protocole de
routage, typiquement BGP, leur a dit de passer ?
Je vous divulgâche tout de suite la fin : non. Comme répètent
souvent les administrateurs réseau
anglophones, « The data plane does not always follow the
control plane ». Qu'est-ce que cela veut dire ?
Expliquons un peu le routage, dans un
réseau comme l'Internet : les routeurs se parlent entre eux et
échangent des informations (du genre « Tu sais quoi ? Je sais
comment joindre 2001:db8:fa9:aa3::/64
. ») et
ces informations échangées leur servent à construire leur
table de routage, une structure de données qui
associe aux préfixes IP (comme ce
2001:db8:fa9:aa3::/64
), l'adresse du routeur
suivant, celui qui rapprochera le paquet du
but. Ensuite, lorsqu'un routeur reçoit un paquet, il consulte sa
table de routage et envoie le paquet au routeur suivant, via la
bonne interface. Deux choses sont à noter :
- Il y a deux processus distincts, le
routage (routing en
anglosaxonien, construire la table avec les informations reçues
par des protocoles de routage comme Babel
- RFC 8966), et la
transmission (forwarding
dans la langue de Perlman, envoyer le paquet). Ces deux
processus utilisent des protocoles très différents, n'ont pas les
mêmes contraintes (par exemple, la transmission est
temps-réel, avec des contraintes très
serrées) et, dans un routeur haut de gamme, ces deux processus
sont accomplis par des composants du routeur qui sont très
différents.
- La responsabilité du routeur s'arrête une fois qu'il a
transmis le paquet. Il ne peut pas indiquer au routeur suivant ce
qu'il doit faire, et ne peut même pas connaitre la décision de
celui-ci. C'est ce qu'on nomme le routage par étapes indépendantes
(hop by hop).
Sur l'Internet, le protocole de routage standard est BGP (RFC 4271). Les annonces BGP ont la forme « je sais joindre
2001:db8:fa9::/48
et je le sais parce que
l'AS 64500 me l'a
dit et il le tenait de l'AS 65539 ». Mais, du fait du routage par
étapes indépendantes, rien ne dit qu'un paquet envoyé au routeur qui
a fait cette annonce ira bien à l'AS 64500 puis à l'AS 65539. Chaque
AS (en pratique, un
AS = un opérateur) est indépendant et a sa propre politique de
routage. Par exemple, l'administratrice du routeur suivant a
parfaitement pu configurer des routes statiques prioritaires, qui
seront utilisées avant celles apprises via BGP. C'est le sens de la
phrase « The data plane does not always follow the control
plane ». « The data plane », c'est IP,
c'est la transmission. « The control plane »,
c'est le protocole de routage, par exemple BGP.
L'étude
de Koen van Hove citée plus haut est une illustration
pratique de ce point (je vous en recommande vraiment la
lecture). L'auteur travaille sur la validation de l'origine des
routes (ROV, pour Route Origin Validation), via
la RPKI
(Resource Public Key Infrastructure). Les
titulaires de préfixes IP publient (et
signent) des ROA (Route Origin
Authorization) qui indiquent quel AS peut être à l'origine
d'une route (dans l'exemple plus haut, 65539 était l'origine). Les
routeurs connectés à l'Internet peuvent utiliser ces ROA pour
valider les annonces. Si on trouve un ROA correctement signé qui dit
« 2001:db8:fa9::/48
doit avoir comme AS
d'origine 65539 » et qu'une annonce
« 2001:db8:fa9::/48
passe par moi et ça vient
de l'AS 65500, qui en est l'origine », une telle annonce, invalide,
peut être rejetée.
Est-ce que cela suffit à garantir la sécurité du routage ? Non,
car, montre l'étude, même si on rejette cette annonce invalide, les
paquets qu'on émet sont transmis à des AS différents et ceux-ci
peuvent avoir d'autres règles et, par exemple, ne pas valider. Donc,
le malheureux paquet destiné à
2001:db8:fa9:b3:551::12:af8
sera peut-être
finalement transmis au méchant AS 65500. C'est ennuyeux, mais c'est
logique, chaque AS étant maitre de sa politique de routage.
Mais est-ce qu'on ne pourrait pas changer cela et « forcer » les
AS à respecter des décisions prises par l'émetteur du paquet ? (Ce
qu'on nomme le routage par la source.) Non, on ne peut pas, et le
problème n'est pas technique (il existe plusieurs mécanismes pour
représenter de telles décisions dans les paquets), mais d'ordre
commercial et politique. En termes simples, les autres opérateurs
font ce qu'ils veulent, et ils n'ont pas de raison de vous
obéir. (Il faut se rappeler que l'Internet est une fédération de
réseaux, pas un réseau unique.) Ils ont d'autant moins de raisons
d'obéir à d'éventuelles consignes de l'émetteur que celles-ci
permettraient des attaques contre la sécurité, par exemple en
forçant le passage par un chemin qu'un attaquant sait moins
contrôlé.
RFC 9562: Universally Unique IDentifiers (UUIDs)
- 12 mai -
Ce RFC normalise les UUID, une famille d'identificateurs uniques, obtenus sans registre central. Il remplace l'ancienne norme, le RFC 4122, avec (...)
RFC 9490: Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
- 9 mai -
Aujourd'hui, l'essentiel du trafic sur l'Internet est chiffré, et pour d'excellentes raisons. Pas question de revenir là-dessus, mais, ceci dit, il (...)
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
- 29 avril -
Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout, permettant d'y attacher (...)
RFC 9567: DNS Error Reporting
- 27 avril -
Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de résoudre les noms dans cette zone, il n'avait pas de moyen simple et (...)
RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- 8 avril -
Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)