Qu'est-ce que « End-to-End » signifie vraiment en réseau ?

Quand on dit qu'une connexion est « end to end », on veut dire que les données voyagent de l'application source originale jusqu'à l'application destination sans qu'une middlebox ne les réécrive ou ne les termine silencieusement en chemin. Ça paraît simple jusqu'à ce que vous tracez le chemin réel d'un paquet à travers NAT, firewalls, load balancers et proxies.

Le principe end-to-end

Cette idée provient d'un article de 1984 par Saltzer, Reed et Clark, qui arguaient que certaines fonctions comme la fiabilité et le chiffrement doivent se trouver aux extrémités d'un réseau, pas au milieu. Le réseau cœur devrait juste transférer les paquets. Les extrémités gèrent la vérification d'erreurs, la retransmission et l'ordre.

TCP en est l'exemple le plus clair. Les routeurs au milieu ne suivent pas les numéros de séquence ni n'accusent réception des segments. C'est le travail des deux hôtes qui exécutent les piles TCP. La couche réseau (IP) fait juste une livraison au mieux effort, et TCP à chaque extrémité corrige ce qui se perd ou se réordonne.

Où end-to-end échoue aujourd'hui

Les réseaux modernes violent ce principe constamment, généralement pour de bonnes raisons opérationnelles :

• NAT réécrit l'IP source et le port, donc le paquet qu'un serveur voit n'est pas le paquet que le client a envoyé.
• Les proxies terminant TLS et les load balancers (comme un AWS ALB ou un reverse proxy nginx) terminent une session TCP/TLS et en démarrent une nouvelle. Le véritable endpoint du client est le proxy, pas le serveur d'app.
• Les firewalls stateful suivent l'état de la connexion et peuvent abandonner les paquets qui ne correspondent pas aux séquences attendues, s'injectant effectivement dans la conversation.
• CGNAT sur les réseaux ISP signifie que de nombreux clients partagent une IP publique, cassant l'hypothèse qu'une IP correspond à un seul hôte.

Cela importe en pratique quand vous debuggez. Si un utilisateur signale « la connexion s'est coupée », vous devez savoir si elle s'est coupée à leur laptop, leur routeur maison, l'ISP, un nœud CDN edge, un load balancer ou le serveur origin. La pensée end-to-end vous force à tracer toute la chaîne au lieu de juste vérifier vos propres logs serveur.

Tester la connectivité end-to-end

Quelques outils qui vous montrent vraiment le chemin, pas juste succès/échec :

# Tracer la route hop par hop
traceroute 8.8.8.8

# Sur Linux, MTR donne des stats continues par hop
mtr google.com

# Vérifier les problèmes MTU qui fragmentent ou lâchent silencieusement les paquets
ping -M do -s 1472 8.8.8.8

Cette dernière commande vaut la peine d'être bien connue. Les échecs de path MTU discovery sont un classique « ça ressemble à une connectivité end-to-end mais c'est pas ça » problème. Les petits paquets comme un TCP SYN passent bien, mais une fois que vous envoyez un payload full-size, un hop quelque part au milieu le lâche silencieusement parce qu'il est trop gros et ICMP « fragmentation needed » est bloqué par un firewall. La connexion pend et tout le monde blâme l'appli.

Pour TCP spécifiquement, tcpdump ou ss -ti aux deux extrémités vous dit si les deux hôtes s'accordent même sur le fait qu'ils ont une connexion ouverte :

ss -ti dst 203.0.113.5

Si un côté pense que la connexion est ESTABLISHED et l'autre montre rien, quelque chose au milieu (généralement un firewall qui timeout les connexions inactives) l'a silencieusement tuée.

Pourquoi c'est important pour la sécurité

Le chiffrement end-to-end est la version pertinente pour la sécurité de ce même concept. TLS entre un navigateur et un edge CDN n'est pas la même chose que TLS entre le navigateur et votre serveur origin. Si le CDN termine TLS et transfère en plaintext (ou une nouvelle connexion TLS) vers votre backend, vous avez deux hops chiffrés séparés, pas un canal chiffré continu. C'est correct pour la plupart des cas, mais si vous gérez quelque chose de sensible, vous devez savoir exactement où le déchiffrement se produit et qui peut voir du plaintext à chaque hop.

La même logique s'applique aux VPNs. Un VPN « full tunnel » vous donne le chiffrement end-to-end de votre device au nœud de sortie VPN, mais la connexion du nœud de sortie au serveur destination réel est un hop séparé avec ses propres propriétés de sécurité.

Le takeaway pratique

Quand quelqu'un dit qu'un chemin réseau est end to end, demandez : end to end entre quels deux points exactement ? Le client et le load balancer ? Le load balancer et le serveur app ? Nommer les vrais endpoints transforme une affirmation réseau vague en quelque chose que vous pouvez tester avec une packet capture.

Si vous voulez creuser sur le tracing de vrai trafic et la lecture de packet captures, check les segments Wireshark et TCP/IP fundamentals sur la plateforme DEFENSE_GRID de Korra Studio.