Un truc auquel on pense rarement quand on cause d'auto-hébergement et d'adresse IPv4 dynamique, c'est à quel point c'est relou lorsque l'on utilise XMPP (messagerie instantanée) avec son serveur à la maison.

En effet, lors d'une conversation, XMPP utilise deux connexions TCP entre les serveurs XMPP de chaque correspondant. La première délivre les messages (et les accusés de réception) écrits par le correspondant 1 au correspondant 2. La deuxième connexion... délivre les messages écrits par le correspondant 2 au correspondant 1.

Donc, lorsque le correspondant 1 change d'IP, son serveur XMPP n'en a pas conscience (car l'adresse IP publique est attribuée à un routeur en amont du serveur) et continue donc à vouloir transmettre les messages du correspondant 1 au 2e correspondant comme si de rien n'était... On a donc une première session TCP aux caractéristiques suivantes : {nouvelle_IP_correspondant_1, sport, IP_correspondant_2, 5269 }. Le serveur du correspondant 2 n'a pas cette session dans sa table (lui il a {ancienne_IP_correspondant_1, sport, IP_correspondant_2, 5269 }) et casse donc la session avec un RST en mode "hé, d'où tu me causes, je te connais pas !". Donc le serveur du correspondant 1 monte une nouvelle connexion TCP et... ça fonctionne : correspondant 1 est bien en mesure de parler à correspondant 2.

Par contre, correspondant 2 ne peut pas répondre à correspondant 1 car le serveur XMPP de ce premier continue à émettre à destination de l'ancienne IP du correspondant 1. Comme elle n'est pas réattribuée immédiatement par le FAI, il n'y a pas de RST... Il faut donc attendre l'expiration des timers TCP soit entre 15 minutes et 20 minutes constatées. Étant donné que l'on essaye de transmettre quelque chose (il y a toujours quelque chose à transmettre : état, présence,...), je pense que c'est le paramètre « tcp_retries2 » du noyau qui influe (« The maximum number of times a TCP packet is retransmitted in established state before giving up. The default value is 15, which correspondants to a duration of approximately between 13 to 30 minutes, depending on the retransmission timeout. [NDLR : qui dépend lui-même du RTT de la connexion, de nos jours] ». En cas d'inactivité complète (si c'est possible, je n'y crois pas avec XMPP), je ne pense pas que tcp_keepalive_{time,intvl,probes} agisse puisque ejabberd coupe les connexions TCP de manière normale (FIN+ACK) après 10 minutes d'inactivité).

Une adresse IP dynamique, c'est juste mortel avec XMPP : on obtient une conversation à sens unique et ça casse bien comme il faut le rythme de la discussion. Note à ceux et celles qui ont un accès Internet avec une IP dynamique : bougez-vous pour changer de FAI, sérieusement ! Et si vous voulez faire le beau / la belle avec votre fibre optique, utilisez au moins un VPN chez un FAI de la fédération FDN. :-