Interruption de connexion

Symptôme : Votre réseau en nuage virtuel (VCN) est connecté à votre réseau sur place au moyen d'un RPV site à site ou d'Oracle Cloud Infrastructure FastConnect. Les hôtes d'un côté de la connexion peuvent effectuer une commande ping sur les hôtes de l'autre côté, mais le trafic normal utilisant la connexion est interrompu. Par exemple :

• Vous pouvez accéder par SSH à un hôte sur la connexion, mais après vous être connecté à l'hôte, la connexion s'interrompt.
• Vous pouvez démarrer une connexion VNC (Virtual Networking Computing), mais la session s'interrompt.
• Vous pouvez démarrer un téléchargement SFTP, mais le téléchargement s'interrompt.

Problème général : La détection d'unité de transmission maximale de chemin (PMTUD) ne fonctionne probablement pas d'un côté de la connexion ou des deux. Elle doit fonctionner des deux côtés afin qu'elles puissent savoir si les paquets qu'elles tentent d'envoyer sont trop volumineux pour la connexion et les ajuster en conséquence. Pour un bref aperçu de l'unité de transmission maximale (MTU) et de la détection d'unité de transmission maximale de chemin (PMTUD), voir Aperçu de la MTU et Aperçu de la PMTUD.

Solutions pour corriger PMTUD :

Le diagramme suivant présente un exemple de scénario dans lequel votre réseau sur place est connecté à votre réseau VCN au moyen d'un RPV site-à-site et comporte des légendes représentant chaque partie de la solution.

1. Assurez-vous que les hôtes utilisent PMTUD : Si les hôtes du réseau sur place n'utilisent pas PMTUD (c'est-à-dire s'ils ne définissent pas l'indicateur Ne pas fragmenter dans les paquets), ils n'ont aucun moyen de détecter si les paquets qu'ils envoient sont trop volumineux pour la connexion. Les instances du côté Oracle de la connexion utilisent PMTUD par défaut. Ne modifiez pas cette configuration sur les instances. Assurez-vous également que les serveurs ont une règle de pare-feu autorisant ICMP de type 3, code 4.

2. Assurez-vous que les listes de sécurité du réseau VCN et les pare-feux d'instance autorisent les messages ICMP de type 3, code 4 : Lorsque PMTUD est utilisée, les hôtes expéditeurs reçoivent un message ICMP spécial s'ils envoient des paquets trop volumineux pour la connexion. À la réception du message, l'hôte peut mettre à jour de façon dynamique la taille des paquets en fonction de la connexion. Toutefois, pour que vos instances reçoivent ces messages ICMP importants, vous devez configurer les listes de sécurité du sous-réseau du VCN et des pare-feux d'instance pour accepter ces messages.

   Conseil
   
   Si vous utilisez des règles de liste de sécurité avec état (pour le trafic TCP, UDP ou ICMP), vous n'avez pas besoin de vérifier si votre liste de sécurité contient une règle explicite pour autoriser les messages ICMP de type 3 code 4 parce que le service Réseau suit les connexions et permet automatiquement ces messages. Les règles sans état nécessitent une règle explicite dans la liste de sécurité entrante pour les messages ICMP de type 3, code 4. Confirmez que les pare-feux de l'instance sont configurés correctement.

   Pour vérifier si un hôte reçoit les messages, voir Recherche de l'emplacement de la panne de PMTUD.

3. Assurez-vous que le routeur sur place respecte l'indicateur Ne pas fragmenter : Si le routeur ne respecte pas l'indicateur et ignore donc l'utilisation de PMTUD, il envoie des paquets fragmentés aux instances du réseau VCN. Cela n'est pas souhaitable (voir Pourquoi faut-il éviter la fragmentation?). Les listes de sécurité du VCN sont probablement configurées de façon à reconnaître uniquement le fragment initial tandis que les autres sont abandonnés, ce qui entraîne l'interruption de la connexion. Au lieu de cela, il faudrait que le routeur utilise PMTUD et respecte l'indicateur Ne pas fragmenter pour déterminer la taille correcte des paquets non fragmentés à envoyer au moyen de la connexion.

