Greboca  

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.

Blog de Stéphane Bortzmeyer  -  RFC 7488: PCP Server Selection

 -  Mars 2015 - 

Le protocole PCP décrit un mécanisme (ayant vocation à remplacer UPnP) pour configurer automatiquement son routeur/pare-feu, notamment pour autoriser les connexions entrantes. Que doit faire un client PCP s'il reçoit plusieurs adresses IP de serveurs PCP ?

Dans quels cas a-t-on plusieurs serveurs PCP (donc, a priori, plusieurs routeurs à sa disposition) ? Un exemple typique est le multi-homing, si une machine est connectée en filaire et en radio en même temps, par exemple (l'annexe A du RFC décrit en détail un cas de multi-homing). Le RFC 6887, qui normalise PCP, en parlait un peu (dans sa section 8.1, qui explique en outre comment on trouve le ou les serveurs PCP, par exemple en suivant le RFC 7291), mais ne normalisait que le cas à un seul serveur, reportant à plus tard le cas à plusieurs serveurs. C'est donc désormais fait, deux ans après. Que doit donc faire le client qui a à sa disposition les adresses de plusieurs serveurs PCP ? D'autant plus que ceux-ci n'ont pas forcément les mêmes capacités, et ne sont typiquement pas coordonnés entre eux. Notez que les règles données dans ce nouveau RFC exigent que le client puisse déterminer si deux adresses IP pointent vers le même serveur PCP ou bien deux serveurs différents.

La section 3 décrit le cas où il y a plusieurs adresses mais un seul serveur : le client doit alors choisir l'adresse IP source de sa requête PCP, en suivant les règles habituelles (section 4 du RFC 6724) et les contraintes spécifiques à PCP du RFC 6887. Un exemple de ces contraintes est que, si on veut configurer une connexion existante, il faut utiliser comme adresse IP source celle utilisée par ladite connexion. Une fois ce choix fait, le client crée une liste d'adresses IP possibles pour le serveur (section 6 du RFC 6724) et les essaie successivement (rappelez-vous que PCP fonctionne sur UDP). Une fois qu'on en a trouvé une qui marche, on la mémorise pour les futures requêtes.

Si les différentes adresses IP obtenues concernent plusieurs serveurs PCP, c'est plus compliqué (section 4). Il faut alors que le client mémorise plusieurs serveurs et, si nécessaire, les synchronise lui-même (rappelez-vous que les différents serveurs PCP ne se coordonnent pas entre eux). Par exemple, si on veut configurer le pare-feu, c'est de la responsabilité du client d'envoyer la même configuration à tous les serveurs PCP. En revanche, si on veut configurer le NAT, le client ne s'adresse typiquement qu'à un seul serveur PCP, celui correspondant à l'adresse IP externe qu'on veut utiliser. (Il faut donc que le client PCP, lorsqu'il reçoit l'information sur l'existence d'un serveur PCP, se souvienne de l'interface et des adresses IP correspondantes.)

La section 5 fournit plusieurs exemples concrets de ces procédures. Par contre, aucune idée de combien d'implémentations de PCP suivent ce RFC (on ne peut pas dire que PCP soit largement déployé...)

par Stéphane Bortzmeyer

Blog de Stéphane Bortzmeyer

RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)

 -  31 mars - 

Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)


Association entre adresse IP et AS

 -  29 mars - 

Dans les discussions au sujet du réseau Internet, on voit souvent passer des demandes sur l'AS associé à une adresse IP ou bien le contraire. Mais (...)


DNS hackathon 2025 in Stockholm

 -  23 mars - 

On 15 and 16 March 2025, I was at the DNS hackathon 2025 in Stockholm, organised by RIPE NCC, DNS-OARC and Netnod. I worked on a mechanism to (...)


RFC 9755: IMAP Support for UTF-8

 -  18 mars - 

Successeur du RFC 6855, voici la normalisation de la gestion d'Unicode par le protocole IMAP (dans sa version 4rev1) d'accès aux boîtes aux (...)


RFC 8738: Automated Certificate Management Environment (ACME) IP Identifier Validation Extension

 -  7 mars - 

Le protocole ACME, surtout connu via son utilisation par l'AC Let's Encrypt, permet de prouver la « possession » d'un nom de domaine, pour avoir un (...)