FR 3119290 A1 20220729 FR 2100769 A 20210127 PROCEDE D’ETABLISSEMENT D’UN CANAL DE COMMUNICATION POSTE-A-POSTE SECURISE, DEDIE A UNE APPLICATION RESEAU, ENTRE DEUX EQUIPEMENTS RESEAU DISTANTS L’invention concerne un procédé d’établissement d’une liaison poste-à-poste, via un réseau public (IPN), entre une application client exécutée par un premier équipement réseau (UT) et une application serveur exécutée par un second équipement réseau (SRV), le procédé comprenant des étapes consistant à : transmettre par le premier équipement une requête de connexion (INV) à un serveur d’enregistrement (REGS), à destination du second équipement, la requête de connexion contenant des données de connexion du premier équipement au réseau public, recevoir par le premier équipement, du serveur d’enregistrement, une réponse de connexion (RINV) provenant du second équipement et contenant des données de connexion du second équipement au réseau public, établir par le premier équipement une liaison poste-à-poste (S29) entre l’application client et l’application serveur, à l’aide des données de connexion du premier et du second équipement. Figure pour l’abrégé : Fig. 6 PROCEDE D’ETABLISSEMENT D’UN CANAL DE COMMUNICATION POSTE-A-POSTE SECURISE, DEDIE A UNE APPLICATION RESEAU, ENTRE DEUX EQUIPEMENTS RESEAU DISTANTS La présente invention concerne l’établissement de connexions sécurisées entre équipements connectés au réseau Internet, les équipements réseau pouvant être protégés par des pares-feux et par des translations d’adresses réseau. Pour sécuriser les communications entre ordinateurs distants ou entre deux réseau locaux distants, on a développé le système du réseau privé virtuel VPN ("Virtual Private Network") qui permet d’établir un canal direct entre des ordinateurs distants tout en isolant leurs échanges du reste du trafic transporté par des réseaux de télécommunication publics comme Internet. La connexion entre les ordinateurs est gérée de façon transparente par un logiciel de gestion de connexion VPN, créant un tunnel entre eux. Les ordinateurs interconnectés en VPN sont ainsi sur le même réseau local (virtuel), ce qui permet de passer outre d'éventuelles restrictions sur le réseau comme des pares-feux. En outre, les données transmises dans le canal VPN peuvent être chiffrées. La f igure 1 représente schématiquement un canal VPN VC10 établi entre un terminal d’utilisateur UT1 et un serveur SRV1, via un réseau public IPN tel que le réseau Internet. Le terminal d’utilisateur UT1 est connecté au réseau IPN par l’intermédiaire d’un routeur ou d’une passerelle réseau GW1. Le serveur SRV1 est également connecté au réseau IPN par l’intermédiaire d’un routeur ou d’une passerelle réseau GW2. Les routeurs GW1, GW2 peuvent comprendre un pare-feu. Une interface réseau du terminal d’utilisateur UT1 peut être également équipée d’un pare-feu. Les liaisons VPN nécessitent l’ouverture de ports dans les pares-feux. Il s’avère que le maintien de ports ouverts constitue une faille de sécurité qui peut être exploitée pour réaliser des attaques visant à accéder au contenu d’un serveur SRV1 ou aux équipements connectés avec le serveur SRV1 dans un réseau local privé. L’établissement du canal VC10 avec le serveur SRV1 requiert généralement la fourniture par le terminal UT1 de données d’accès confidentielles (telles qu’un identifiant associé à un mot de passe). Or il existe de nombreux types d’attaques ciblant les terminaux d’utilisateur pour obtenir ces données d’accès, donnant accès au serveur SRV1 et au réseau local privé du serveur. Ces attaques exploitent les ports ouverts ou des programmes chargés dans les terminaux d’utilisateurs à l’insu des utilisateurs, conçu pour récupérer les données d’accès confidentielles au serveur SRV1. On a également proposé d’utiliser le mécanisme de redirection de port NAT/PAT ("Network Address Translation / Port Address Translation") pour rediriger un port ouvert par la passerelle GW2 par exemple vers un port local d’un serveur web hébergé par le serveur SRV1. Cette liaison nécessite également le maintien d’un port ouvert, ce qui constitue également une faille de sécurité. La f igure 2 représente schématiquement un autre type de liaison VPN susceptible d’être établie entre le terminal d’utilisateur UT1 et un serveur SRV1 (ou un réseau local incluant le serveur), par l’intermédiaire du réseau public IPN. Cet autre type de liaison utilise un point central CP et un canal VPN VC2 préétabli entre le point central et le serveur SRV1 par l’intermédiaire de la passerelle GW2 connectée au réseau Internet IPN. Ici encore, le terminal d’utilisateur UT1 est connecté au réseau IPN par l’intermédiaire du routeur ou de la passerelle réseau GW1. L’établissement d’un canal VPN VC1 entre le terminal d’utilisateur UT1 et le point central CP nécessite également l’ouverture d’un port du côté du point central CP et la fourniture par le terminal UT1 de données d’accès confidentielles. Il est donc souhaitable de sécuriser l’établissement d’un canal de communication dédié à l’exécution d’une application réseau, telle que VPN, entre deux équipements connectés à un réseau public, en évitant d’avoir à maintenir un port ouvert ou à fournir des données confidentielles lors de l’établissement du canal de communication. Des modes de réalisation concernent un procédé d’établissement d’un canal de communication poste-à-poste sécurisé, dédié à une application réseau, via un réseau public, entre un premier équipement réseau et un second équipement réseau, les premier et second équipements étant connectés au réseau public, le procédé comprenant des étapes consistant à : enregistrer la présence sur le réseau public du premier équipement, auprès d’un serveur d’enregistrement, le second équipement étant enregistré auprès du serveur d’enregistrement, émettre par le premier équipement une requête d’information de connexion à un serveur d’analyse de connexion, et recevoir par le premier équipement du serveur d’analyse de connexion des données de connexion publiques du premier équipement observées depuis le réseau public, transmettre par le premier équipement une requête de connexion au serveur d’enregistrement, à destination du second équipement, la requête de connexion contenant les données de connexion publiques du premier équipement, recevoir par le premier équipement, du serveur d’enregistrement, une réponse de connexion provenant du second équipement et contenant des données de connexion publiques du second équipement, observées depuis le réseau public, et sur réception de la réponse de connexion, établir par le premier équipement un canal de communication poste-à-poste avec le second équipement via le réseau public, à l’aide des données de connexion du premier et du second équipement, et connecter par le premier équipement une application client au canal de communication. Selon un mode de réalisation, la requête de connexion comprend des données de connexion locale à une application serveur à connecter à l’application client, pour permettre au second équipement de connecter l’application serveur au canal de communication. Selon un mode de réalisation, le procédé comprend des étapes consistant à : transmettre par le premier équipement une nouvelle requête de connexion au serveur d’enregistrement, à destination du second équipement, la requête de connexion contenant des données de connexion locale à une nouvelle application serveur à connecter à une nouvelle application client, et connecter par le premier équipement la nouvelle application client au canal de communication. Des modes de réalisation peuvent également concerner un procédé d’établissement d’un canal de communication poste-à-poste sécurisé, dédié à une application, via un réseau public, entre un premier équipement réseau et un second équipement réseau, les premier et second équipements étant connectés au réseau public, le procédé comprenant des étapes consistant à : enregistrer la présence sur le réseau public du second équipement, auprès d’un serveur d’enregistrement, le premier équipement étant enregistré auprès du serveur d’enregistrement, recevoir par le second équipement une requête de connexion du serveur d’enregistrement, émise par le premier équipement, la requête de connexion contenant des données de connexion publiques du premier équipement, observées depuis le réseau public, émettre par le second équipement une requête d’information de connexion à un serveur d’analyse de connexion, et recevoir par le second équipement du serveur d’analyse de connexion des données de connexion publiques du second équipement, observées depuis le réseau public, sur réception de la requête de connexion, transmettre par le second équipement, au serveur d’enregistrement, une réponse de connexion à destination du premier équipement, contenant les données de connexion publiques du second équipement, sur réception de la réponse de connexion, établir par le second équipement un canal de communication poste-à-poste avec le premier équipement via le réseau public, à l’aide des données de connexion publiques du premier et du second équipement, et connecter par le second équipement une application serveur au canal de communication. Selon un mode de réalisation, la requête de connexion reçue comprend des données de connexion locale de l’application serveur, la connexion de l’application serveur au canal de communication étant effectuée à l’aide des données de connexion locale de l’application serveur. Selon un mode de réalisation, le procédé comprend des étapes consistant à : recevoir par le second équipement une nouvelle requête de connexion, la requête de connexion contenant des données de connexion locale d’une nouvelle application serveur, et connecter par le second équipement la nouvelle application serveur au canal de communication à l’aide des données de connexion locale de la nouvelle application serveur. Selon un mode de réalisation, les données de connexion transmises par le serveur d’analyse aux premier et second équipements comprennent des données de connexion relatives à plusieurs points de connexion du premier équipement et plusieurs points de connexion du second équipement, l’établissement du canal de communication poste-à-poste entre les premier et second équipements, comprenant des étapes consistant à exécuter par les premier et second équipements une procédure de sélection de paramètres de connexion pour tester des paires de données de connexion associant des données de connexion d’un point d’accès du premier équipement et des données de connexion d’un point d’accès du second équipement, et sélectionner une des paires testées ayant permis aux premier et second équipements de communiquer, le canal de communication poste-à-poste étant établi sur la base de la paire de données de connexion sélectionnée. Selon un mode de réalisation, la procédure de sélection de paramètres de connexion est conforme à au moins l’un des protocoles suivants : le protocole ICE, le protocole STUN, et le protocole TURN. Selon un mode de réalisation, l’application serveur est une application d’établissement d’une liaison VPN, ou une application de contrôle d’un équipement réseau comme une imprimante réseau ou un routeur, ou une application d’accès à une base de données. Selon un mode de réalisation, les transmissions de données entre le premier équipement et/ou le second équipement, d’une part et d’autre part, le serveur d’enregistrement sont effectuées par un canal de transmission sécurisé, et/ou les transmissions de données entre le premier équipement et/ou le second équipement, d’une part et d’autre part, le serveur d’analyse de connexion sont effectuées par un canal de transmission sécurisé, et/ou les transmissions de données entre le premier équipement et le second équipement, par le canal de communication poste-à-poste sont effectuées par un canal de transmission sécurisé. Selon un mode de réalisation, les transmissions de données entre le premier équipement et/ou le second équipement, d’une part et d’autre part, le serveur d’enregistrement sont effectuées : conformément au protocole SIP sur UDP ou sur TCP, sécurisé ou non par le protocole TLS, ou par un canal VPN, ou bien conformément au protocole WebSocket sécurisé ou non par un canal VPN, ou bien conformément au protocole WebRTC sécurisé ou non par un canal VPN. Selon un mode de réalisation, le serveur d’enregistrement et le serveur d’analyse de connexion sont mis en œuvre dans un unique serveur. Des modes de réalisation peuvent également concerner un équipement réseau associé à un circuit pour se connecter à un réseau public, l’équipement étant configuré pour mettre en œuvre l’un des procédés tels que définis précédemment. Selon un mode de réalisation, l’équipement réseau comprend un routeur et un pare-feu, le canal de communication étant établi au travers du routeur et du pare-feu. Selon un mode de réalisation, l’équipement réseau se présente sous la forme d’un programme installé dans un terminal d’utilisateur ou un serveur, ou se présente sous la forme d’un circuit connectable à un terminal d’utilisateur ou à un serveur. Des exemples de réalisation de l’invention seront décrits dans ce qui suit, à titre non limitatif en relation avec les figures jointes parmi lesquelles : les f igures 1 et 2 décrites précédemment, représentent schématiquement deux types de liaisons VPN établies entre un terminal d’utilisateur et un serveur, la f igure 3 représente schématiquement un canal de communication établi entre un terminal d’utilisateur et un serveur, selon un mode de réalisation, la f igure 4 représente schématiquement différents blocs logiciels ou matériels pouvant être sollicités pour établir un canal de communication entre des applications réseau exécutées respectivement par un équipement client et un équipement serveur, selon un mode de réalisation, les f igures 5A, 5B représentent plus en détail différents blocs logiciels ou matériels pouvant être sollicités respectivement côté équipement client et côté équipement serveur, pour établir un canal de communication entre des applications réseau distantes, selon un mode de réalisation, la f igure 6 est un diagramme temporel schématique montrant différentes étapes d’un procédé d’établissement d’un canal de communication entre deux applications réseau exécutées par des équipements distants, selon un mode de réalisation. La f igure 3 représente un canal de communication poste-à-poste sécurisé VC établi entre un terminal d’utilisateur UT et un serveur SRV, via un réseau public IPN tel que le réseau Internet. Le terminal d’utilisateur UT est connecté au réseau IPN par l’intermédiaire d’un routeur ou d’une passerelle réseau GWC. Le serveur SRV est également connecté au réseau IPN par l’intermédiaire d’un routeur ou d’une passerelle réseau GWS. La passerelle GWS et/ou GWC et/ou le terminal UT et/ou le serveur SRV peuvent comprendre un pare-feu. L’établissement du canal de communication VC fait intervenir un serveur d’enregistrement REGS et un serveur d’analyse de connexion SISV, accessibles par le réseau IPN. Le serveur SISV est configuré pour fournir des informations (adresses IP - "Internet Protocol" / ports) de connexion au terminal UT et au serveur SRV. Une fois que le terminal UT et le serveur SRV disposent de ces informations de connexion, ils peuvent établir en toute sécurité un canal de communication ne nécessitant pas le maintien de ports ouverts ou la transmission en clair de données d’accès confidentielles via le réseau IPN. Le serveur d’enregistrement REGS peut être configuré pour permettre au terminal d’utilisateur UT et au serveur SRV de se connecter entre eux sans avoir à connaitre leurs données de connexion publiques réciproques. A cet effet, le serveur REGS peut mémoriser une table de correspondance entre des données d’identification d’équipements réseau et des paramètres de connexions publiques d’équipements réseaux préalablement enregistrés. L’établissement de la connexion du terminal UT ou du serveur SRV au serveur d’enregistrement REGS peut faire intervenir un composant sécurisé, matériel ou logiciel, intégré dans chacune des passerelles GWC, GWS, ou dans les équipements UT, SRV, et mémorisant de manière sécurisée des données d’accès confidentielles au serveur REGS. La f igure 4 représente différents modules logiciels ou matériels intervenant dans l’établissement du canal de communication poste-à-poste sécurisé VC entre le terminal d’utilisateur UT et le serveur SRV, selon un mode de réalisation. Le terminal d’utilisateur UT et le serveur SRV comprennent respectivement un module client ECM et un module serveur ESM, incluant chacun un module de type "agent utilisateur" ("user agent") UAC, UAS et des modules applicatifs client MAPC et serveur MAPS. Les modules UAC, UAS comprennent chacun un module de communication VUPC, VUPS configurés pour gérer le canal de communication poste-à-poste VC établi à travers le réseau IPN et permettre aux modules applicatifs client MAPC et serveur MAPS d’utiliser ce canal de communication. Le canal VC peut être établi sur la base de protocoles IP tels que UDP ("User Datagram Protocol") ou TCP ("Transmission Control Protocol"). Les modules de communication VUPC, VUPS permettent de négocier l’établissement du canal de communication VC entre les agents utilisateur UAC, UAS avec l’aide des serveurs REGS et SISV, en utilisant par exemple les protocoles SIP ("Session Initiation Protocol"), STUN ("Simple Traversal of UDP through NATs" - "Network Address Translation") et négociation ICE ("Interactive Connectivity Establishment"). Les modules applicatifs MAPC, MAPS comprennent par exemple un module VPNP pour établir un canal VPN, ou tout autre application client / serveur UUP utilisant le canal de communication VC et mettant en œuvre un protocole IP ("Internet Protocol") comme par exemple UDP, TCP, IPSec ("Internet Protocol Security"), ou GRE ("Generic Routing Encapsulation"). Les f igures 5A, 5B représentent plus en détail les modules client ECM et serveur ESM, et en particulier les agents utilisateurs UAC, UAS et les modules applicatifs MAPC, MAPS. Les agents utilisateurs UAC, UAS comprennent respectivement les modules VUPS, VUPC, des modules d’aboutement PKC, PKS de connexion de paquets de données et un module TIPS mettant en œuvre la pile de protocoles IP. Chacun des modules PKC, PKS établit et gère un canal de communication interne à l’agent UAC, UAS, avec les modules applicatifs MAPC, MAPS en s’appuyant sur le module TIPS. Les modules PKC, PKS peuvent également gérer le paramétrage, le démarrage et l’arrêt des modules applicatifs MAPC, MAPS selon les besoins. Les agents utilisateur UAC, UAS disposent d’une liaison vers l’extérieur EL pour communiquer notamment avec les serveurs REGS et SISV par l’intermédiaire des modules VUPC, VUPS. Il est à noter que l’un et/ou l’autre des modules applicatifs MAPC, MAPS peuvent être implémentés à l’extérieur des modules ECM et ESM, par exemple dans un réseau local connecté à ces derniers. La f igure 6 représente des étapes S1 à S34 d’un mode de réalisation d’un procédé d’établissement d’un canal de communication poste-à-poste sécurisé pour mettre en relation une application client APPC exécutée par le terminal UT avec une application serveur cible APPS exécutée par le serveur SRV. A l’étape S1, l’agent utilisateur UAC du terminal UT est connecté au réseau IPN, et le module de communication VUPC émet une requête d’enregistrement REG à destination du serveur d’enregistrement REGS, au travers du routeur GWC / pare-feu FWC, matériel ou logiciel (étape S2). A l’étape S3, une réponse REP à la requête d’enregistrement REG est émise par le serveur REGS à destination du module VUPC de l’agent utilisateur UAC. A l’étape S4, la réponse REP est retransmise par le routeur GWC au travers du pare-feu FWC. La réponse REP fournie par le serveur REGS indique si l’enregistrement demandé par l’agent utilisateur UAC a réussi ou échoué. Au étapes S5, S6, S7, S8, une procédure identique à celle des étapes S1 à S4 est engagée par le module de communication VUPS de l’agent utilisateur UAS sur le serveur SRV au travers du routeur GWS / pare-feu FWS. Les étapes S1 à S8 peuvent par exemple être effectuées conformément aux protocoles SIP et UDP ou TCP, tel que décrit dans le document de normalisation RFC3261, et plus précisément dans le chapitre 10 de ce document. La transmission des requêtes REG et des réponses REP peut être sécurisée à l’aide du protocole TLS ("Transport Layer Security"), tel que décrit dans le document de normalisation RFC5246 et/ou si nécessaire en passant par un canal VPN crypté. D’autres protocoles comme WebSocket (RFC7118) et WebRTC ("Web Real-Time Communication") peuvent également être utilisés pour réaliser les étapes S1 à S8. A l’étape S9, le module VUPC de l’agent utilisateur UAC communique avec le serveur SISV en lui transmettant une requête CEQ pour déterminer avec quelle adresse IP publique et par quel port, il est connecté au réseau IPN. La requête CEQ contient par exemple un numéro de transaction. Aux étapes S9, S10, la requête CEQ est transmise au serveur SISV au travers du routeur GWC / pare-feu FWC . A cet effet, le routeur GWC ouvre un port et effectue si nécessaire une translation d’adresse NAT ("Network Address Translation) et/ou de port PAT ("Network Address and Port Translation"). A l’étape S11, le serveur SISV reçoit la requête CEQ et envoie au module de communication VUPC de l’agent utilisateur UAC un message de réponse CER contenant par exemple le même numéro de transaction afin de permettre au module VUPC d’établir le lien entre la requête CEQ et la réponse CER. La réponse CER est reçue avec des données encapsulées contenant une adresse IP ("Internet Protocol") publique de l’émetteur de la requête et un numéro de port ouvert par le routeur / pare-feu GWC pour communiquer avec le serveur SISV. A l’étape S12, le message de réponse CER traverse le pare-feu FWC en passant par le port ouvert pour atteindre l’agent utilisateur UAC. A partir de l’étape S10, l’agent UAC est accessible directement depuis le réseau public IPN à l’adresse IP publique et sur le numéro de port indiqués dans le message de réponse CER, pendant un temps limité, typiquement de quelques secondes. A l’étape S13, le module de communication VUPC transmet au serveur REGS une requête de connexion INV à destination du serveur SRV. La requête de connexion contient notamment les identifiants des agents UAC et UAS, tels qu’enregistrés auprès du serveur REGS aux étapes S1 à S4 et S5 à S8. A l’étape S14, la requête traverse le routeur GWC / pare-feu FWC côté terminal UT pour atteindre le serveur REGS. A l’étape S15, le serveur REGS localise le serveur SRV à l’aide des informations figurant dans la requête INV, puis transmet la requête INV au serveur SRV. L’acheminement de la requête INV par le serveur REGS vers le serveur SRV suppose que les deux agents UAC et UAS aient été préalablement enregistrés auprès du serveur REGS. A l’étape S16, la requête INV traverse le routeur GWS / pare-feu FWS, côté serveur SRV, pour atteindre le module de communication VUPS de l’agent UAS. Selon un mode de réalisation, la requête INV comprend des données d’application relatives à une application serveur APPS à exécuter sur le serveur ou dans le réseau local du serveur SRV. Les données d’application comprennent par exemple un type et une donnée d’identification de l’application APPS, des données de connexion à l’application serveur incluant une adresse IP locale, un numéro de port et une désignation du protocole de communication à employer. Les données d’application peuvent également comprendre des données supplémentaires telles que des paramètres de fonctionnement, à transmettre pour le bon fonctionnement de l’application APPS. La requête INV comprend également des identifiants du terminal UT et du serveur SRV tels qu’enregistrés par le serveur REGS. Un exemple de requête INV est présenté en Annexe I. Dans cet exemple, la requête INV correspond à un message "INVITE" défini et transmis conformément au protocole SIP ("Session Initiation Protocol"). Le corps du message inclut des données relatives au protocole SDP ("Session Description Protocol"). Selon un mode de réalisation, la requête INV comprend une extension des protocoles SIP et SDP, incluant les balises suivantes : - "m= " permettant de définir le type d’application réseau cible APPS ("VPN" dans l’exemple de l’Annexe I) à exécuter sur le serveur SRV ou dans le réseau local du serveur, - "a= -dst-ip" et "a= -dst-port" permettant de localiser l’application APPS dans l’environnement local du serveur SRV, - "a= -dst-proto" définissant un protocole réseau IP compatible avec l’application serveur, tel que UDP ou TCP. D’autres balises pourraient être utilisées pour transmettre des paramètres à l’application APPS, par exemple tels que "a= -param-1" … "a= -param-n" (n représentant le nombre de paramètres à transmettre). Dans l’exemple de l’Annexe I, la requête INV est un message comprenant un entête et un corps. L’entête rassemble les données suivantes : - la commande "INVITE" associée à un identifiant du serveur destinataire visé " " tel qu’enregistré par le serveur REGS, et un identifiant du protocole de signalisation concerné, à savoir SIP version 2.0,- une balise "Via :" définissant à nouveau le protocole de signalisation et sa version, ainsi que le protocole réseau "SIP/2.0/UDP", l’adresse IP et le port local de l‘émetteur de la requête “ ”, une balise "branch" associée à un identifiant de transaction à utiliser pour chaque échange de la transaction, - des balises "From" et "To :" qui définissent les identifiants de l’émetteur et du destinataire de la requête " ", “ ” tels qu’enregistrés par le serveur REGS, la balise "from" étant accompagnée d’une étiquette "tag" générée aléatoirement à des fins d’identification, - une balise "Call-ID:" permettant d’identifier la connexion, - une balise "CSeq:" introduisant un numéro de séquence associé à la commande SIP et incrémenté à chaque nouvelle commande, - une balise "Max-Forwards:" définissant un nombre maximum de redirections qui est décrémenté à chaque redirection effectuée lors de la transmission de la commande INV, - une balise "Date:" introduisant la date et heure de l’envoi de la commande, - une balise "content-type:" définissant le protocole utilisé dans le corps de la requête, ici le protocole SDP, et - une balise "content-length" définissant la longueur en nombre d’octets du corps de la requête. Le corps du message INV comprend un certain nombre de balises définies conformément au protocole SDP. Ces balises sont décrites plus en détail dans le document de normalisation RFC4566, et plus précisément dans le chapitre 5 de ce document. Le corps du message comprend notamment les balises suivantes : - "v=0" indiquant un numéro de version du protocole SDP,. - "o= …." indiquant l’identifiant de l’initiateur de la transaction (" "), tel que défini lors des étapes S1 à S4, ainsi qu’un identifiant et un numéro de version de session ("1590676221" et "1590676223"), le type de réseau auquel est connecté l’émetteur de la requête ("IN" pour Internet), le type d’adresse dans le réseau ("IP4" pour Internet Protocol v4), et l’adresse IP de l’émetteur ("86.203.229.181"), - "c=IN IP4 86.203.229.181" indiquant à nouveau le type de réseau auquel est connecté l’émetteur de la requête ("IN" pour Internet), le type d’adresse dans le réseau ("IP4"), et l’adresse IP ("86.203.229.181"), - "m= 4003 UDP 0" définissant normalement un type de média utilisé, mais qui est ici redéfinie pour identifier une application serveur cible " " (identifiant l’application APPS dans l’exemple de la f igure 6),et identifier un protocole "UDP" à utiliser pour l’échange de paquets de données avec l’application, un premier numéro de port public susceptible d’être utilisé pour établir le canal de communication , et un numéro de version du protocole "0" visé par la requête. Le corps de la requête INV comprend également des balises "a=…" incluant chacun une étiquette associée à des paramètres, notamment des paramètres de connexion réseau à utiliser pour sélectionner avec le serveur SRV la "meilleure" connexion. Ainsi, les balises "a=…" comprennent des paramètres "ice-ufrag" et "ice-pwd" permettant de spécifier un identifiant et un mot de passe choisis aléatoirement et utilisés pour assurer l’intégrité du contenu des messages échangés. Les balises "a=…" comprennent également des paramètres " candidate" définissant chacun un point de connexion obtenu aux étapes S9-S12. Les balises "a =candidate" présentent la syntaxe suivante : a=candidate : dans laquelle : - identifie plusieurs candidats du même type, partageant la même base et provenant du même serveur SISV, - identifie un composant spécifique du flux de données à transmettre par la connexion, - indique le protocole à utiliser, - indique un numéro de priorité, - indique une adresse possible d’accès à l’agent UAC, - indique un numéro de port possible d’accès à l’agent UAC - indique un type du point de connexion, par exemple "typ host" ou "typ srflx" respectivement pour un point provenant de la machine locale ou d’un serveur réflexif de type STUN par exemple, - and indiquent des adresses et des ports du point de connexion, utiles notamment à des fins de diagnostic. Les données de connexion réseau reçues à l’étape S12 sont utilisées pour spécifier la requête INV et en particulier les balises "a=candidate". La première balise "a=candidate" présentée en Annexe I contient les adresses IP publique / ports ouverts dans le pare-feu FWC à l’étape S10. A la suite de la réception de la requête INV à l’étape S16, le module VUPS de l’agent UAS envoie au module d’aboutement PKS une requête avec des informations permettant d’identifier, localiser et paramétrer l’application APPS visée. En réponse à cette requête, le module d’aboutement PKS transmet un code d’état d’acceptation ou de refus, éventuellement accompagné de paramètres propres à l’application APPS. Le module VUPS de l’agent UAS communique (étapes S17 à S20) avec le serveur SISV en lui transmettant une requête CEQ pour déterminer avec quelle adresse IP publique et quel port, il communique avec le serveur SISV. Ainsi aux étapes S17 à S20, identiques aux étapes S9 à S12, mais effectuées entre les serveurs SISV et SRV, une requête CEQ est émise par l’agent UAS au serveur SISV au travers du routeur GWS / pare-feu FWS. A l’étape S19, le serveur SISV émet une réponse CER qui traverse le routeur GWS / pare-feu FWS à l’étape S20. A partir de l’étape S18, l’agent UAS est accessible directement depuis le réseau public IPN à l’adresse IP publique et sur le numéro de port public indiqués dans le message de réponse CER. Le message de réponse CER reçu par le serveur SRV à l’étape S20 contient les informations de connexion au réseau IPN relatives à l’agent UAS, fournies par le serveur SISV. Selon un mode de réalisation, les communications effectuées aux étapes S9 à S12 et S17 à S20 sont réalisées dans un canal sécurisé, par exemple conformément au protocole TLS. Les étapes S21 à S24 qui suivent comprennent la transmission d’un message de réponse RINV à la requête INV, du serveur SRV au terminal UT par l’intermédiaire du serveur REGS. Le message de réponse RINV contient sensiblement la même structure et le même type d’informations que le message de requête INV. Cependant, le message de réponse contient les informations relatives au serveur SRV et notamment celles transmises par le serveur SISV dans le message CER à l’étape S20, et éventuellement les informations liées à l’application visée APPS fournies par le module d’aboutement PKS. Le message de réponse RINV contient en outre un code d’état pouvant indiquer une acceptation de la connexion, une acceptation de la connexion à une autre adresse spécifiée dans le message de réponse RINV, ou un refus de la connexion en raison de l’occurrence d’une erreur. Le code d’état peut être celui défini dans les spécifications RFC3261, section 13.2.2. Aux étapes S22, S23, le message de réponse RINV est relayé par le serveur REGS vers le terminal UT en utilisant les informations figurant dans la requête RINV. Par exemple, dans le cas où le serveur REGS est un serveur registrar conforme au protocole SIP, il utilise les informations contenues dans l’entête SIP du message RINV pour définir où transférer le message. Le module VUPC peut alors transmettre au module d’aboutement PKC les informations de paramétrage fournies par le module PKS. Le module PKC renvoie au module VUPC un code d’état d’acceptation ou d’échec. A l’étape S24, si les codes d’états fourni dans le message de réponse RINV et par le module PKC spécifient une acceptation de la connexion, le module VUPC de l’agent UAC transmet à l’étape S25 au serveur REGS, à destination du serveur SRV un message d’accusé de réception ACK. A l’étape S26, le message ACK traverse le routeur GWC / pare-feu FWC et est reçu par le serveur REGS. Aux étapes S27, S28, le message ACK est acheminé du serveur REGS au serveur SRV, au travers du routeur /pare-feu GWS, en utilisant les informations de connexion contenues dans l’entête du message de réponse ACK. Les messages INV, RINV et ACK transmis aux étapes S13 à S16, S21 à S24 et S25 à S28 peuvent être ceux spécifiés par le protocole SIP et décrits plus en détail au chapitre 13 du document de normalisation RFC3261. Selon un mode de réalisation, les transmissions des messages INV, RINV et ACK aux étapes S13 à S16, S21 à S24 et S25 à S28 sont réalisées dans un canal sécurisé, par exemple conformément au protocole TLS. A la réception des messages RINV et ACK, les modules VUPC, VUPS des agents UAC et UAS exécutent à l’étape S29 une procédure de sélection de données de connexion. Cette procédure vise à tester les chemins de connexion poste-à-poste en s’appuyant sur les données de connexion (adresses IP/ports) fournies par le serveur SISV et insérées dans les messages INV et RINV. A cet effet, les modules VUPC, VUPS des agents UAC, UAS utilisent par exemple les points de connexion spécifiés par les balises "a=candidate" dans la requête INV et la réponse RINV. Ces points de connexion sont utilisés par les agents UAC, UAS en formant des paires de points de connexion émetteur et récepteur. Chaque paire est ensuite testée par les agents UAC, UAS. Pour cela, le module VUPC transmet une requête de test à travers le point de connexion du routeur GWS / pare-feu FWS, coté SRV, pour atteindre le module VUPS. Le module VUPS répond en transmettant une requête de test à travers le point de connexion du routeur GWC / pare-feu FWC, coté terminal UT pour atteindre le module VUPC. La paire finalement retenue par les modules VUPC, VUPS forme alors un chemin de connexion qui peut être celui qui a été le plus efficace en terme de latence. Cette procédure est par exemple réalisée conformément au protocole ICE décrite dans le document RFC8445, en particulier au chapitre 6. A l’issue de cette procédure, chacun des agents UAC, UAS dispose d’une adresse IP/port de destination à utiliser pour transmettre des données à l’autre agent. Ainsi, les agents UAC, UAS sont connectés entre eux par un canal de communication poste-à-poste ("peer-to-peer"), et peuvent s’échanger n’importe quelle donnée conformément au protocole IP sélectionné (par exemple UDP). Les adresses IP/ports publics ainsi définis pour accéder au terminal UT et au serveur SRV peuvent être différents de ceux ouverts aux étapes S10 et S18. Le canal de communication poste-à-poste peut être utilisé par le terminal UT pour connecter n’importe quelle application serveur APPS parmi les modules applicatifs MAPS sur le serveur SRV, à une application client APPC parmi les modules applicatifs MAPC sur le terminal UT (étape S32). Cependant, les modules d’aboutement PKC, PKS limitent l’usage de cette connexion à l’application spécifiée par les balises "m=" et "a= …". Pour réaliser cette connexion, un tunnel de communication est établi du côté du terminal UT à l’étape S30 en fournissant un point d’entrée pour l’application client APPC et en se connectant à la liaison poste-à-poste VC. A l’étape S31, un tunnel de communication est également établi du coté du serveur SRV en se connectant à la liaison poste à poste VC et se mettant en attente de données en provenance de l’UAC arrivant du tunnel VC. A l’étape S32, l’application client APPC est paramétrée et activée par le module PKC, et commence à envoyer des données. Ces données sont transmises à travers le tunnel VC à l’étape S33. Dès réception de celles-ci, à l’étape S34, l’application serveur APPS est alors paramétrée et démarrée par le module PKS. Dès lors, les applications APPC et APPS sont connectées entre elles et peuvent communiquer librement par le canal de communication VC (S33). Les applications client APPC et serveur APPS peuvent par exemple permettre l’établissement d’un canal VPN entre le terminal UT et le serveur SRV pour donner au terminal accès à des ressources du serveur ou du réseau local auquel le serveur est connecté. L’application serveur APPS peut être par exemple un serveur Web de contrôle d’un équipement réseau tel qu’une imprimante réseau ou un routeur connecté au réseau local du serveur SRV, ou encore une application spécifique installée sur le serveur. Dans ce cas, l’application client APPC peut être par exemple un navigateur Internet équipé d’une extension spécifique pour communiquer à travers le tunnel de communication VC ainsi établi. Il convient de noter que, par ce procédé, il est possible de faire communiquer une application réseau à travers des équipements réseau protégés (non accessibles depuis le réseau public car protégés par un routeur et un pare-feu). Cependant, les applications réseau susceptibles d’utiliser le canal de communication VC sont strictement limitées à celles définies dans la commande INV transmise aux étapes S13 à S16. Selon un mode de réalisation, il est possible d’utiliser le canal de communication VC précédemment établi pour une application réseau, pour faire communiquer d’autres applications réseau APPC/APPC. A cet effet, les modules de communication VUPC, VUPS des agents UAC, UAS peuvent à nouveau exécuter les étapes S13 à S16, S21 à S28 et S30 à S34. Aux étapes S13 à S16, une nouvelle requête INV est envoyée à destination du serveur SRV. Cette nouvelle requête INV contient toutes les informations de paramétrage et d’identification de l’application serveur cible APPS. Le module VUPS est ainsi informé de la nouvelle application serveur à activer. Le tunnel de communication étant déjà établi (S29), les informations nécessaires à l'établissement de ce dernier ne sont pas utiles dans la requête INV. Selon un mode de réalisation, les modules PKC, PKS sont en mesure d'exécuter plusieurs applications en utilisant par exemple une méthode de multiplexage de données permettant une identification de paquets de données. Selon un autre mode de réalisation, les modules PKC, PKS peuvent arrêter l’exécution d’une application réseau, pour la remplacer par une nouvelle, lors de l‘émission ou la réception d’une requête d’activation d’une autre application. Lorsque l’utilisateur ferme l’application APPC ou APPS, l’agent UAC ou UAS transmet à l’autre agent (UAS ou UAC) un message de fermeture, par exemple un message BYE selon le protocole SIP et l’autre agent répond en envoyant un message de confirmation de fermeture. Les modules d’aboutement PKC et PKS activés par les agents UAC et UAS sont alors fermés, ce qui provoque la fermeture du canal VC. Dans le cas ou plusieurs applications sont en cours d’exécution, un message de notification de fermeture est envoyé à chaque fermeture d’application, par exemple un message NOTIFY ou UPDATE selon le protocole SIP. Si la dernière application réseau active est fermée, le canal VC est fermé, ainsi que les modules d’aboutement PKC, PKS. Ainsi, le procédé qui vient d’être décrit permet de mettre en communication des applications réseau exécutées par des équipements réseau protégés par un routeur et un pare-feu, sans avoir à maintenir ouverts des ports librement accessibles depuis le réseau public. Conformément à des mécanismes de sécurité mis en œuvre dans les pares-feux actuels, les ports ouverts aux étapes S10, S18 et éventuellement S29 restent ouverts pendant une durée très courte de quelques dizaines de secondes. Un éventuel pirate n’a donc pas le temps d’examiner tous les ports susceptibles d’être utilisés pour pénétrer dans les réseaux locaux du terminal UT ou du serveur SRV. A l’issue de cette durée, si le port est encore utilisé, il reste ouvert mais seulement pour l’adresse IP émettrice du dernier paquet de données reçu. Ainsi, à l’étape S33, les ports sélectionnés à l’étape S29 restent ouverts uniquement pour les paquets de données provenant des adresses IP publiques sélectionnées à l’étape S29. Ces ports peuvent être maintenus ouverts pendant une longue période par un mécanisme autonome (mécanisme "keep-alive" du protocole ICE par exemple), tant que les modules VUPC et VUPS sont en cours d’exécution. Ces ports ne sont donc pas exploitables pour pénétrer dans les réseaux locaux du terminal UT et du serveur SRV. Il apparaîtra clairement à l'homme de l'art que la présente invention est susceptible de diverses variantes de réalisation et diverses applications. En particulier, il peut ne pas être nécessaire d’exécuter la procédure de sélection de données de connexion à l’étape S29, sachant que les étapes S9-S12 et S17-S20 permettent d’obtenir au moins une adresse IP publique et un port de connexion pour le terminal UT et le serveur SRV. Les modules d’aboutement PKC, PKC peuvent être dédiés à une application réseau. Dans ce cas, ils n’ont pas besoin d’identifiants et de données de connexion locale pour déterminer comment connecter les applications client et serveur à chacune des extrémités du canal de communication. Par ailleurs, toutes les étapes de la f igure 6 exécutées par l’agent UAC ou par l’agent UAS peuvent être implémentées dans un équipement réseau spécifique distinct du terminal UT ou du serveur SRV. Ces étapes peuvent aussi être en partie ou en totalité mises en œuvre par un programme installé dans le terminal UT et/ou le serveur SRV. Les protocoles mentionnés précédemment, susceptibles d’être utilisés dans le cadre de l’exécution des étapes de la f igure 6, présentent l’avantage d’être des protocoles standardisés et implémentés dans des modules disponibles, ce qui permet de faciliter la réalisation et l’interopérabilité des agents UAC, UAS, ainsi que des serveurs REGS et SISV. Cependant, il va de soi qu’il n’est pas nécessaire de mettre en œuvre ces protocoles pour réaliser les étapes de la f igure 6, et que des protocoles spécifiques peuvent être développés à cette fin, les fonctions assurées par les serveurs REGS et SISV pouvant être adaptées à ces protocoles spécifiques ou dédiés. Le développement de tels protocoles peut en effet permettre d’alléger les traitements à effectuer et de les adapter plus spécifiquement aux besoins requis. Notamment, d’autres protocoles que UDP et TCP peuvent être utilisés pour la couche transport du modèle OSI ("Open Systems Interconnection"), comme SCTP ("Stream Control Transmission Protocol"). En outre, les serveurs REGS et SISV ont été décrits comme étant des équipements distincts. Il va de soi également que les fonctions réalisées par ces deux serveurs et mises en œuvre dans les étapes de la f igure 6, peuvent être réalisées par un serveur physique unique ou un serveur accessible à une adresse IP publique unique. Il va également de soi que le terminal UT peut également être un serveur connecté à un réseau local et que l’application APPC/APPS exécutée aux étapes S32-S34 peut permettre par exemple d’établir une liaison VPN entre ce réseau local et le réseau local connecté au serveur SRV. Le serveur SRV peut également être un simple terminal d’utilisateur. Dans ce cas, l’application APPC/APPS peut permettre par exemple d’établir une liaison VPN entre deux terminaux distants. Ainsi, l’expression "équipement réseau" telle qu’utilisée dans les revendications ci-jointes désigne donc indifféremment un terminal d’utilisateur, un serveur ou un réseau local. Annexe I Exemple de requête INV (étape S13) INVITE sip: SIP/2.0 Via: SIP/2.0/UDP ;branch=z9hG4bKnashds8 To: SiteXX From: Nomade1 ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2020 13:02:03 GMT Contact: sip: Content-Type: application/sdp Content-Length: 105 v=0 o= 1590676221 1590676223 IN IP4 82.203.229.181 c=IN IP4 86.203.229.181 m= 4003 UDP 0 a= -dst-IP:192.168.100.20 a= -dst-port:4242 a= -dst-proto:TCP a=ice-ufrag:6abdfa9b a=ice-pwd:7792893930440d10070f2f6e a=candidate:Sc0a8006a 1 UDP 1862270975 86.203.229.181 4003 typ srflx raddr 192.168.0.106 rport 4003 a=candidate:Hc0a8006a 1 UDP 1694498815 192.168.0.106 4003 typ host a=candidate:Hc0a86302 1 UDP 1694498815 192.168.99.2 4003 typ host a=candidate:Hac107201 1 UDP 1694498815 172.16.114.1 4003 typ host a=candidate:Hac101001 1 UDP 1694498815 172.16.16.1 4003 typ host a=candidate:Sc0a8006a 2 UDP 1862270974 86.203.229.181 4026 typ srflx raddr 192.168.0.106 rport 4026 a=candidate:Hc0a8006a 2 UDP 1694498814 192.168.0.106 4026 typ host a=candidate:Hc0a86302 2 UDP 1694498814 192.168.99.2 4026 typ host a=candidate:Hac107201 2 UDP 1694498814 172.16.114.1 4026 typ host a=candidate:Hac101001 2 UDP 1694498814 172.16.16.1 4026 typ host Procédé d’établissement d’un canal de communication poste-à-poste sécurisé, dédié à une application réseau, via un réseau public (IPN), entre un premier équipement réseau (UT) et un second équipement réseau (SRV), les premier et second équipements étant connectés au réseau public, le procédé comprenant des étapes consistant à : enregistrer la présence sur le réseau public du premier équipement, auprès d’un serveur d’enregistrement (REGS), le second équipement étant enregistré auprès du serveur d’enregistrement, émettre par le premier équipement une requête d’information de connexion (CEQ) à un serveur d’analyse de connexion (SISV), et recevoir par le premier équipement du serveur d’analyse de connexion des données de connexion publiques (CER) du premier équipement observées depuis le réseau public, transmettre par le premier équipement une requête de connexion (INV) au serveur d’enregistrement, à destination du second équipement, la requête de connexion contenant les données de connexion publiques du premier équipement, recevoir par le premier équipement, du serveur d’enregistrement, une réponse de connexion (RINV) provenant du second équipement et contenant des données de connexion publiques (CER) du second équipement, observées depuis le réseau public, et sur réception de la réponse de connexion, établir par le premier équipement un canal de communication poste-à-poste (VC) avec le second équipement via le réseau public, à l’aide des données de connexion du premier et du second équipement, et connecter par le premier équipement une application client (APPC) au canal de communication. Procédé selon la revendication 1, dans lequel la requête de connexion (INV) comprend des données de connexion locale à une application serveur (APPS) à connecter à l’application client (APPC), pour permettre au second équipement (SRV) de connecter l’application serveur au canal de communication (VC). Procédé selon la revendication 2, comprenant des étapes consistant à : transmettre par le premier équipement (UT) une nouvelle requête de connexion (INV) au serveur d’enregistrement (REGS), à destination du second équipement (SRV), la requête de connexion contenant des données de connexion locale à une nouvelle application serveur (APPS) à connecter à une nouvelle application client (APPC), et connecter par le premier équipement la nouvelle application client (APPC) au canal de communication. Procédé d’établissement d’un canal de communication poste-à-poste sécurisé, dédié à une application, via un réseau public (IPN), entre un premier équipement réseau (UT) et un second équipement réseau (SRV), les premier et second équipements étant connectés au réseau public, le procédé comprenant des étapes consistant à : enregistrer la présence sur le réseau public du second équipement, auprès d’un serveur d’enregistrement (REGS), le premier équipement étant enregistré auprès du serveur d’enregistrement, recevoir par le second équipement une requête de connexion (INV) du serveur d’enregistrement, émise par le premier équipement, la requête de connexion contenant des données de connexion publiques du premier équipement, observées depuis le réseau public, émettre par le second équipement une requête d’information de connexion (CEQ) à un serveur d’analyse de connexion (SISV), et recevoir par le second équipement du serveur d’analyse de connexion des données de connexion publiques (CER) du second équipement, observées depuis le réseau public, sur réception de la requête de connexion, transmettre par le second équipement, au serveur d’enregistrement, une réponse de connexion (RINV) à destination du premier équipement, contenant les données de connexion publiques du second équipement, sur réception de la réponse de connexion, établir par le second équipement un canal de communication poste-à-poste (VC) avec le premier équipement via le réseau public, à l’aide des données de connexion publiques du premier et du second équipement, et connecter par le second équipement une application serveur (APPS) au canal de communication (VC). Procédé selon la revendication 4, dans lequel la requête de connexion (INV) reçue comprend des données de connexion locale de l’application serveur (APPS), la connexion de l’application serveur au canal de communication (VC) étant effectuée à l’aide des données de connexion locale de l’application serveur. Procédé selon la revendication 5, comprenant des étapes consistant à : recevoir par le second équipement (SRV) une nouvelle requête de connexion (INV), la requête de connexion contenant des données de connexion locale d’une nouvelle application serveur (APPS), et connecter par le second équipement la nouvelle application serveur au canal de communication (VC) à l’aide des données de connexion locale de la nouvelle application serveur. Procédé selon l’une des revendications 1 à 6, dans lequel les données de connexion transmises par le serveur d’analyse (SISV) aux premier et second équipements (UT, SRV) comprennent des données de connexion relatives à plusieurs points de connexion du premier équipement et plusieurs points de connexion du second équipement, l’établissement du canal de communication poste-à-poste (VC) entre les premier et second équipements, comprenant des étapes consistant à exécuter par les premier et second équipements une procédure de sélection de paramètres de connexion pour tester des paires de données de connexion associant des données de connexion d’un point d’accès du premier équipement et des données de connexion d’un point d’accès du second équipement, et sélectionner une des paires testées ayant permis aux premier et second équipements de communiquer, le canal de communication poste-à-poste étant établi sur la base de la paire de données de connexion sélectionnée. Procédé selon la revendication 6 ou 7, dans laquelle la procédure (S29) de sélection de paramètres de connexion est conforme à au moins l’un des protocoles suivants : le protocole ICE, le protocole STUN, et le protocole TURN. Procédé selon la revendication 8, dans lequel l’application serveur (APPS) est une application d’établissement d’une liaison VPN, ou une application de contrôle d’un équipement réseau comme une imprimante réseau ou un routeur, ou une application d’accès à une base de données. Procédé selon l'une des revendications 1 à 9, dans lequel : les transmissions de données entre le premier équipement (UT) et/ou le second équipement (SRV), d’une part et d’autre part, le serveur d’enregistrement (REGS) sont effectuées par un canal de transmission sécurisé, et/ou les transmissions de données entre le premier équipement et/ou le second équipement, d’une part et d’autre part, le serveur d’analyse de connexion (SISV) sont effectuées par un canal de transmission sécurisé, et/ou les transmissions de données entre le premier équipement et le second équipement, par le canal de communication poste-à-poste (VC) sont effectuées par un canal de transmission sécurisé. Procédé selon l'une des revendications 1 à 10, dans lequel les transmissions de données entre le premier équipement (UT) et/ou le second équipement (SRV), d’une part et d’autre part, le serveur d’enregistrement (REGS) sont effectuées : conformément au protocole SIP sur UDP ou sur TCP, sécurisé ou non par le protocole TLS, ou par un canal VPN, ou bien conformément au protocole WebSocket sécurisé ou non par un canal VPN, ou bien conformément au protocole WebRTC sécurisé ou non par un canal VPN. Procédé selon l'une des revendications 1 à 11, dans lequel le serveur d’enregistrement (REGS) et le serveur d’analyse de connexion (SISV) sont mis en œuvre dans un unique serveur. Equipement réseau (UT, SRV) associé à un circuit pour se connecter à un réseau public (IPN), l’équipement étant configuré pour mettre en œuvre le procédé selon l'une des revendications 1 à 12. Equipement réseau selon la revendication 13, comprenant un routeur (GWC, GWS) et un pare-feu (FWC, FWS), le canal de communication (VC) étant établi au travers du routeur et du pare-feu. Equipement réseau selon la revendication 13 ou 14, dans lequel l’équipement réseau se présente sous la forme d’un programme installé dans un terminal d’utilisateur (UT) ou un serveur (SRV), ou se présente sous la forme d’un circuit connectable à un terminal d’utilisateur ou à un serveur.