Vous trouverez ensuite un bref aperçu de MTU et de PMTUD, ainsi que la procédure permettant de vérifier si PMTUD fonctionne des deux côtés de la connexion réseau.

Vous vous demandez peut-être pourquoi la fragmentation doit être évitée. Premièrement, elle a une incidence négative sur la performance de votre application. La fragmentation exige le réassemblage des fragments et la retransmission des fragments perdus. Le réassemblage et la retransmission nécessitent du temps et des ressources processeur.

Deuxièmement, seul le premier fragment contient les informations sur les ports source et de destination. Cela signifie que les pare-feux ou les listes de sécurité de votre VCN abandonnent généralement les autres paquets, car ils sont généralement configurés pour évaluer les informations sur le port. Pour que la fragmentation fonctionne avec vos pare-feux et vos listes de sécurité, vous devez les configurer pour qu'elles soient plus permissives que d'habitude, ce qui n'est pas souhaitable.

Les communications entre deux hôtes sur un réseau IP utilisent des paquets. Chaque paquet a une adresse IP source et une adresse IP de destination, et des données utiles. Chaque segment de réseau entre les deux hôtes a une unité de transmission maximale (MTU) représentant le nombre d'octets qu'un paquet peut contenir.

La taille standard de la MTU Internet est de 1500 octets. Ceci est également vrai pour la plupart des réseaux domestiques et de nombreux réseaux d'entreprise (et leurs réseaux Wi-Fi). Certains centres de données, y compris ceux pour Oracle Cloud Infrastructure, sont dotés d'une MTU plus importante. Toutes les instances de calcul OCI utilisent une MTU de 9000 par défaut. Sur un hôte Oracle Linux 8, vous pouvez utiliser la commande ip address show pour afficher la MTU de la connexion réseau de cet hôte (ou utiliser ip link sur Red Hat Linux). Par exemple, voici la sortie d'une instance Oracle Linux 8 (la MTU est mise en surbrillance en italique rouge) :

ip address show <interface-x>
<interface-x>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 01:00:5E:90:10:10 brd ff:ff:ff:ff:ff:ff
    ... 

À titre de comparaison, voici la sortie d'un hôte Oracle Linux 8 connecté à un réseau d'entreprise :

ip address show <interface-y>
<interface-y>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 01:00:5E:90:10:20 brd ff:ff:ff:ff:ff:ff
    ...

Remarquez que sa MTU est de plus de 1500 octets.

Si l'hôte est connecté au moyen d'un réseau privé virtuel d'entreprise, la MTU est encore plus basse car le tunnel RPV doit encapsuler le trafic à l'intérieur d'un paquet IPSec et l'envoyer sur le réseau local. Par exemple :

ip address show <interface-z>
<interface-z>: flags=81d1<UP,POINTOPOINT,RUNNING,NOARP,PROMISC,MULTICAST> mtu 1300 
... 

Comment les deux hôtes déterminent-ils la taille de paquet qu'ils peuvent s'envoyer l'un à l'autre? Pour de nombreux types de trafic réseau, tels que HTTP, SSH et FTP, les hôtes utilisent le protocole TCP pour établir de nouvelles connexions. Lors de l'établissement d'une liaison en trois temps entre deux hôtes, chacun envoie la taille maximale du segment (MSS) pour déterminer la taille de leurs données utiles. Cette valeur est inférieure à la MTU. (TCP s'exécute à l'intérieur du protocole Internet (IP). Pour cette raison, il est appelé TCP/IP. Les segments sont à TCP ce que les paquets sont à IP.)

À l'aide de l'application tcpdumpde, vous pouvez voir la valeur MSS partagée pendant l'établissement de la liaison. Voici un exemple de tcpdump (la valeur MSS est mise en surbrillance en italique rouge) :

12:11:58.846890 IP 192.168.0.25.22 > 10.197.176.19.58824: Flags [S.], seq
2799552952, ack 2580095593, win 26844, options [mss 1260,sackOK,TS val
44858491 ecr 1321638674,nop,wscale 7], length 0

