À quoi sert réellement un tunnel

On monte un petit service de stockage à la maison, on arrive au bureau, on essaie de le joindre, et rien ne répond. On fait tourner un point de rappel de paiement sur son portable, et la requête de test du fournisseur n'arrive jamais. On veut héberger une partie multijoueur pour des amis et l'on découvre que tout le monde est derrière une adresse privée. Le problème de fond est identique dans les trois cas : la machine n'a pas d'adresse publique, une requête venue de l'extérieur n'a donc nulle part où être livrée.

La solution classique tient en trois étapes, et la plupart des gens s'arrêtent à la première. Obtenir une adresse publique, configurer la redirection de port sur le routeur, mettre en place un DNS dynamique. Beaucoup d'opérateurs ne distribuent plus d'adresse publique du tout. Un service de tunnel existe pour contourner ce tas : un serveur de relais tient le côté public, et les requêtes sont portées vers l'intérieur par une connexion que votre machine a ouverte elle-même.

Quatre étapes, sans entrer dans le routeur

Le réglage est volontairement court. Installer le client, créer un compte, ajouter une association qui relie un port de la machine interne à un nom à l'extérieur, et c'est fini. Rien dans cette séquence n'exige la page d'administration du routeur ni un appel à l'opérateur, et c'est tout l'intérêt : ceux qui ont besoin de cela sont justement ceux qui n'obtiennent ni la page du routeur ni la coopération de l'opérateur.

TCP et UDP passent tous deux, et cette largeur est ce qui rend le service utile plutôt qu'une astuce pour pages web. Un service web, une session de bureau à distance, un serveur FTP, un serveur de jeu et un relais de messages pour un réseau de capteurs fonctionnent tous, parce que le protocole en dessous ne sait pas ce que les octets représentent.

Chaque nom associé reçoit en plus un certificat HTTPS automatique. Pour un développeur, cela supprime un agacement très concret et très familier : les fournisseurs de paiement et d'identité exigent un rappel en HTTPS, et le tester en local signifiait autrefois fabriquer un certificat auto-signé puis convaincre un tiers de lui faire confiance, ce qui est impossible. Ici, le rappel a un vrai certificat dès la première minute.

Plateformes et situations qui conviennent

Le client couvre les trois systèmes de bureau, et il peut aussi s'installer directement sur un routeur, ce qui veut dire que le tunnel se termine au bord du réseau plutôt que sur une machine à l'intérieur. Cette seule possibilité couvre beaucoup de terrain : tout ce qui est derrière le routeur devient joignable sans qu'un client tourne quelque part.

Les usages que les gens apportent réellement sont réguliers. Atteindre des systèmes internes de l'entreprise, gestion ou bureautique, depuis l'extérieur. Tester des rappels de paiement et d'identité qui exigent HTTPS. Rejoindre un appareil de stockage à la maison ou au bureau en déplacement. Héberger une partie multijoueur sans louer de serveur. Rapatrier des données de capteurs dispersés sur le terrain. L'exploitant annonce quelques millions d'utilisateurs et des dizaines de milliers d'entreprises, et le côté relais repose sur un faisceau de plusieurs liaisons plutôt que sur une seule route.

Palier gratuit, palier payant

Le palier gratuit donne un tunnel et un port, avec assez de bande passante pour des tests quotidiens et un accès temporaire, ce qui décrit honnêtement ce qu'il faut pour essayer une idée. Les paliers payants visent ce qui doit rester debout : systèmes internes d'entreprise, projets publiés, parties multijoueur sensibles à la latence. Plus de bande passante, un service plus régulier, et l'affirmation de l'éditeur d'une disponibilité du niveau qu'exigent les services financiers, avec un relais en fonctionnement depuis plusieurs années sans arrêt. Une formule à achat unique existe pour ceux qui préfèrent ne pas renouveler chaque année.

Il existe une situation où ce n'est pas la bonne réponse, et il vaut la peine de le dire franchement. Si vous avez déjà une adresse publique, ou si cela ne vous dérange pas de faire tourner vous-même un démon de tunnel sur un serveur bon marché, alors un service géré est un coût mensuel pour quelque chose que vous savez exploiter. Ce qui est vendu n'est pas le tunnel, c'est l'absence du serveur, de la configuration du relais et du renouvellement annuel des certificats.

Toute l'idée est de faire du tunnel une chose qu'on achète au lieu d'une chose qu'on entretient. Pas de relais à corriger, pas de configuration de proxy à écrire, pas de certificat à courir après. Pour un développeur seul ou une petite équipe, les heures épargnées valent plus que le tarif, et la première de ces heures commence dès que le client a fini de s'installer.