Quel saut NAT fait tomber le mappage VPN inactif et comment le savoir
Un flux VPN inactif peut mourir à chaque saut avec état. Répétez un test, comparez ce que chaque frontière a vu et rapportez le résultat borné plutôt qu’un coupable supposé.
Après une période calme le tunnel se reconnecte, aucun journal ne nomme de coupable, et le geste évident est de choisir l’appareil qui a la documentation de délai la plus impressionnante. C’est une supposition habillée en diagnostic. L’état peut survivre un moment dans un routeur domestique, dans un traducteur d’opérateur et en périphérie de cloud, et chacun d’eux peut lâcher un flux qui se tait. Ce que vous pouvez faire à la place, c’est cartographier le chemin, marquer les appareils que vous pouvez réellement observer et exécuter un test d’inactivité que vous pouvez répéter.
Un test reproductible transforme une anecdote en mesure. Tout ce qui suit suppose un client, un serveur et un protocole, et suppose que vous résistez à changer deux variables à la fois. Le but est de rendre la prochaine occurrence moins coûteuse que celle-ci.
Exécutez le même test d’inactivité à chaque fois
Notez quand le flux était dernier connu bon, combien de temps il est ensuite resté inactif et si un paquet frais l’a ramené. Ces trois faits sont la mesure ; sans eux vous avez une histoire de portable qui a lâché. Utilisez le même client, le même serveur et le même protocole à chaque répétition, et notez l’instant où le premier paquet après le silence a été envoyé.
Comparez ensuite ce que chaque frontière que vous possédez a réellement vu. La distinction qui décide de l’enquête est de savoir si le serveur n’a rien vu du tout après la pause, ou s’il a vu la requête et répondu vers un chemin qui ne portait plus les réponses.
| What you observe | What it suggests | What it does not prove |
|---|---|---|
| server records no packet after the pause | state was lost upstream of the server | which hop dropped it |
| server answers, client never receives | return-path state or filtering | that the timer belongs to the client |
| client sends nothing at all | client-side timer or application behaviour | that the network path is healthy |
Comparer des chemins sans changer cinq choses
Un second réseau d’accès approuvé est une comparaison légitime, parce que la chaîne NAT diffère. Il diffère aussi par le fournisseur, les conditions radio et peut-être la famille d’adresses, donc le résultat est une frontière et non une attribution. Consignez les limites avec le résultat au lieu de les abandonner en silence quand vous rapportez. Notez le chemin au passage : appareil, rôle, et si son état peut être lu.
Ce qu’une comparaison de chemins vous achète, c’est une question bornée : le flux survit sur l’un et meurt sur l’autre après un silence comparable, donc la variable se trouve quelque part dans les parties qui diffèrent. C’est un résultat réel même quand aucun appareil n’est nommé, et il indique au prochain ingénieur où passer un après-midi et où ne pas le passer.
L’état local mérite d’être lu avant de spéculer sur les opérateurs. Sur une passerelle Linux, conntrack -L liste les flux suivis avec leur durée de vie restante, ce qui transforme une supposition sur un minuteur en un nombre que vous pouvez regarder expirer. Lisez-le avant et après la période d’inactivité, pas seulement après.
Ce qu’un signal de maintien tiendra et ce qu’il ne tiendra pas
Un signal de maintien pris en charge garde un mappage ouvert, et garder un mappage ouvert ne prouve rien sur le service derrière. Le tunnel peut rester mappé alors que l’application qu’il transporte a cessé de répondre, et depuis un voyant d’état ces deux situations se ressemblent. Traitez le signal de maintien comme une assurance contre l’expiration par inactivité, pas comme un contrôle de santé.
Réglez l’intervalle sur le délai le plus court que vous avez réellement mesuré, pas sur un nombre copié d’un forum. Un signal de maintien réglé sous chaque minuteur plausible est du trafic dont personne n’avait besoin, et il retire aussi le symptôme qui vous aurait dit quelle frontière expire en premier. Choisissez l’intervalle à partir du nombre mesuré et laissez le reste tranquille.
Un changement, puis mesurez de nouveau
Résistez à l’envie de relever tous les délais et de vider chaque passerelle pendant un test en direct. Cela efface les preuves pour lesquelles vous êtes venu et interrompt des flux appartenant à d’autres, ce qui est un mauvais échange pour une hypothèse que vous n’avez pas testée. Changez un réglage pris en charge sur un appareil, puis répétez la période d’inactivité et la reprise de l’application.
Notez quelle observation de frontière a bougé, et notez-le même quand rien ne s’est amélioré. Un réglage qui n’a rien réparé est une information, et il est moins coûteux de le remarquer une fois que de le dérouler sur tout le parc.
Écrire une conclusion que vous pouvez défendre
Quand un traducteur en amont ne peut pas être inspecté, dites seulement ce que les preuves soutiennent : l’échange meurt quelque part sur ce tronçon du chemin après tant de calme, et le saut responsable reste non attribué. Une affirmation bornée survit à la relecture et oriente la personne suivante vers le bon segment. Nommer un routeur caché comme cause ne fait ni l’un ni l’autre. Remettez la conclusion bornée à qui possède le segment non observable, avec l’intervalle joint.
RFC 4787 décrit pourquoi les minuteurs de mappage UDP sont difficiles à déduire depuis une seule extrémité, et cette difficulté est la raison pour laquelle la conclusion bornée est l’honnête. Les minuteurs sont réels, et l’incertitude autour d’eux aussi.