Le paquet précédent provient d'une connexion SSH à une instance d'un ordinateur portable connecté à un RPV d'entreprise. Le réseau local que l'ordinateur portable utilise pour sa connexion Internet a une MTU de 1 500 octets. Le tunnel RPV impose une MTU de 1300 octets. Lors d'une tentative de connexion SSH, TCP (exécuté à l'intérieur de la connexion IP) indique à l'instance Oracle Cloud Infrastructure qu'il prend en charge les segments TCP dont le nombre d'octets est inférieur ou égal à 1 260. Avec une connexion RPV d'entreprise, l'ordinateur portable connecté au réseau RPV a généralement une MTU et une MSS plus basses que les appareils avec lesquels il communique par Internet.

Dans un cas plus complexe, les deux hôtes ont une MTU plus élevée qu'un lien réseau intermédiaire entre eux qui n'est connecté directement à aucun d'entre eux. Le diagramme suivant illustre un exemple.

Cet exemple présente deux serveurs, chacun directement connecté à son propre réseau routé prenant en charge une MTU de 9000 octets. Les serveurs se trouvent dans différents centres de données. Chaque centre de données est connecté à Internet, qui prend en charge une MTU de 1 500 octets. Un tunnel IPSec RPV site à site relie les deux centres de données. Ce tunnel traverse Internet. La MTU de l'intérieur du tunnel est donc plus basse que celle d'Internet. Dans ce diagramme, la MTU est de 1380 octets.

Si les deux serveurs tentent de communiquer (avec SSH, par exemple), pendant l'établissement d'une liaison en trois temps, ils s'accordent sur une MSS autour de 8960. La connexion SSH initiale peut aboutir, car la taille maximale des paquets lors de la configuration initiale de la connexion SSH est généralement inférieure à 1380 octets. Lorsqu'un côté tente d'envoyer un paquet supérieur au plus petit lien entre les deux points d'extrémité, la détection de MTU de chemin (PMTUD) devient critique.

La détection de MTU de chemin est définie dans les documents RFC 1191 et RFC 8899 . Elle fonctionne en exigeant des deux hôtes communicant de définir un indicateur Ne pas fragmenter dans les paquets qu'ils envoient. Si un paquet de l'un de ces hôtes atteint un routeur où l'interface sortante possède une MTU inférieure à la longueur du paquet, le routeur abandonne ce dernier. Le routeur retourne également un message ICMP de type 3 code 4 à l'hôte. Ce message indique spécifiquement "Destination inaccessible, fragmentation nécessaire mais l'option Ne pas fragmenter a été définie" (défini dans le document RFC 792). En clair, le routeur dit à l'hôte : "Vous m'avez dit de ne pas fragmenter les paquets trop volumineux et celui-ci est trop volumineux. Je ne l'envoie pas." Le routeur indique également à l'hôte la taille maximale de paquets autorisée par cette interface sortante. L'hôte expéditeur ajuste ensuite la taille des paquets sortants pour qu'ils soient plus petits que la valeur fournie par le routeur dans le message.

