Réglages punchy de Nebula : lequel corrige votre NAT

Deux pairs se trouvent via le phare puis échouent à construire un chemin direct, et le premier réflexe est d’activer toutes les options punchy. Ce réflexe produit une configuration à trois changements sans savoir lequel comptait. Les réglages répondent à des questions différentes : l’un entretient une correspondance qui existe déjà, et l’autre tente une poignée de main dans la direction inverse. Décidez quelle question est la vôtre avant de toucher à l’une ou l’autre.

Confirmez l’extrémité avant le minutage

Un pair qui n’apparaît jamais à l’adresse attendue ne sera pas sauvé par le réglage de punch. Vérifiez ce que le phare sait du pair et ce qu’annonce sa propre configuration, car une adresse bootstrap périmée ou une adresse privée publiée par erreur déjoue toutes les astuces de traversée. Confirmez aussi que le certificat est approuvé, car une identité non approuvée arrête la conversation bien avant que le NAT n’importe. Vérifiez ensuite que l’UDP atteint ne serait-ce que le phare. Les valeurs de temps sont la dernière chose à regarder, pas la première.

Notez la paire d’extrémités avec laquelle vous testez, afin que les comparaisons ultérieures utilisent les mêmes pairs plutôt que deux autres machines.

punch garde une correspondance, respond ouvre une direction

L’option punch envoie périodiquement des paquets vides vers l’adresse de sous-couche d’un pair qui a déjà un tunnel. Son but n’est pas glorieux : elle empêche un NAT à état ou un pare-feu de faire expirer la correspondance dont dépend le chemin direct. L’option respond change ce qui se passe lors d’une notification du phare, en faisant tenter à l’hôte une poignée de main vers le pair qui cherche à l’atteindre. Ce sont des mécanismes différents avec des modes de défaillance différents.

Choisissez punch quand le chemin direct fonctionne puis se dégrade. Choisissez respond quand le chemin ne se forme jamais dans un sens. Activer les deux et espérer, c’est ainsi qu’une correction de cinq minutes devient une semaine de réglages.

Les délais décident quand, pas si

Les valeurs de délai déplacent le minutage : l’une s’applique au paquet envoyé après une notification, l’autre à la tentative de poignée de main inverse. Aucune ne rend fonctionnelle une direction bloquée. Changer les deux à la fois détruit la comparaison que vous alliez faire.

Laissez-les tranquilles jusqu’à ce que le mécanisme soit correct. Ajustez-en ensuite un, et notez l’ancienne valeur.

Quand un relais est la réponse honnête

Certaines combinaisons de NAT ne peuvent pas supporter un chemin direct, quelle que soit l’organisation du minutage. Un NAT symétrique des deux côtés, ou un pare-feu qui rejette entièrement le trafic entrant non sollicité, ne laisse rien à percer.

Un nœud relais avec une adresse joignable donne à ces pairs un chemin qui ne dépend pas de la réussite de la traversée. Il coûte de la bande passante via ce nœud, c’est donc une décision de capacité et non un contournement. Configurez le relais délibérément et vérifiez que les pairs peuvent l’atteindre, car un relais lui-même derrière un NAT difficile ne change rien. Puis cessez de régler les paramètres punch pour cette paire, car le chemin direct n’allait jamais apparaître.

Testez la paire qui a échoué, après inactivité

Reproduisez la condition qui a cassé : laissez la paire inactive pendant le même intervalle, ou répétez la séquence de poignées de main qui échouait. Exercez ensuite l’application entre ces deux pairs, pas une requête vers le phare. Une réponse du phare prouve le chemin de contrôle et rien sur le chemin de données.

Notez quel réglage a changé, l’heure, et si un chemin direct est apparu ou si le trafic est resté sur le relais. S’il est resté, la réponse est un relais et une note de capacité, et c’est un résultat parfaitement bon. S’il est apparu, la question suivante est de savoir s’il survit une heure d’inactivité, car une correspondance qui se dégrade est exactement le problème pour lequel punch existe.