Le VPN UDP se fige au repos : le pare-feu a oublié votre flux

Le VPN se connecte, fonctionne un moment, puis cesse de faire passer le trafic alors que le client affiche encore une session. Une reconnexion corrige le problème, ce qui le fait passer pour un bug du client. C'est en général un pare-feu ou un appareil NAT qui a supprimé une correspondance UDP inactive et ignore que le tunnel existe toujours.

Le symptôme est assez constant pour être diagnostiqué : il apparaît après une période d'inactivité, pas sous charge.

À quoi ressemble un blocage au repos

Mesurez-le au lieu de le décrire. Notez combien de temps le tunnel reste inactif avant que le trafic s'arrête, si un nouveau paquet sortant le ranime et si l'interface du client conserve encore son adresse. Si une requête fraîche du client fonctionne mais qu'une réponse à un flux existant ne fonctionne pas, la correspondance est le suspect. Si rien ne fonctionne avant une reconnexion, l'état de session du client est perdu aussi.

Les deux sont liés à l'inactivité, et ils demandent des correctifs différents.

Notez les durées avant de changer quoi que ce soit. Un rapport disant que ça s'arrête après une dizaine de minutes d'inactivité est vérifiable, alors qu'un rapport disant que ça tombe au hasard ne l'est pas. Cette différence décide si vous chassez un minuteur ou un changement de routage.

Trouvez l'appareil qui a oublié

Plusieurs appareils peuvent conserver l'état du même flux : le routeur local, un traducteur en amont, une frontière cloud et le pare-feu de l'hôte. Chacun a son propre minuteur, et le plus court gagne. Une panne de cinq minutes signifie généralement qu'un appareil est configuré bien en dessous des autres.

Ne supposez pas que la valeur par défaut documentée est le délai d'expiration sur votre chemin. C'est la valeur par défaut d'un seul appareil.

• Routeur domestique : souvent des minutes, parfois bien moins.
• NAT cloud ou répartiteur de charge : cherchez le délai d'inactivité documenté spécifiquement pour UDP.
• Pare-feu de l'hôte : les minuteurs de suivi netfilter s'appliquent par flux.

Vérifiez les minuteurs sur le chemin réel

Sous Linux, les minuteurs de suivi netfilter sont visibles et ajustables : sysctl net.netfilter.nf_conntrack_udp_timeout et net.netfilter.nf_conntrack_udp_timeout_stream. Le second s'applique dès que du trafic a été vu dans les deux sens, ce qui explique qu'un tunnel établi puisse survivre à une simple sonde.

RFC 4787 décrit le comportement d'UDP NAT et les minimums recommandés. C'est la référence à citer quand une valeur par défaut de constructeur paraît anormalement courte.

Keepalive et reconnexion sont deux outils différents

Un keepalive maintient une correspondance en vie ; une reconnexion reconstruit une session morte. Ils règlent des défaillances différentes et ne sont pas des réglages de vitesse interchangeables. L'option PersistentKeepalive de WireGuard envoie un paquet à intervalle fixe pour garder la liaison NAT ouverte. L'option keepalive d'OpenVPN fait le même travail à sa manière. Ni l'une ni l'autre n'aide si l'appareil du milieu a déjà oublié le flux et supprime les deux directions.

Des sondes extrêmement fréquentes ajoutent du travail sans corriger la mauvaise frontière.

Vérifiez avec une nouvelle requête, pas avec un rechargement de page

Après avoir changé un minuteur ou ajouté un keepalive, répétez le scénario d'inactivité exactement comme avant. Faites ensuite une requête réellement nouvelle depuis l'application couverte. Un onglet de navigateur déjà chargé peut s'afficher depuis le cache et ne vous apprend rien.

Si le blocage persiste, avancez d'un saut vers l'extérieur et vérifiez la table d'états de cet appareil.