Cet exemple présente le résultat d'une tentative de commande ping effectuée par une instance sur un hôte (203.0.113.2) sur Internet, avec un paquet de 8000 octets et l'indicateur Ne pas fragmenter défini (c'est-à-dire avec la PMTUD activée). Le message ICMP retourné est mis en évidence en italique rouge :

ping 203.0.113.2 -M do -s 8000

PING 203.0.113.2 (203.0.113.2) 8000(8028) bytes of data.
From 10.0.0.2 icmp_seq=1 

Frag needed and DF set (mtu = 1500)

La réponse est exactement celle qui est attendue. L'hôte de destination se trouve sur Internet, qui a une MTU de 1500 octets. Même si la connexion réseau locale de l'hôte expéditeur est dotée d'une MTU de 9000 octets, l'hôte ne peut pas joindre l'hôte de destination avec le paquet de 8000 octets et reçoit un message ICMP en conséquence. La PMTUD fonctionne correctement.

À titre de comparaison, voici le même ping, mais l'hôte de destination se trouve de l'autre côté d'un tunnel IPSec RPV site à site :

ping 192.168.6.130 -M do -s 8000
PING 192.168.0.130 (192.168.0.130) 8000(8028) bytes of data.
From 192.0.2.2 icmp_seq=1 Frag needed and DF set 

(mtu = 1358)

Ici, le routeur RPV constate que pour envoyer ce paquet vers sa destination, l'interface sortante est un tunnel RPV. Ce tunnel se trouve sur Internet et doit donc tenir dans le lien MTU de 1500 octets d'Internet. Il en résulte que l'intérieur du tunnel ne permet que les paquets de 1 360 octets au maximum (chiffre qui est alors réduit à 1 358 par le routeur, ce qui complique encore les choses).

Si la PMTUD ne fonctionne pas quelque part le long de la connexion, vous devez en déterminer la raison et l'emplacement de la défaillance. En général, ceci est dû à un paquet ICMP de type 3, code 4 (depuis le routeur comportant un lien limité dans lequel le paquet ne tient pas), n'est jamais renvoyé à l'hôte expéditeur. Cela peut se produire si quelque chose bloque ce type de trafic entre l'hôte et le routeur, et d'un côté ou de l'autre du tunnel RPV (ou d'un autre lien MTU contraint).

-M pmtudisc_opt
Select Path MTU Discovery strategy. pmtudisc_option may be either do
(prohibit fragmentation, even local one), want (do PMTU discovery, fragment
locally when packet size is large), or dont (do not set DF flag).

ping -M do

 -s 1500 192.168.6.130
PING 192.168.0.130 (192.168.0.130) 1500(1528) bytes of data.
From 10.0.0.2 icmp_seq=1 

Frag needed and DF set (mtu = 1358)

Oracle recommande d'utiliser PMTUD. Il est toutefois possible, dans certains cas, de configurer des serveurs de sorte qu'ils n'en aient pas besoin. Prenons le cas des instances de votre réseau VCN communiquant, par l'intermédiaire d'un RPV site à site, avec des hôtes dans votre réseau sur place. Vous connaissez l'intervalle d'adresses IP de votre réseau sur place. Vous pouvez ajouter une route spéciale aux instances qui indique le maximum de MTU à utiliser lors d'une communication avec des hôtes figurant dans cet intervalle d'adresses. La communication d'instance à instance au sein du réseau VCN utilise toujours une MTU de 9000 octets.

Les informations suivantes indiquent comment définir cette route sur une instance de Linux.

La table de routage par défaut sur l'instance comporte généralement deux routes : la route par défaut (pour la passerelle par défaut) et une route locale (pour le sous-réseau local). Par exemple :

ip route show
default via 10.0.6.1 dev ens3
10.0.6.0/27 dev ens3  proto kernel  scope link  src 10.0.6.9

Vous pouvez ajouter une autre route qui pointe vers la même passerelle par défaut, avec l'intervalle d'adresses du réseau sur place et une MTU inférieure. Par exemple, dans la commande suivante, le réseau sur place est 1.0.0.0/8, la passerelle par défaut est 10.0.6.1 et la taille maximale de MTU est 1 300 pour les paquets envoyés au réseau sur place.

ip route add 1.0.0.0/8 via 10.0.6.1 mtu 1300

La table de routage mise à jour ressemble à ceci :

ip route show
default via 10.0.6.1 dev ens3
1.0.0.0/8 via 10.0.6.1 dev ens3  mtu 1300
10.0.6.0/27 dev ens3  proto kernel  scope link  src 10.0.6.9

Dans le réseau VCN, la communication d'instance à instance continue d'utiliser 9000 MTU. Toutefois, la communication avec le réseau sur place utilise 1300 au maximum. Cet exemple suppose qu'aucune partie de la connexion entre le réseau sur place et le VCN n'utilise une MTU inférieure à 1 300.